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

C++ patterns for low-latency applications including high-frequency trading

arxiv.org

Post reply on HN
Print view View original

71–80 of 240 posts

Re: C++ patterns for low-latency applications including high-frequency trading

#71

Post by [deleted] »

gohwell wrote: post #64
zxcvbn4038 wrote: post #62

Earlier quoted context omitted.

When I did low latency everyone was offloading TCP to dedicated hardware. They would shut down every single process on the server and bind the trading trading app to the CPUs during trading hours to ensure nothing interrupted. Electrons travel slower than light so they would rent server space at the exchange so they had direct access to the exchange network and didn't have to transverse miles of cables to send their…

I’ve worked at a few firms and never heard of an IT budget for f-ups. Sounds like a toxic work environment.

[deleted]

Re: C++ patterns for low-latency applications including high-frequency trading

#72

Post by [deleted] »

itchyouch wrote: post #58
FredPret wrote: post #30

Earlier quoted context omitted.

What's the mechanism for removing liquidity?

Adding liquidity means to place an order that sits on the book while removing liquidity means to execute against an order that's already resting on the book.

[deleted]

Re: C++ patterns for low-latency applications including high-frequency trading

#73

Post by ra0x3 »

zxcvbn4038 wrote: post #62
worstspotgain wrote: post #50

Earlier quoted context omitted.

I briefly looked over your stock exchange code: - For memory management, consider switching to std::shared_ptr. It won't slow anything down and will put that concern to rest entirely. - For sockets, there are FOSS libraries that will outperform your code and save you a ton of headaches dealing with caveats and annoyances. For example, your looping through FD_ISSET is slower than e.g. epoll or kqueue. - For dependenci…

When I did low latency everyone was offloading TCP to dedicated hardware. They would shut down every single process on the server and bind the trading trading app to the CPUs during trading hours to ensure nothing interrupted. Electrons travel slower than light so they would rent server space at the exchange so they had direct access to the exchange network and didn't have to transverse miles of cables to send their…

A great insightful comment, thank you!

Re: C++ patterns for low-latency applications including high-frequency trading

#74

Post by bb88 »

sneilan1 wrote: post #40
temporarely wrote: post #36

Earlier quoted context omitted.

fun fact: the original LMAX was designed for and written in Java. https://martinfowler.com/articles/lmax.html

I think it made sense at the time. From what I understand, you can make Java run as fast as C++ if you're careful with it and use JIT. However, I have never tried such a thing and my source is hearsay from friends who have worked in financial institutions. Then you get added benefit of the Java ecosystem.

All the java libs that you use can never do an allocation -- ever!. So you don't really get that much benefit to the java ecosystem (other than IDE's). You have to audit the code you use to make sure allocations never happen during the critical path.

Fifteen years ago, the USN's DDX software program learned this the hard way when they needed a hard real time requirement in the milliseconds.

Re: C++ patterns for low-latency applications including high-frequency trading

#75

Post by pclmulqdq »

sneilan1 wrote: post #3

I've got an implementation of a stock exchange that uses the LMAX disruptor pattern in C++ https://github.com/sneilan/stock-exchange And a basic implementation of the LMAX disruptor as a couple C++ files https://github.com/sneilan/lmax-disruptor-tutorial I've been looking to rebuild this in rust however. I reached the point where I implemented my own websocket protocol, authentication system, SSL etc. Then I realized…

The LMAX disruptor is a great data structure when you have threads bound to cores and most/all of them are uncontended. It has some terrible pathologies at the tails if you aren't using this pattern. Threads getting descheduled at bad times can really hurt.

SPSC ring buffers are going to be hard to beat for the system you are thinking of, and you can likely also implement work stealing using good old locks if you need it.

Re: C++ patterns for low-latency applications including high-frequency trading

#76

Post by bb88 »

ramchip wrote: post #66
nine_k wrote: post #43

Earlier quoted context omitted.

From my hearsay, you absolutely can, given two things: fewer pointer-chasing data structures, and, most crucially, fewer or no allocations. Pre-allocate arrays of things you need, run ring buffers on them if you have to use a varying number of things. A fun but practical approach which I again heard (second-hand) to be used, is just drowning your code in physical RAM, and switch the GC completely off. Have enough RAM…

I worked in trading and we did the first one, in C++. We'd load all the instruments (stocks etc.) on startup to preallocate the "universe", and use ring buffers as queues. Instruments don't change during trading hours so restarting daily to pick up the new data is enough. I saw a Java team do the second one in an order router (a system that connects to various exchanges and routes+translates orders for each exchange'…

I honestly don't know why the real time trading devs don't make their own OS/programming language for this. It's not like they don't have the money.

Re: C++ patterns for low-latency applications including high-frequency trading

#77

Post by bb88 »

sneilan1 wrote: post #60
fooker wrote: post #49

Earlier quoted context omitted.

In my experience, once you know the problem really well, yes you're right. If you are building a complex prototype from scratch, you'll usually spend more time fighting the Rust compiler than trying out alternate design decisions.

I do know the problem domain well. My second iteration in rust already almost has an order book implemented. Writing code in rust however is very fun! (At least so far lol)

Better than C++? Have you experienced any problems in Rust that C++ instantly solved? Not because I'm pro/anti rust/C++ here, just curious.

Re: C++ patterns for low-latency applications including high-frequency trading

#78

Post by lmm »

globular-toast wrote: post #5

Is there any good reason for high-frequency trading to exist? People often complain about bitcoin wasting energy, but oddly this gets a free pass despite this being a definite net negative to society as far as I can tell.

> a definite net negative to society as far as I can tell.

What did you examine to reach that conclusion? If high-frequency trading were positive for society, what would you expect to be different?

The reason for high-frequency trading to exist is that the sub-penny rule makes it illegal to compete on price so you have to compete on speed instead. Abolishing the sub-penny rule would mean high-frequency trading profits got competed-away to nothing, although frankly they're already pretty close. The whole industry is basically an irrelevant piece of plumbing anyway.

Re: C++ patterns for low-latency applications including high-frequency trading

#79

Post by TheAlchemist »

globular-toast wrote: post #5

Is there any good reason for high-frequency trading to exist? People often complain about bitcoin wasting energy, but oddly this gets a free pass despite this being a definite net negative to society as far as I can tell.

Because it's not explicitly forbidden ?

I would argue that HFT is a rather small space, albeit pretty concentrated. It's several orders of magnitude smaller in terms of energy wasting than Bitcoin.

The only positive from HFT is liquidity and tighter spreads, but it also depends what people put into HFT definition. For example, Robinhood and free trading, probably wouldn't exist without it.

They are taking a part of the cake that previously went to brokers and banks. HFT is not in a business of screwing 'the little guy'.

From my perspective there is little to none negative to the society. If somebody is investing long term in the stock market, he couldn't care less about HFT.

Re: C++ patterns for low-latency applications including high-frequency trading

#80

Post by cheonic730 »

FredPret wrote: post #30
blakers95 wrote: post #29

Earlier quoted context omitted.

Yep and what's worse is many hft firms aren't in the market-making business at all but actually REMOVE liquidity.

What's the mechanism for removing liquidity?

> What's the mechanism for removing liquidity?

Liquidity removal = market order

Liquidity providing = limit order (not immediately executable)

Post reply on HN