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

21–30 of 240 posts

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

#21

Post by sesuximo »

jeffreyrogers wrote: post #18
globular-toast wrote: post #5

Is there any good reason for high-frequency trading to exist? People often complain about bitcoin wasting energy, but oddly this gets a free pass despite this being a definite net negative to society as far as I can tell.

Bid/ask spreads are far narrower than they were previously. If you look at the profits of the HFT industry as a whole they aren't that large (low billions) and their dollar volume is in the trillions. Hard to argue that the industry is wildly prosocial but making spreads narrower does mean less money goes to middlemen.

Why do high spreads mean more money for middlemen?

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

#22

Post by Arnt »

sesuximo wrote: post #21
jeffreyrogers wrote: post #18

Earlier quoted context omitted.

Bid/ask spreads are far narrower than they were previously. If you look at the profits of the HFT industry as a whole they aren't that large (low billions) and their dollar volume is in the trillions. Hard to argue that the industry is wildly prosocial but making spreads narrower does mean less money goes to middlemen.

Why do high spreads mean more money for middlemen?

When you buy stock, you generally by it from a "market maker", which is a middleman. When you sell, you sell to a market maker. Their business is to let you buy and sell when you want instead of waiting for a buyer/seller to show up. The spread is their profit source.

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

#23

Post by pi-rat »

globular-toast wrote: post #5

Is there any good reason for high-frequency trading to exist? People often complain about bitcoin wasting energy, but oddly this gets a free pass despite this being a definite net negative to society as far as I can tell.

Generally gets attributed with:

- Increased liquidity. Ensures there's actually something to be traded available globally, and swiftly moves it to places where it's lacking.

- Tighter spreads, the difference between you buying and then selling again is lower. Which often is good for the "actual users" of the market.

- Global prices / less geographical differences in prices. Generally you can trust you get the right price no matter what venue you trade at, as any arbitrage opportunity has likely already been executed on.

- etc..

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

#24

Post by sesuximo »

Arnt wrote: post #22
sesuximo wrote: post #21

Earlier quoted context omitted.

Why do high spreads mean more money for middlemen?

When you buy stock, you generally by it from a "market maker", which is a middleman. When you sell, you sell to a market maker. Their business is to let you buy and sell when you want instead of waiting for a buyer/seller to show up. The spread is their profit source.

Wouldn’t the price movement overwhelm the spread if you sell more than a few days after you buy? I guess if spreads were huge it would matter more

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

#25

Post by Arnt »

bravura wrote: post #10
globular-toast wrote: post #5

Is there any good reason for high-frequency trading to exist? People often complain about bitcoin wasting energy, but oddly this gets a free pass despite this being a definite net negative to society as far as I can tell.

Warren Buffett proposed that the stock market should be open less frequently, like once a quarter or similar. This would encourage long-term investing rather than reacting to speculation. Regardless, there are no natural events that necessitate high-frequency trading. The underlying value of things rarely changes very quickly, and if it does it's not volatile, rather it's a firm transiton.

AIUI the point of HFT isn't to trade frequently, but rather to change offer/bid prices in the smallest possible steps (small along both axes) while waiting for someone to accept the offer/bid.

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

#26

Post by Arnt »

sesuximo wrote: post #24
Arnt wrote: post #22

Earlier quoted context omitted.

When you buy stock, you generally by it from a "market maker", which is a middleman. When you sell, you sell to a market maker. Their business is to let you buy and sell when you want instead of waiting for a buyer/seller to show up. The spread is their profit source.

Wouldn’t the price movement overwhelm the spread if you sell more than a few days after you buy? I guess if spreads were huge it would matter more

The price movement does indeed overwhelm the spread. Half the time it goes up, half the time down.

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

#27

Post by JedMartin »

sneilan1 wrote: post #3

I've got an implementation of a stock exchange that uses the LMAX disruptor pattern in C++ https://github.com/sneilan/stock-exchange And a basic implementation of the LMAX disruptor as a couple C++ files https://github.com/sneilan/lmax-disruptor-tutorial I've been looking to rebuild this in rust however. I reached the point where I implemented my own websocket protocol, authentication system, SSL etc. Then I realized…

It's not easy to get data structures like this right in C++. There are a couple of problems with your implementation of the queue. Memory accesses can be reordered by both the compiler and the CPU, so you should use std::atomic for your producer and consumer positions to get the barriers described in the original LMAX Disruptor paper. In the get method, you're returning a pointer to the element within the queue after bumping the consumer position (which frees the slot for the producer), so it can get overwritten while the user is accessing it. And then your producer and consumer positions will most likely end up in the same cache line, leading to false sharing.

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

#28

Post by binary132 »

munificent wrote: post #9

> The noted efficiency in compile-time dispatch is due to decisions about function calls being made during the compilation phase. By bypassing the decision-making overhead present in runtime dispatch, programs can execute more swiftly, thus boosting performance. The other benefit with compile-time dispatch is that when the compiler can statically determine which function is being called, it may be able to inline the…

The real performance depends on the runtime behavior of the machine as well as compiler optimizations. I thought this talk was very interesting on this subject.

https://youtu.be/i5MAXAxp_Tw

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

#29

Post by blakers95 »

jeffbee wrote: post #17
FredPret wrote: post #7

Earlier quoted context omitted.

Non-bitcoin transactions are just a couple of entries in various databases. Mining bitcoin is intense number crunching. HFT makes the financial markets a tiny bit more accurate by resolving inconsistencies (for example three pairs of currencies can get out of whack with one another) and obvious mispricings (for various definitions of "obvious")

That's a nice fairy tale that they probably tell their kids when asked, but what the profitable firms are doing at the cutting edge is inducing responses in the other guys' robots, in a phase that the antagonist controls, then trading against what they know is about to happen. It is literally market manipulation. A way to kill off this entire field of endeavor is to charge a tax on cancelled orders.

Yep and what's worse is many hft firms aren't in the market-making business at all but actually REMOVE liquidity.

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

#30

Post by FredPret »

blakers95 wrote: post #29
jeffbee wrote: post #17

Earlier quoted context omitted.

That's a nice fairy tale that they probably tell their kids when asked, but what the profitable firms are doing at the cutting edge is inducing responses in the other guys' robots, in a phase that the antagonist controls, then trading against what they know is about to happen. It is literally market manipulation. A way to kill off this entire field of endeavor is to charge a tax on cancelled orders.

Yep and what's worse is many hft firms aren't in the market-making business at all but actually REMOVE liquidity.

What's the mechanism for removing liquidity?
Post reply on HN