Live data from Hacker News

HRT's Python fork: Leveraging PEP 690 for faster imports

hudsonrivertrading.com

81–90 of 103 posts

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#81

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?

I don’t really understand question b), how else would you organize a venture involving more than a couple people?

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#82

Earlier 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…

> Right, exactly what I said. They don't make money by market making

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

#83
post #79
post #70

Earlier 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

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.

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#84
post #23

Earlier 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

With insignificant ecosystems, compared to Python.

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#86
post #15

Earlier 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…

> i.e Tesla posts horrible quarter numbers, but stock goes up

This is a non sequitur from who’s winning the HFT game

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#87
post #15

Earlier quoted context omitted.

when milliseconds mean millions

If that was the case, why use Python in the first place?

They’re not doing the fast stuff in python; nevertheless it’s worth their engineering to make the parts they do in python fast

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#89

I 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.

to prevent this, set PYTHONNOUSERSITE=1 will prevent searching for modules in ~/.local/ (for convenience, try calling python through a wrapper in your project, say bin/run-python, and there you can set all the python-specific environment variables you need, set at the time of execution and not have to worry about setting them in the user's shell etc)

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#90
> we support the Steering Council in their rejection of PEP 690—the implicit lazy imports are not a good fit for upstream due to the same, subtle bugs we encountered during our migration. However, as time permits, we hope to propose a revised lazy imports PEP that introduces an explicit lazy keyword, e.g. lazy import foo or lazy from foo import bar. This approach will satisfy migration and compatibility concerns, allow users to opt-in gradually, and enable all Python users to reap the speed benefits of lazy imports in a safe way.
Post reply on HN