Most trading firms are past the whole "beat the other guys to buy". Established large investment firms already have all that on lockdown in terms of infrastructure and influence to the extent where they basically just run the stock market at this point (i.e Tesla posts horrible quarter numbers, but stock goes up).
Most of the smaller firms basically try to figure out the patterns of the larger firms and capitalize on that. The timescales have shifted quite a bit.
No, there are absolutely electronic trading markets where a difference of milliseconds of latency to certain events is worth more than a M PnL. That’s a long time.
The top trading firms are firing off orders in double digit nanoseconds, not milliseconds.
In some cases the order leaving the card starts to emerge before the packet containing the market data event that they're responding to has even finished arriving.
Waiting for a full microsecond for the packet to arrive before responding means you're already too slow
Doesn't the fact that a modern FPGA-centric (probably ASICs in the mix too at this point) hybrid NIC/order-parser/state-machine thing is rumored to be able to hit glass-to-glass of ~20-40ns mean that the speed game is hotter than ever?
Do you mean that because it involves a lot of hardware design now? The days of being able to offer around the inside in C++ on a regulated securities exchange are over, but there's still C++ driving the thing, that 20ns "tick to trade" or however it's being measured in some instance is still pretty basic response stuff, light speed is still a thing. There's a C++ program upstairs running the show, and it's trying to do it's job in under a mike for sure.
But there are more recent talks (Optiver is especially transparent about it but other people talk about it too): https://www.youtube.com/watch?v=sX2nF1fW7kI, that's David Gross at CppCon last year, it can't have changed that much since last year.
That’s irrelevant to the fact that the expected PnL on a millisecond of latency improvement is a lot more than 1M in some markets. Obviously if you are getting what ever trade you are concerned with off in less than one millisecond, the question isn’t well posed.
There are many more games to play than delta one takeout and the solutions certainly don’t fit on one or a handful of FPGA’s.
I took the parent post to mean that a few large firms have emerged as clear winners of the speed game, and most other companies compete on (relatively) longer time scales now.
It's not uncommon to have a fast core and then an API that alpha / research teams feed signals into
if you are someone like HRT I presume the bulk of their money comes at very short holding periods so you have e.g. fast signals that work short term and then mid frequency alpha signals that spit out a forecast over a few timeframes i.e. it might not be that they buy (aggressively) really quickly but rather than someone sells to them and then they hold onto the position for longer than they would if they have no opinions.
Similarly this shapes where you post your orders e.g. if you really want it then you want to be top of the book
Well there's gonna be people writing code who can't do it in say a high performance C/C++ setup. Not professional programmers, but professional <some finance discipline>.
Sometimes it will be worth the tradeoff to put that person and a programmer together to code up a solution in another language. Sometimes it will be worth it to have the non-programmer write it in Python and then do Herculean things in the background to make it fast enough.
The gulf between high performance C/C++ and Python is vast and includes most other programming languages, many of which are friendly to write or can be made friendly to write for a limited domain, with significantly less rocket science needed than making python faster.
Even at the speediest trading firms, the large majority of code is not latency sensitive. Systems and algos are structured such that the fast acting stuff is simple and contained.
Honestly if you're a millisecond too slow you might as well not trade at all. From my own experience with trying to get Python to go fast for crypto trading, you can get it pretty fast using Cython - single digit microseconds on an average AWS instance for a simple linear regression was my proudest moment. They're probably pushing it even faster because nanoseconds are where the money's at. Many HFT firms are down in the double digit nanoseconds, I believe. Maybe lower.
In crypto, you have centralised (e.g. Coinbase) and decentralised exchanges (e.g. Uniswap). Decentralised exchanges operate onchain via smart contracts.
Those days are all over btw.
Most trading firms are past the whole "beat the other guys to buy". Established large investment firms already have all that on lockdown in terms of infrastructure and influence to the extent where they basically just run the stock market at this point (i.e Tesla posts horrible quarter numbers, but stock goes up).
Most of the smaller firms basically try to figure out the patterns of the larger firms and capitalize on that. The timescales have shifted quite a bit.
No, there are absolutely electronic trading markets where a difference of milliseconds of latency to certain events is worth more than a M PnL. That’s a long time.
The top trading firms are firing off orders in double digit nanoseconds, not milliseconds.
In some cases the order leaving the card starts to emerge before the packet containing the market data event that they're responding to has even finished arriving.
Waiting for a full microsecond for the packet to arrive before responding means you're already too slow
The speed game is essentially over
Doesn't the fact that a modern FPGA-centric (probably ASICs in the mix too at this point) hybrid NIC/order-parser/state-machine thing is rumored to be able to hit glass-to-glass of ~20-40ns mean that the speed game is hotter than ever?
Do you mean that because it involves a lot of hardware design now? The days of being able to offer around the inside in C++ on a regulated securities exchange are over, but there's still C++ driving the thing, that 20ns "tick to trade" or however it's being measured in some instance is still pretty basic response stuff, light speed is still a thing. There's a C++ program upstairs running the show, and it's trying to do it's job in under a mike for sure.
The OG talk on this is Carl Cook's: https://www.youtube.com/watch?v=NH1Tta7purM
But there are more recent talks (Optiver is especially transparent about it but other people talk about it too): https://www.youtube.com/watch?v=sX2nF1fW7kI, that's David Gross at CppCon last year, it can't have changed that much since last year.
That’s irrelevant to the fact that the expected PnL on a millisecond of latency improvement is a lot more than 1M in some markets. Obviously if you are getting what ever trade you are concerned with off in less than one millisecond, the question isn’t well posed.
There are many more games to play than delta one takeout and the solutions certainly don’t fit on one or a handful of FPGA’s.
I took the parent post to mean that a few large firms have emerged as clear winners of the speed game, and most other companies compete on (relatively) longer time scales now.
> i.e Tesla posts horrible quarter numbers, but stock goes up
This is a non sequitur from who’s winning the HFT game
If that was the case, why use Python in the first place?
It's not uncommon to have a fast core and then an API that alpha / research teams feed signals into
if you are someone like HRT I presume the bulk of their money comes at very short holding periods so you have e.g. fast signals that work short term and then mid frequency alpha signals that spit out a forecast over a few timeframes i.e. it might not be that they buy (aggressively) really quickly but rather than someone sells to them and then they hold onto the position for longer than they would if they have no opinions.
Similarly this shapes where you post your orders e.g. if you really want it then you want to be top of the book
They’re not doing the fast stuff in python; nevertheless it’s worth their engineering to make the parts they do in python fast
Well there's gonna be people writing code who can't do it in say a high performance C/C++ setup. Not professional programmers, but professional <some finance discipline>.
Sometimes it will be worth the tradeoff to put that person and a programmer together to code up a solution in another language. Sometimes it will be worth it to have the non-programmer write it in Python and then do Herculean things in the background to make it fast enough.
The gulf between high performance C/C++ and Python is vast and includes most other programming languages, many of which are friendly to write or can be made friendly to write for a limited domain, with significantly less rocket science needed than making python faster.
> Sometimes it will be worth it to have the non-programmer write it in Python and then do Herculean things in the background to make it fast enough.
Nim exists, Crystal exists
It would not surprise me if some shops end up using less common languages to fill a niche (or hell, invent their own DSL).
But it also wouldn't surprise me if a lot of shops land on python because that's what their hiring pool knows.
With insignificant ecosystems, compared to Python.
Even at the speediest trading firms, the large majority of code is not latency sensitive. Systems and algos are structured such that the fast acting stuff is simple and contained.
There’s tons of latency sensitive code outside of the FPGA systems and it is not simple.
Honestly if you're a millisecond too slow you might as well not trade at all. From my own experience with trying to get Python to go fast for crypto trading, you can get it pretty fast using Cython - single digit microseconds on an average AWS instance for a simple linear regression was my proudest moment. They're probably pushing it even faster because nanoseconds are where the money's at. Many HFT firms are down in the double digit nanoseconds, I believe. Maybe lower.
For reference, a byte at 10gbps is almost 1ns long.
Though the encoder runs 64/66bits at a time, so you really get around 8B every 7ns or so.
For crypto you pay the miners to put your transaction first. You don't need millisecond precission reaction time.
Crypto trading takes place on exchanges, not the blockchain though?
In crypto, you have centralised (e.g. Coinbase) and decentralised exchanges (e.g. Uniswap). Decentralised exchanges operate onchain via smart contracts.
This article from a16z explains the mechanics of reordering transactions for profit (MEV): https://a16zcrypto.com/posts/article/mev-explained/