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

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.

in “HRT's Python fork: Leveraging PEP 690 for faster imports” · View on HN

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

in “Unpacking Elixir: Real-Time and Latency” · View on HN

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.

in “Understanding Jane Street” · View on HN

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

in “Ask HN: Am I too late for the “Data Science” wave?” · View on HN

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

in “Java is better than C++ for high speed trading systems” · View on HN

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]

in “Ask HN: What programming skills are required by HFT or Trading firms” · View on HN