CppCon
5 HN recommenders · recommended in 9 months, 2017–2025
1:00:07 · 358K views · Oct 8, 2017
Optiver's Carl Cook explains how to build high-frequency trading systems in C++, where the critical path runs rarely but must be extremely fast. He covers techniques for low and predictable latency, including avoiding main memory and cache misses.
HN repeatedly points people to it as the best overview of low-latency trading engineering.
10 comments from Hacker News
I’ve seen this sentiment before and worked on both a “low latency Java” team and low latency C++ teams. I have some sympathy for the idea that the JVM is better since it means you won’t spend all your time chasing crash reports. The thing is, like another comment hinted at, is that this issue is generally more reflective of the environment you build in than the technology choice. Here’s a good talk on the reasons for and limits of using C++ for low latency systems: this video If I had to rank in terms of reliability of trading infrastructure I’ve used/worked on, * Low Latency C / C++ infra at fully automated trading firm. Very much run by the programmers and quants and also fairly small. By far the fastest (near limits of what you could do) and also most reliable. * Low Latency Java execution infrastructure. Pretty reliable, not that fast, had some issues with GC battling and manual memory management to avoid GC, etc. There was a pretty clear latency floor (still quite low) even when “doing everything right” that serious native infrastructure beat. * C++ market making infra at a firm run by manual traders. It was by far the slowest and least reliable. Echos the experience of “spent hours debugging weird crashes”. The culture was very “A trader asked for this and needs it done yesterday. Also this refactoring business doesn’t sound like adding new features, drop it”. What I saw is that if you hire people who have a good idea of what they’re doing and keep a culture of technical e
I find this stuff fascinating, and this article is way above average for online posts about proprietary/algorithmic/quantitative/low-latency trading (very leaky Venn diagram there). I have a few nitpicks but overall it's informative and it's an interesting format: viewing an industry through the lens of a particular firm, especially one as fascinating as Jane. Anything that develops literacy in modern finance amongst the lay public is a good thing in my book. If this stuff floats your boat I'd also recommend any of Carl Cook's talks, e.g. this video . Optiver is AFAIK in a somewhat different business than Jane, but they're also players (or were last I had any inside baseball). Too many people got their worldview on this industry from "Flash Boys", and I say this as a Lewis fan, is criminally stupid at best and in bad faith at worst (if you want a well-researched, accessible alternative: [LINK] is about a zillion times better). It's a pretty short list of places I'd ever go through some grueling and semi-arbitrary gauntlet to work for, but Jane is on it for sure. I hope the author(s) do Medallion next.
Basically Java, .NET and C++, with heavy focus on C++. Being able to write allocation free algorithms, even on GC languages, lock free data structures and good knowledge of all multi-core programming paradigms and distributed computing. Here are some talks that will give you a small overview into that world, CppCon 2017: Carl Cook “When a Microsecond Is an Eternity: High Performance Trading Systems in C++” this video Core C++ 2019 :: Nimrod Sapir :: High Frequency Trading and Ultra Low Latency development techniques [LINK] Open source Java HFT code from Chronicle Software, [LINK] "Writing and Testing High-Frequency Trading Engines", from Cliff Click [LINK] However in these domains every ms counts, even how long cables are, so also expect Verilog, VHDL, and plenty of custom made algorithms running directly on hardware. "A Low-Latency Library in FPGA Hardware for High-Frequency Trading" [LINK] You can get an overview of the typical expectations here, [LINK]
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: this video But there are more recent talks (Optiver is especially transparent about it but other people talk about it too): [LINK] , that's David Gross at CppCon last year, it can't have changed that much since last year.
Thanks for the praise, and for the insight per your experience. Sounds like a great gig! I looked you up, and see that you are likely working exclusively in Haskell, but thought you might derive some value from Carl Cook's presentation on optimizing HFT code at the most recent cpp convention. I recognize the languages are distinctly different, but he provides some interesting theoretical points along the way that might be advantageous to you. Here's a link: this video Also, I can sympathize with your plight to run scalable sims. I've done some work in bioinformatics, and am building a small cluster at home so that I can learn to write code that'll scale to more massively parallel systems that are de rigueur in that domain. Cheers!