Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hudsonrivertrading.com

Post reply on HN
Print view View original

91–100 of 103 posts

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

#91

Post by benreesman »

nly wrote: post #79
dumah wrote: 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

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.

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

#92

Post by gkze »

skeledrew wrote: post #85

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

Yeah I wonder what led them down the drastic fork trajectory rather than considering this approach… kind of interesting this wasn’t even acknowledged in the article

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

#93

Post by nasretdinov »

gjvc wrote: post #89
nasretdinov wrote: post #17

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)

Thanks, yeah I know that it works, what I meant is that it may be quite easy to compare the module import times with and without that env variable to see how much impact an NFS home directory has (and it's a lot), and possibly draw similar conclusions about the distributed file system behaviour in general too

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

#94

Post by atombender »

ActorNightly wrote: post #48
Redoubts wrote: post #44

Earlier quoted context omitted.

> Because every single trading firm makes money on fees I really want to know what you think this company does, precisely

I can't tell if people don't understand how financial firms work or are you just being sarcastic. If a company has customers, and those customers buy a product, the company charges a price for that product.

They're a market market that provides liquidity to clients. They (as far as I know) don't charge fees, but earn their profits by exploiting the ask/bid spread.

A customer might want to offload TSLA and are willing to pay the market rate of $329. This trade might work in HRT's favor if they can sell it for $329.01. It's just 1 cent, but over millions of transactions these small amounts of profit add up.

The value captured by HRT is meaningful in the aggregate, but tiny and irrelevant to the institutional clients, and therefore can't be thought of as a fee. What HRT provides in return for taking clients' trades is liquidity.

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

#95

Post by sgarland »

roadside_picnic wrote: post #11

Interviewed with HRT awhile back. While I didn't get past the final round, their Python internals interview (which I did pass) was an absolute blast to prepare for, and required a really deep dive into implementation specific details of CPython around things like exactly how collisions are handled in dict, details about memory management, etc. Pretty much had to spend a few weeks in the CPython source to prep, and wa…

I also interviewed with them a couple of years ago, for their Database SRE (AKA DBRE) role. It was going quite well until I discovered that they required you to live within commuting distance of an office, and unfortunately I had just moved away from one. They didn’t require in-person, supposedly, but needed the option, I guess?

I was quite impressed by the interviews, mostly for their pragmatism and skill-fitting. The programming interview wasn’t LC, it was “can you use a language (preferably Python) to parse a CSV and get useful information out of it,” because that’s the skill level the team needs. On the other hand, the Linux and DB interviews were quite in-depth, because again, the team needs those skills.

10/10 would interview again if I’m ever near an office again.

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

#96

Post by mdaniel »

sunshowers wrote: post #8
zzzeek wrote: post #6

Gonna call this an antipattern. Do you need all those modules imported in every script ? Well then you save nothing on loadup time, the time will be spent regardless. Does every script not need those imports ? Well they shouldn't be importing those things and this small set of top level imports should be curated into a better, more fine grained list (and if you want to write tools, you can certainly identify these pa…

There are often large programs where not every invocation imports every module. The lazy import approach was pioneered in Mercurial I believe, where it cut down startup times by 3x.

Or, here's an idea: don't write a CLI on the hot path of a developer's flow in a scripting language. No wonder it lost out

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

#97

Post by sunshowers »

mdaniel wrote: post #96
sunshowers wrote: post #8

Earlier quoted context omitted.

There are often large programs where not every invocation imports every module. The lazy import approach was pioneered in Mercurial I believe, where it cut down startup times by 3x.

Or, here's an idea: don't write a CLI on the hot path of a developer's flow in a scripting language. No wonder it lost out

I don't disagree, but I mean it was either that or C + shell back in the early 2000s, and C + shell is notorious for its non-portability across Unix and Windows—partly why Git on Windows requires an entire MSYS installation.

Today, it would be a mistake to use anything other than Rust (hence Jujutsu carrying the flame forward).

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

#98

Post by bitfilped »

globular-toast wrote: post #13

Imagine if these guys put their intelligence towards improving the world.

Not sure why you're throwing shade on people making a living. Go lobby to your representative if you think the financial market should be changed instead of belittling folks doing a job.

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

#100

Post by tracnar »

instig007 wrote: post #42
tracnar wrote: post #28

While I see the usefulness of lazy imports, it always seemed a bit backward to me for the importer to ask for lazy import, especially if you make it an import keyword rather than a Python flag. Instead I'd expect the modules to declare (and maybe enforce) that they don't have side effects, that way you know they can be lazily imported, and it opens the door for more optimizations, like declaring the module immutable.…

> it always seemed a bit backward to me for the importer to ask for lazy import, especially if you make it an import keyword rather than a Python flag Exactly this. There must be zero side effects at module import time, not just for load times, but because the order of such effects is 1) undefined, 2) heavily dependent on a import protocol implementation, and 3) poses safety and security nightmares that Python devs d…

For optimizing the module finding, using a custom import hook was indeed what I had in mind!
Post reply on HN