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

191–200 of 240 posts

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

#191

Post by munificent »

CyberDildonics wrote: post #53
nine_k wrote: post #44

Earlier quoted context omitted.

Delightfully hardcore indeed! But of course you don't have to buy a rack of servers for testing, you can rent it. Servers are a quickly depreciating asset, why invest in them?

Why would replaying data for testing be "Delightfully hardcore indeed!". That's how people program in general, they run the same data through their program. Servers are a quickly depreciating asset, why invest in them? I don't think they are a quickly depreciating asset compared to the price of renting, but you would want total control over them in this scenario anyway.

> Why would replaying data for testing be "Delightfully hardcore indeed!".

Replaying data isn't hardcore. Buying a dedicated server and running it through a dedicated switch just to gather precise timing info is.

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

#192

Post by Aurornis »

chipdart wrote: post #154
nickelpro wrote: post #83

Fairly trivial base introduction to the subject. In my experience teaching undergrads they mostly get this stuff already. Their CompArch class has taught them the basics of branch prediction, cache coherence, and instruction caches; the trivial elements of performance. I'm somewhat surprised the piece doesn't deal at all with a classic performance killer, false sharing, although it seems mostly concerned with single-…

> Fairly trivial base introduction to the subject. Might be, but low-latency C++, in spite of being a field on its own, is a desert of information. The best resources available at the moment on low-latency C++ are a hand full of lectures from C++ conferences which left much to be desired. Putting aside the temptation to grandstand, this document is an outstanding contribution to the field and perhaps the first author…

> this document is an outstanding contribution to the field and perhaps the first authoritative reference on the subject.

I don't know how you arrive at this conclusion. The document really is an introduction to the same basic performance techniques that have been covered over and over. Loop unrolling, inlining, and the other techniques have appeared in countless textbooks and blog posts already.

I was disappointed to read the paper because they spent so much time covering really basic micro techniques but then didn't cover any of the more complicated issues mentioned in the parent comment.

I don't understand why you'd think this is an "outstanding contribution to the field" when it's basically a recap of simple techniques that have been covered countless times in textbooks and other works already. This paper may seem profound if someone has never, ever read anything about performance optimization before, but it's likely mundane to anyone who has worked on performance before or even wondered what inlining or -Funroll-loops does while reading some other code.

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

#193

Post by vineyardlabs »

hermitdev wrote: post #188
ssfrr wrote: post #178

Earlier quoted context omitted.

I guess the difference I'm interested in is whether HFT tends to be "realtime", in the sense that there's a hard deadline that you need to hit every time. Put another way, audio is operating on a much longer timescale, but cares a lot about worst-case latency (as well as throughput and quality). Is that true of HFT also, or are they more concerned with average latency? If computing a trade takes too long, can they ju…

I can't go into too much detail (I currently work at an HFT, but not on the HFT bits), but some of the FPGAs make decisions without even seeing a entire packet coming in on the wire. Latencies are more often measured in nanos than micros from what I've seen lately.

Tangentially, how do you like working for an HFT? I'm a low level software / FPGA developer and have thought about going into the HFT space. Is the work life balance as terrible as people say?

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

#194

Post by fsloth »

Aurornis wrote: post #192
chipdart wrote: post #154

Earlier quoted context omitted.

> Fairly trivial base introduction to the subject. Might be, but low-latency C++, in spite of being a field on its own, is a desert of information. The best resources available at the moment on low-latency C++ are a hand full of lectures from C++ conferences which left much to be desired. Putting aside the temptation to grandstand, this document is an outstanding contribution to the field and perhaps the first author…

> this document is an outstanding contribution to the field and perhaps the first authoritative reference on the subject. I don't know how you arrive at this conclusion. The document really is an introduction to the same basic performance techniques that have been covered over and over. Loop unrolling, inlining, and the other techniques have appeared in countless textbooks and blog posts already. I was disappointed t…

”covered countless times in textbooks”

What’s your favourite textbook on the subject?

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

#195

Post by PoignardAzur »

nickelpro wrote: post #83

Fairly trivial base introduction to the subject. In my experience teaching undergrads they mostly get this stuff already. Their CompArch class has taught them the basics of branch prediction, cache coherence, and instruction caches; the trivial elements of performance. I'm somewhat surprised the piece doesn't deal at all with a classic performance killer, false sharing, although it seems mostly concerned with single-…

> optimization tricks like fat LTO, PGO, or even the standardized hinting attributes ([[likely]], [[unlikely]]) for optimizing icache layout

If you do PGO, aren't hinting attributes counter-productive?

In fact, the common wisdom I mostly see compiler people express is that most of the time they're counter-productive even without PGO, and modern compilers trust their own analysis passes more than they trust these hints and will usually ignore them.

FWIW, the only times I've seen these hints in the wild were in places where the compiler could easily insert them, eg the null check after a malloc call.

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

#196

