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

141–150 of 240 posts

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

#141

Post by quotemstr »

Maxatar wrote: post #68
worstspotgain wrote: post #67

Earlier quoted context omitted.

Here's how to maximize shared_ptr performance: - In function signatures, use const references: foo(const std::shared_ptr &p). This will prevent unnecessary bumps of the refcount. - If you have an inner loop copying a lot of pointers around, you can dereference the shared_ptr's to raw pointers. This is 100% safe provided that the shared_ptr continues to exist in the meantime. I would consider this an optimization and…

> In function signatures, use const references: foo(const std::shared_ptr &p). This will prevent unnecessary bumps of the refcount. This advice doesn't seem quite right to me, and in my codebases I strictly forbid passing shared_ptr by const reference. If you don't need to share ownership of bar, then you do the following: foo(const bar&); If you do need to share ownership of bar, then you do the following: foo(std::…

> Why do we pass by value when sharing ownership? Because it allows for move semantics, so that you give the caller to option to make a copy, which bumps up the reference count, or to entirely avoid any copy whatsoever, which allows transfering ownership without bumping the reference count.

What if the callee sometimes wants to get a reference count and sometimes doesn't? In the latter case, your proposed signature forces an unnecessary pair of atomic reference count operations. But if you use

    foo(bar const&)
instead, then foo can't acquire a reference even when it wants to.

You could stick std::enable_shared_from_this` under `bar`. But `std::enable_shared_from_this` adds a machine word of memory, so you might not want to do that.

If you pass

    foo(shared_ptr const&)
you incur an extra pointer chase in the callee. Sure, you could write

    foo(bar const&, shared_ptr const&)
but then you burn an extra argument register. You can't win, can you?

You can win actually. Just use https://www.boost.org/doc/libs/1_85_0/libs/smart_ptr/doc/htm... or your favorite intrusive reference-counted smart pointer, not `std::shared_ptr`. If you do, you get the same capabilities that `std::enable_shared_from_this` grants but without any of the downsides.

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

#142

Post by doovd »

atomicnumber3 wrote: post #135
Maxatar wrote: post #101

Earlier quoted context omitted.

As someone who does quant trading professionally and game development as a hobby, they both are performance sensitive, but they emphasize different kinds of performance. Trading is about minimizing latency while video games are about maximizing bandwidth. Video games try to cram as much work as possible within about 16 milliseconds whereas for most trading algorithms 16 milliseconds is too slow to do anything, you wa…

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

> obviously good trades

Are you able to expand with any examples of this?

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

#143

Post by nickelpro »

hawk_ wrote: post #139
nickelpro wrote: post #87

Earlier quoted context omitted.

On the software side I don't think HFT is as special a space as this paper makes it out to be.[1] Each year at cppcon there's another half-dozen talks going in depth on different elements of performance that cover more ground collectively than any single paper will. Similarly, there's an immense amount of formal literature and textbooks out of the game development space that can be very useful to newcomers looking fo…

What other low latency projects in public domain are worth learning from?

Whatever is relevant to the domain you're tackling. How you structurally approach latency in a web server is different than a 3D renderer, which is different than an audio stack, etc. All of those domains have great open source or source available code to learn from, but it wouldn't be useful for me to say "go read HAProxy" if you're never going to touch an HTTP packet. When I'm tackling a problem the first thing I do is research everything everyone else has done on the problem and read their code, benchmark it if possible, and steal all the good ideas.

The basic principles never change. Avoid copies, never allocate, keep the hot path local, and really, good codebases should be doing these things anyway. I don't code any differently when I'm writing a command line argument parser vs low-latency RPC servers. It's just a matter of how long I spend tweaking and trying to improve a specific section of code, how willing I am to throw out an entire abstraction I've been working on for perf.

In the domain of web stuff, effectively all the major load balancers are good to study. HAProxy, nginx, Envoy. Also anything antirez has ever touched.

Application servers are also interesting to study because there's many tricks to learn from a piece of software that needs to interface with something very slow but otherwise wants to be completely transparent in the call graph. FastWSGI is a good example.

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

#144

Post by winternewt »

I made a C++ logging library [1] that has many similarities to the LMAX disruptor. It appears to have found some use among the HFT community.

The original intent was to enable highly detailed logging without performance degradation for "post-mortem" debugging in production environments. I had coworkers who would refuse to include logging of certain important information for troubleshooting, because they were scared that it would impact performance. This put an end to that argument.

[1] https://github.com/mattiasflodin/reckless

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

#145

Post by mgaunard »

nickelpro wrote: post #87
mbo wrote: post #84

Earlier quoted context omitted.

Out of interest, do you have any literature that you'd recommend instead?

On the software side I don't think HFT is as special a space as this paper makes it out to be.[1] Each year at cppcon there's another half-dozen talks going in depth on different elements of performance that cover more ground collectively than any single paper will. Similarly, there's an immense amount of formal literature and textbooks out of the game development space that can be very useful to newcomers looking fo…

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.

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

#146

Post by throwaway2037 »

bb88 wrote: post #97
throwaway2037 wrote: post #82

Earlier quoted context omitted.

In my experience: Allocation is OK, but garbage collection is bad.

I think back then GC defaulted running potentially at allocation. shared_ptr is a much better solution for garbage collection. One I wish that java had implemented.

    > shared_ptr is a much better solution for garbage collection. One I wish that java had implemented.
I'm pretty sure there is a large body of (computer science) research work around the topic of deterministic (reference-counted) vs non-deterministic (non-reference counted) garbage collection. There are lots of pros and cons for both sides. Also, I find it interesting that Java, C#, and GoLang all chose non-deterministic GC, but Perl and Python use deterministic GC. (I'm not sure what Ruby does.)

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

#147

Post by mgaunard »

atomicnumber3 wrote: post #135
Maxatar wrote: post #101

Earlier quoted context omitted.

As someone who does quant trading professionally and game development as a hobby, they both are performance sensitive, but they emphasize different kinds of performance. Trading is about minimizing latency while video games are about maximizing bandwidth. Video games try to cram as much work as possible within about 16 milliseconds whereas for most trading algorithms 16 milliseconds is too slow to do anything, you wa…

"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.

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

#148

Post by au8er »

doovd wrote: post #142
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…

> obviously good trades Are you able to expand with any examples of this?

If every other exchange is selling $AAPL at $100 and suddenly the top level of one exchange drops to $99, then if you just take out that order you basically gain a free dollar. Do this very fast and have pricing the product accurately and you will print tons of money.

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

#149

Post by spacechild1 »

Maxatar wrote: post #68
worstspotgain wrote: post #67

Earlier quoted context omitted.

Here's how to maximize shared_ptr performance: - In function signatures, use const references: foo(const std::shared_ptr &p). This will prevent unnecessary bumps of the refcount. - If you have an inner loop copying a lot of pointers around, you can dereference the shared_ptr's to raw pointers. This is 100% safe provided that the shared_ptr continues to exist in the meantime. I would consider this an optimization and…

> In function signatures, use const references: foo(const std::shared_ptr &p). This will prevent unnecessary bumps of the refcount. This advice doesn't seem quite right to me, and in my codebases I strictly forbid passing shared_ptr by const reference. If you don't need to share ownership of bar, then you do the following: foo(const bar&); If you do need to share ownership of bar, then you do the following: foo(std::…

> If you don't need to share ownership of bar, then you do the following: > > foo(const bar&);

Exactly!

> This advice doesn't seem quite right to me, and in my codebases I strictly forbid passing shared_ptr by const reference

There is at least one use case I can think of: the function may copy the shared_ptr, but you want to avoid touching the reference count for the (frequent) case where it doesn't. This is an edge case, though, and personally I almost never do it.

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

#150

Post by mgaunard »

doovd wrote: post #142
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…

> obviously good trades Are you able to expand with any examples of this?

The idea for aggressive orders in HFT is to buy before the market goes up, and sell before the market goes down.

HFT signals are about detecting those patterns right before they occur, but as early as the information is available globally. For example someone just bought huge amounts of X, driving the price up, and you know Y is positively correlated to X, so Y will go up as well, so you buy it before it does.

X and Y might be fungible, correlated mechanically or statistically.

You can also do it on Y=X as well; then what you need is the ability to statistically tell whether a trade will initiate/continue a trend or revert. You only need to be right most of the time.

Post reply on HN