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

61–70 of 103 posts

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

#61

Post by ActorNightly »

mhh__ wrote: post #59
ActorNightly wrote: post #54

Earlier quoted context omitted.

I don't know what you define as outsider money, but the fact is that they are a market maker, and you are never going to make large amounts of money on arbitrage by itself.

Two business models: Good returns - take other peoples money, trade it, take 20% of profits Excellent returns - trade your own money, make a bit less overall but keep 100% of profits

If the first case, whats the incentive for users to trade with you

In the second case, why start a company?

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

#62

Post by ladberg »

ActorNightly wrote: post #52
Redoubts wrote: post #49

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 think you're misunderstanding what that page is: it's not an advertisement to invest with the company, it's an advertisement to trade via/with the company in the same way you might otherwise go manually trade from a Bloomberg terminal (or any other method).

There is no way to invest in the company, and the only way of becoming a "customer" is to engage in trading.

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

#63

Post by idohft »

ActorNightly wrote: post #32
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…

>Python devs at HRT really know their stuff. Its a finance firm - i.e scam firm. "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". Scammers are not tech people. And its pretty from their post. > In Python, imports occur at runtime. For each imported name, the interpreter must find, load, and evaluate the con…

> Its a finance firm - i.e scam firm. "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". > Scammers are not tech people. And its pretty from their post.

It would be great if you included any sort of evidence or argument.

Reading on to the other comments, it looks like you're throwing out a lot of accusations and claims. I don't know what you think you know, but from the looks of it, you don't really know HRT's business. I don't really these days, but I knew it years ago, and it's not from taking client money or arbitrage or some weird scam. It's not magic but the world of algo trading isn't a ponzi scheme.

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

#64

Post by arn3n »

mhh__ wrote: post #41
almostgotcaught wrote: post #9

Earlier quoted context omitted.

every quant shop has QR and QT people that can barely write passable python let alone cpp - then the QD people have to integrate that stuff with prod cpp pipelines.

alpha in being good at both (if nothing else you can keep more of the desks pnl...)

In my experience it tends to be the opposite — I am not a quant (QD) but having worked with a few teams there’s a negative selection for technical expertise. QRs who are good at programming are usually pushed into maintaining infrastructure, datasets, or just tooling for less technical members of their team, who then get to use those tools to further their own alpha generation. Orgs incentivize the final step in making alpha — spend too much time helping others or building reusable research, and your coworkers steal the thunder.

That, or stop helping your coworkers/accommodating them… risky, as a career move. Only seen that work once.

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

#65

Post by 82716f12 »

ActorNightly wrote: post #60
82716f12 wrote: post #56

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…

My understanding of these firms is limited too, but I’ve never heard of market makers charging transaction fees.

Isn’t it actually the opposite? they pay for order flow instead? They should be making money from bid-ask spread, not fees.

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

#66

Post by pgwhalen »

PufPufPuf wrote: post #22
htrp wrote: post #15

Earlier quoted context omitted.

when milliseconds mean millions

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

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.

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

#67

Post by ActorNightly »

82716f12 wrote: post #58
ActorNightly wrote: post #57

Earlier quoted context omitted.

You can have one module with all the capability, but the capability is separated into submodules. And the __init__.py of the module doesn't auto import the submodules So when you do this import bigmodule It doesn't do anything functionality, and you may only have some small top level things available for you, like bigmodule.config, or bigmodule.logging. Then, you have your big initializer code in bigmodule.financedat…

That sounds good in theory, but I haven’t come across a codebase that’s really optimized and free of unnecessary imports, especially in large companies. And when you have to depend on external libraries beyond your control, how do you typically handle those situations?

As codebases get larger, inefficiencies are bound to happen. Having explicit imports that I can go look up and see where they are is better for resolving this, because you can trace how every module gets imported and time them. Having interpreter code that runs with lazy loading that is all hidden is not the way to solve this.

As for external libraries, you import them in places where you need to use them only to avoid the same pitfalls. Its also pretty easy to analyze the import process within those libraries, and then again import specific submodules only that limit what actually gets loaded.

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

#68

Post by smohare »

82716f12 wrote: post #58
ActorNightly wrote: post #57

Earlier quoted context omitted.

You can have one module with all the capability, but the capability is separated into submodules. And the __init__.py of the module doesn't auto import the submodules So when you do this import bigmodule It doesn't do anything functionality, and you may only have some small top level things available for you, like bigmodule.config, or bigmodule.logging. Then, you have your big initializer code in bigmodule.financedat…

That sounds good in theory, but I haven’t come across a codebase that’s really optimized and free of unnecessary imports, especially in large companies. And when you have to depend on external libraries beyond your control, how do you typically handle those situations?

[dead]

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

#69

Post by KK7NIL »

charcircuit wrote: post #35
shepardrtc wrote: post #26

Earlier quoted context omitted.

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…

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?

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

#70

Post by dumah »

ActorNightly wrote: post #33
htrp wrote: 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…

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.
Post reply on HN