Post by mgaunard »

ssfrr wrote: post #186
mgaunard wrote: post #145

Earlier quoted context omitted.

Latency isn't even as important in HFT as people claim. What's most important is deterministically staying into a reasonable enveloppe (even at the 99.9 percentile) to satisfy real-time requirements and not fall behind. When it's really important, it's implemented in FPGA or with an ASIC.

This is close to the question I asked above, comparing to audio. If you're processing 32 samples at a time at 48kHz, you need to process a frame every 667us. If you only hit the deadline 99.9% of the time, that's a glitch more than once per second. You'd need a bunch more nines for an acceptable commercial product, so most audio devs just treat it as a hard realtime constraint. I think the main split is whether you c…

In HFT you typically only measure latency for events that you did react on, not all events (at least, in the systems that I've built).

That's arguably a bit problematic as events you don't react to can cause you to fall behind, so it's useful to also track how far behind you are from the point where you start processing a packet (which requires hardware timestamping, unfortunately not present on many general-purpose NICs like what's in the cloud).

For a given market, you may have less than 1M samples a day (I've even seen some so-called HFT strategies or sub-strategies that only had 300 samples per day).

So overall, you'd have fewer events than 44.1kHz, and there are typically expected outliers at the beginning of the data before the system gets warmed up or recovers from bad initial parameters (which I suppose you could just ignore from your distribution, or you could try not to require a warmup).

But you're right, you probably want to look at quantiles closer to 1 as well. You're also looking at the max regardless.

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

#197

Post by atomicnumber3 »

mgaunard wrote: post #147
atomicnumber3 wrote: post #135

Earlier quoted context omitted.

"which is 3 orders of magnitude faster than a single frame in a video game." You're right on the money. I worked in HFT for half a decade. Back in the late 2000s you were on the cutting edge if you were writing really good C++ and had overclocked some CPUs to hell and back and then shoved them in a rack in a datacenter in new jersey. "To hell and back" means "they only crash every hour or two" (because while they're…

Even if the low-latency logic moves to the FPGA, you still need your slow path to be reasonably fast, say about 100us, and absolutely never more than 1ms. To my knowledge Python is not suitable, though I know some players embed scripting languages that are.

It depends entirely on what you've got on the FPGA and what's slow-path. My firm had order entry done exclusively by the FPGA and the non-FPGA code would have orders in the FPGA for sometimes tens of seconds before they would fire. The non-FPGA code was still C++, but the kind of everyday C++ where nobody has been wringing all the water out of it for speed gains. If we rewrote it all, it'd probably be python. But that's just us. Every firm has their own architecture and spin on how this all works. I'm sure somebody out there has C++ code that still has to be fast to talk to an FPGA. We didn't - you were either FPGA-fast or we didn't care.

edit: also, fwiw, "say about 100us, and absolutely never more than 1ms." things measured in that many microseconds are effectively not what my firm considered "low-latency". But like I said, there are lots of different speed games out there, so there's no one-size-fits-all here.

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

#198

Post by fsloth »

_aavaa_ wrote: post #172
nickelpro wrote: post #112

Earlier quoted context omitted.

Casey's a fundamentalist, in the religious extremist sense. Just as a theologian might have something to learn from the most extremely devout, so it is that there is valuable information in Casey's proselytizing. But you should no more follow Casey in form and function than you would any other fundamentalist.

While gesturing at religion and saying he's a fundamentalist is an easy rhetorical technique, it doesn't add much. Yes good resources do exist, but they are few and far between. The number of new undergraduates from cs or software engineering who learned to think in the ways needed to make low latency applications are a rounding error based on my experience with them. Most forgot it, weren't taught it well, or never…

Agree there are not enough performance zealots. Modern architectures are almost magically fast if you get all of the tiny invisible things that kill your performance sorted out correctly. The fact that the knowledge of how to achieve this is closer to black magic lore than foundational educational knowledge is sad.

Performance is surprisingly often a feature. When things become instantly fast, instead of horribly slow, new opportunities are suddenly feasible for a lot of things.

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

#199

Post by ykonstant »

I am curious: why does this field use/used C++ instead of C for the logic? What benefits does C++ have over C in the domain? I am proficient in C/assembly but completely ignorant of the practices in HFT so please go easy on the explanations!

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

#200

Post by roblatham »

fsloth wrote: post #194
Aurornis wrote: post #192

Earlier quoted context omitted.

> this document is an outstanding contribution to the field and perhaps the first authoritative reference on the subject. I don't know how you arrive at this conclusion. The document really is an introduction to the same basic performance techniques that have been covered over and over. Loop unrolling, inlining, and the other techniques have appeared in countless textbooks and blog posts already. I was disappointed t…

”covered countless times in textbooks” What’s your favourite textbook on the subject?

it's an oldie but _Advanced Compiler Design and Implementation_ covers these concepts really well in a language-independent way.
Post reply on HN