CppCon 2017: Carl Cook “When a Microsecond Is an Eternity: High Performance Trading Systems in C++”

What Hacker News said

Recommends log_base_login · 2017-11 · on “Coders who trade: Wall Street designs its staff for the future”

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 a

Recommends pjmlp · 2020-05 · on “Ask HN: What programming skills are required by HFT or Trading firms”

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 coun

Recommends jeffreygoesto · 2020-11 · on “Ask HN: Am I too late for the “Data Science” wave?”

First of all, it leaves the team behind if you use features that are too advanced. Makes collaboration hard if you have wildly diverging skills (in both ways). Also, it did in our case take you away so far from the bare metal, that the code was elegant, but slow. It did not play well with our static allocators and allocated/deallocated way too much, especially temporaries. You might i.e. check out talks like [0]. [0] [this video]

Recommends vgatherps · 2020-11 · on “Java is better than C++ for high speed trading systems”

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

Recommends benreesman · 2022-08 · on “Understanding Jane Street”

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 g

Recommends vgatherps · 2023-09 · on “Unpacking Elixir: Real-Time and Latency”

This is almost certainly incorrect, unless it’s using a very stretched definition of “hft” and using microseconds to mean 99th% <1ms instead of say <5us (reasonably competitive software range depending on your trade). They might be forwarding non latency sensitive client/internal orders through a system written in erlang, or using erlang for an orchestration layer, but they’re not competing with other hft traders in one. Source: I work in the field and have built <5us systems. [this video] Is a free great watch about the things you have to do to very reliably have such low latencies

Recommends benreesman · 2025-08 · on “HRT's Python fork: Leveraging PEP 690 for faster imports”

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

Cites zeusk · 2018-06 · on “Intel 28-core fantasy vs. AMD 32-core reality”

> I can imagine few cases where first-to-right-the-bell performance on a single core determines if you get a specific quote in HFT but that's that. That is actually the case from what I've heard, A lot of them buy consumer chips then disable all but one core and overclock it to the max. Here is a guy from optiver talking about their process at CppCon: [this video]