Earlier quoted context omitted.
> If a company has customers They don't...
a) What do you call this at the bottom of the page https://www.hudsonrivertrading.com/liquidity/ b) If you don't have customers, why have a company?
HRT's Python fork: Leveraging PEP 690 for faster imports
81–90 of 103 posts
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#82Earlier quoted context omitted.
Being a market maker vs "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could" are two very different things lol Moreover, I would be very surprised if the majority of their $8 billion annual profit came from client market making.
Right, exactly what I said. They don't make money by market making. They make money by charging transaction fees, and on an access basis to their "algorithms" which are designed against analyzing the complex futures that they are the market maker for. The incentive for users to sign up with them is to get access to "better" pricing for whatever commodity they pair the buy/sell orders for - but remember these are futu…
“client market making”. That’s very different from “market making”, you two are not in agreement at all here
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#83Earlier quoted context omitted.
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
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.
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#84Earlier quoted context omitted.
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 . 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…
> 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
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#85Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#86Earlier quoted context omitted.
when milliseconds mean millions
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 l…
This is a non sequitur from who’s winning the HFT game
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#87Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#88Hmm it strikes me that is they really wanted to go this lazy route, they could've implemented an import hook, instead of creating and maintaining an entire fork.
Re: HRT's Python fork: Leveraging PEP 690 for faster imports
#89I wonder how much can be saved by using a local file system for imports though. In my testing just a mere presense of a home directory on NFS already dramatically slows down imports (by ~10x) due to Python searching for modules in home directory too by default.