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

201–210 of 240 posts

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

#201

Post by [deleted] »

quotemstr wrote: post #179
worstspotgain wrote: post #158

Earlier quoted context omitted.

> If you pass > foo(shared_ptr const&) > you incur an extra pointer chase in the callee. Actually this is usually not the case (assuming of course that caller is holding the original pointer in a shared_ptr which is the use case we were discussing.) That shared_ptr instance is held either on the stack (with address FP + offset or SP + offset) or inside another object (typically 'this' + offset.) To call foo(const sha…

> That shared_ptr instance is held either on the stack (with address FP + offset or SP + offset) or inside another object (typically 'this' + offset.) To call foo(const shared_ptr &), the compiler adds the base pointer and offset together, then passes the result of that addition - without dereferencing it. You're overthinking it. Think in cache lines. No matter what the instructions say, with all their fancy addressi…

[deleted]

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

#202

Post by quotemstr »

worstspotgain wrote: post #180
quotemstr wrote: post #179

Earlier quoted context omitted.

> That shared_ptr instance is held either on the stack (with address FP + offset or SP + offset) or inside another object (typically 'this' + offset.) To call foo(const shared_ptr &), the compiler adds the base pointer and offset together, then passes the result of that addition - without dereferencing it. You're overthinking it. Think in cache lines. No matter what the instructions say, with all their fancy addressi…

> No matter what the instructions say, with all their fancy addressing modes, foo has to load two cache lines: one holding the shared_ptr and another holding the pointee data. If we instead passed bar* in a register, we'd need to grab only one cache line: the pointee's. The cache doesn't make a difference here. To clarify: we start with a shared_ptr instance. It must get dereferenced to be used. It must either be der…

Sure. I've just only rarely encountered the situation you're describing. When it comes up, passing a shared_ptr by const reference is fine --- just so long as it's documented and the code explains "Look, I know this looks like a newbie error, but in context, it's actually an optimization. Here's why..." lest someone "optimize" away the deferred load win.

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

#203

Post by _aavaa_ »

fsloth wrote: post #198
_aavaa_ wrote: post #172

Earlier quoted context omitted.

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 slo…

> The fact that the knowledge of how to achieve this is closer to black magic lore than foundational educational knowledge is sad.

It is sad, doubly so since the things you need to get within an order of magnitude of what your hardware can do aren't the arcane assembly and "premature optimization" boogeymen students picture. Forget the 10x engineer, going from the 0.0001x engineer to the 0.1x would be a massive improvement and it's low hanging fruit.

They're simple things: have your code do less, learn what good performance should be, understand the hardware and internalize that the point is to program it, and use/build better tools (e.g. perhaps your programming model is fundamentally flawed if it essentially incentivizes things like the N+1 Selects Problem).

> Performance is surprisingly often a feature.

Performance is, unsurprisingly, often a missing feature in most software. Every day I need to boot up Teams I feel we stray further from Moore's light.

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

#204

Post by Narishma »

hi_dang_ wrote: post #109
_aavaa_ wrote: post #102

Earlier quoted context omitted.

I'd recommend: https://www.computerenhance.com The author has a strong game development (engine and tooling) background and I have found it incredibly useful. It also satisfies the requirement for "A genuine fear, hate, and anger, towards unnecessary allocations, copies, and other performance killers."

Very anecdotal but of the people I know in game studios who are tasked with engine work, and people who make a killing doing FPGA work for HFT firms, both camps shook their head at Casey’s HMH thing. Uniformly I do not know of a single professional developer of this sort of caliber who looked at HMH and thought it looks great. Quite the opposite. I think they found his approach and justifications unsound as it would…

The whole point of Handmade Hero is to make everything from scratch as a learning exercise, so using third-party libraries would be counter-productive.

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

#205

Post by djmips »

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?

Interestingly you can find a lot of good tips in the optimization section of 'Realtime Collision Detection ' https://realtimecollisiondetection.net/

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

#206

Post by kangda123 »

vineyardlabs wrote: post #193
hermitdev wrote: post #188

Earlier quoted context omitted.

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?

Not OP but it varies wildly between companies. JS and Citadel are both top tier trading shops and they could not be more different when it come to wlb.

It's not hard to sniff out during the process though.

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

#207

Post by vineyardlabs »

kangda123 wrote: post #206
vineyardlabs wrote: post #193

Earlier quoted context omitted.

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?

Not OP but it varies wildly between companies. JS and Citadel are both top tier trading shops and they could not be more different when it come to wlb. It's not hard to sniff out during the process though.

Yeah that's pretty much what I figured.

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

#208

Post by vineyardlabs »

kangda123 wrote: post #206
vineyardlabs wrote: post #193

Earlier quoted context omitted.

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?

Not OP but it varies wildly between companies. JS and Citadel are both top tier trading shops and they could not be more different when it come to wlb. It's not hard to sniff out during the process though.

Curious, what firm is "JS" in this context?

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

#209

Post by fsloth »

_aavaa_ wrote: post #203
fsloth wrote: post #198

Earlier quoted context omitted.

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 slo…

> The fact that the knowledge of how to achieve this is closer to black magic lore than foundational educational knowledge is sad. It is sad, doubly so since the things you need to get within an order of magnitude of what your hardware can do aren't the arcane assembly and "premature optimization" boogeymen students picture. Forget the 10x engineer, going from the 0.0001x engineer to the 0.1x would be a massive impro…

Totally agree on all points!

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

#210

Post by idohft »

immibis wrote: post #171
mrbald wrote: post #128

Earlier quoted context omitted.

Central counterparty concept implemented by most exchanges is a valid service, as otherwise counterparty risk management would be a nightmare - an example of a useful “middleman”.

Yes, but you and I can't even talk to the exchange. We have to talk to one of many brokers that are allowed to talk to the exchange, and brokers do much more than just passing your orders to exchanges. For example, IIRC they can legally front-run your orders.

What exactly do you mean when you say this: > IIRC they can legally front-run your orders.

I doubt this is true, but there are definitions attached to front-running.

Post reply on HN