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

221–230 of 240 posts

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

#221

Post by chipdart »

roblatham wrote: post #200
fsloth wrote: post #194

Earlier quoted context omitted.

”covered countless times in textbooks” What’s your favourite textbook on the subject?

it's an oldie but _Advanced Compiler Design and Implementation_ covers these concepts really well in a language-independent way.

I don't think so. For instance, one basic technique in low-latency C++ is running specific code periodically even with no-op parameters just to keep it warm in the cache.

It's one thing to claim that you can cherry pick some directly or indirectly pieces of information from an unrelated source. It's another entirely different thing to claim that unrelated source is an authoritative reference in an unrelated field, specially when no one recognizes it as such.

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

#222

Post by chipdart »

Aurornis wrote: post #192
chipdart wrote: post #154

Earlier quoted context omitted.

> Fairly trivial base introduction to the subject. Might be, but low-latency C++, in spite of being a field on its own, is a desert of information. The best resources available at the moment on low-latency C++ are a hand full of lectures from C++ conferences which left much to be desired. Putting aside the temptation to grandstand, this document is an outstanding contribution to the field and perhaps the first author…

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

> I don't know how you arrive at this conclusion.

I am well aware of this fact because I've researched the topic and I can state it without any degree if uncertainty. The only and resources there are scattered loose notes and presentations in conferences such as Timur Doulmer's work for C++ On Sea, and even so he's clear on how his work is mainly focused on real-time audio processing, which has different requirements than say HFT.

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

Go ahead and cite the absolute best example you can come up from this incredible list of yours. The very top of your list will suffice to evaluate your whole list. I'll wait.

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

#223

Post by Aurornis »

chipdart wrote: post #222
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…

> I don't know how you arrive at this conclusion. I am well aware of this fact because I've researched the topic and I can state it without any degree if uncertainty. The only and resources there are scattered loose notes and presentations in conferences such as Timur Doulmer's work for C++ On Sea, and even so he's clear on how his work is mainly focused on real-time audio processing, which has different requirements…

> Go ahead and cite the absolute best example you can come up from this incredible list of yours. The very top of your list will suffice to evaluate your whole list. I'll wait.

This could really do without the "incredible list of yours" and "I'll wait" snark. You don't need to be so condescending, but for the sake of helping others who are actually curious about the subject:

https://www.agner.org/optimize/ is a great place to start that I link to frequently.

It has significantly more breadth than the small collection of techniques in the paper linked in this post. It doesn't have the "HFT" buzzword attached, but then again the techniques in the linked paper above aren't unique to HFT either.

There are also several books on the subject, but given that the above link is a good place to start and the resources are freely available, that's where I'd recommend you look.

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

#224

Post by affyboi »

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.

Why shouldn’t people be allowed to do both? I don’t see much of an advantage to making the markets less agile.

It would be nice to be able to buy and sell stocks more than once a quarter, especially given plenty of events that do affect the perceived value of a company happen more frequently than that

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

#225

Post by affyboi »

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.

Brokers are required to give you NBBO or better. You could set up a direct connection to an exchange if you were willing to pay and were sufficiently motivated to deal with all of that

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

#226

Post by affyboi »

foobazgt wrote: post #129
FredPret wrote: post #57

Earlier quoted context omitted.

You mean like settling trades every 0.25 seconds or something like that? Wouldn't there be a queue of trades piling up every 0.25 seconds, incentivizing maximum speed anyway?

Usually the proposal is to randomize the processing of the queue. So, as long as your trades get in during the window, there's no advantage to getting in any earlier. In theory the window is so small as to not have any impact on liquidity but wide enough to basically shut down all HFT.

How would that work? Would you randomly select a single order posted, go by market participant (like randomly select some entities that posted a trade in this window), and would you allow prices to move during this window?

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

#227

Post by affyboi »

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.

The exchanges already charge fees per order https://www.nyse.com/publicdocs/nyse/markets/nyse-arca/NYSE_...

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

#228

Post by FooBarBizBazz »

astromaniak wrote: post #14
bravura wrote: post #10

Earlier quoted context omitted.

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.

> Warren Buffett proposed that the stock market should be open less frequently This will result in another market where deals will be made and then finalized on that 'official' when it opens. It's like with employee stock. You can sell it before you can...

> It's like with employee stock. You can sell it before you can...

I thought that this was explicitly forbidden in most SV employment contracts? "Thou shalt not offer your shares as collateral or (I forget the exact language) write or purchase any kind of derivative to hedge downside.' No buying PUTS! No selling CALLs! No stock-backed loans!

Or do people make secondary deals despite this, because, well, the company doesn't know, does it?

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

#230

Post by matheusmoreira »

nickelpro wrote: post #83

Fairly trivial base introduction to the subject. In my experience teaching undergrads they mostly get this stuff already. Their CompArch class has taught them the basics of branch prediction, cache coherence, and instruction caches; the trivial elements of performance. I'm somewhat surprised the piece doesn't deal at all with a classic performance killer, false sharing, although it seems mostly concerned with single-…

> allocations, copies, and other performance killers

Please elaborate on those other performance killers.

Post reply on HN