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

111–120 of 240 posts

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

#111

Post by [deleted] »

alchemist1e9 wrote: post #95
FredPret wrote: post #42

Earlier quoted context omitted.

If one outlawed / disincentivized hostile the bot behavior you described, there would still be the opportunity to do the good and profitable things I described.

These commenters have no clue what they are talking about. You don’t need to worry about hostile behaviors in the way they claim. These HN individuals are not domain educated and are spouting highly uninformed nonsense. Silly ideas like market orders take liquidity and limit orders provide it show an extremely rudimentary familiarity with only basic terminology of the field and with no understanding of the extremely…

[deleted]

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

#112

Post by nickelpro »

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…

Casey's a fundamentalist, in the religious extremist sense. Just as a theologian might have something to learn from the most extremely devout, so it is that there is valuable information in Casey's proselytizing.

But you should no more follow Casey in form and function than you would any other fundamentalist.

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

#113

Post by lifeformed »

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.

Just from an energy perspective, I'm pretty sure HFT uses many orders of magnitude less energy than bitcoin mining.

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

#114

Post by ssfrr »

Maxatar wrote: post #101
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…

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…

I'm curious how HFT relates to pro audio programming. The timescale is close to gaming (usually It's not hard real-time like you're going to crash your car, but if you miss your deadline it causes an unacceptable and audible glitch.

I've always been a bit surprised that Jane Street uses OCaml. I know they've put a lot of attention into the GC, but it still seems fundamentally indeterminate in a way that would make most audio devs nervous.

[1]: http://www.rossbencina.com/code/real-time-audio-programming-...

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

#115

Post by _aavaa_ »

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…

I have not watched Handmade Hero, so I can't offer any comments any their comments based on factual claims about the software. A few things though:

I am not linking to handmade hero, I'm linking to a separate project of his (his performance aware programming course) that is actually aimed at being an educational piece.

I lied, I will comment on one factual piece. "normal library code in favour of hand-rolling your own half-baked implementations based on outdated trivia." Yes, that is the whole point of the series (not the characterization as half-based and outdated trivia). The point was to show how to build a game (and its engine) from scratch to as big of a degree as possible. The avowing of library code is the point, to show what it takes to build engines rather than call a library so that the industry has more people who would even attempt doing such a thing.

Equally anecdotally, based on available online information, he worked for a long time on core technologies at RAD Game tools, a company which essentially every gamer, expect maybe pure mobile gamers, has purchased a game that used their technology. It may be possible that he acts (or acted in HMH) based on outdated trivia and favoured premature unfounded optimization, but I find it hard to believe based on the content of his I've engaged with and his track record.

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

#116

Post by alchemist1e9 »

rramadass wrote: post #107
alchemist1e9 wrote: post #95

Earlier quoted context omitted.

These commenters have no clue what they are talking about. You don’t need to worry about hostile behaviors in the way they claim. These HN individuals are not domain educated and are spouting highly uninformed nonsense. Silly ideas like market orders take liquidity and limit orders provide it show an extremely rudimentary familiarity with only basic terminology of the field and with no understanding of the extremely…

> These HN individuals are not domain educated and are spouting highly uninformed nonsense. Yeah, this is highly frustrating particularly for people like me who don't know anything about the domain i.e. HFT/Trading and would like to know more. Can you recommend some good introductory books/resources ?

I might be biased for some almost personal reasons, however I think there is one book that anyone serious about the field should just read, period.

“Trades, Quotes and Prices”

Authors:

Jean-Philippe Bouchaud, Capital Fund Management, Paris, Julius Bonart, University College London, Jonathan Donier, Capital Fund Management, Martin Gould, CFM - Imperial Institute of Quantitative Finance.

I’m a practitioner and this book is foundational.

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

#117

Post by worstspotgain »

CyberDildonics wrote: post #106
worstspotgain wrote: post #96

Earlier quoted context omitted.

> What? The context you're missing is in your post's GP. That poster holds a std::shared_ptr (for whatever perfectly valid reason) and wishes to pass it to foo(). However, he declares it as foo(const bar &) because the callee does not need to share in the ownership of the shared_ptr. That means it gets called as foo(*p.get()). > scope based ownership That's the incorrect assumption that you came to. Obviously if bar…

The context you're missing is in your post's GP. I didn't miss any of that, that exactly what I thought it meant. I just don't know what you mean by precisely wish to bar ownership That's the incorrect assumption that you came to. Prove it. In a single threaded program with scope based ownership, that shared_ptr is going to be freed somewhere, so why not just have it exist in that scope as a unique_ptr so the ownersh…

> I just don't know what you mean by precisely wish to bar ownership

If foo() doesn't need to share ownership now but may need to later, declaring it as foo(const std::shared_ptr &) instead of foo(const bar &) allows this change without revising any prototypes. However, if we precisely wish to prohibit shared ownership by foo(), we can do so by declaring it as foo(const bar &).

> Prove it. In a single threaded program with scope based ownership

The incorrect assumption that you came to is that we were talking about stack variables. But anyways, here's an example that's both scope-based and single threaded:

   std::vector > v;
with an algorithm that selectively adds our pointer to the vector one or more times, and another that duplicates and removes elements according to some ongoing criteria. The object gets deleted when no pointer instances are left in the vector.

In practice most code is multithreaded (not that it matters) and most shared_ptrs are held inside other objects (not that it makes a difference either.)

> Are you saying I'm wrong then saying the exact thing I just said?

I'm saying you misunderstood and now I clarified again. I'm at the troll-detection threshold, so this is my last clarification. Take care!

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

#118

Post by a_t48 »

Maxatar wrote: post #108
a_t48 wrote: post #70

Earlier quoted context omitted.

If you _maybe_ need to share ownership, the second is a little pessimistic - you always increase the ref count.

That is correct and I can see that being a justification for passing a const&, in fact the C++ Core Guidelines agree with you that such a scenario is the only acceptable reason for passing a shared_ptr by const&, although they encourage passing by value, or just passing a const T&.

Obviously the correct way is to accept a templated type and use perfect forwarding. /s /s /s /s /s

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

#119

Post by a_t48 »

CyberDildonics wrote: post #106
worstspotgain wrote: post #96

Earlier quoted context omitted.

> What? The context you're missing is in your post's GP. That poster holds a std::shared_ptr (for whatever perfectly valid reason) and wishes to pass it to foo(). However, he declares it as foo(const bar &) because the callee does not need to share in the ownership of the shared_ptr. That means it gets called as foo(*p.get()). > scope based ownership That's the incorrect assumption that you came to. Obviously if bar…

The context you're missing is in your post's GP. I didn't miss any of that, that exactly what I thought it meant. I just don't know what you mean by precisely wish to bar ownership That's the incorrect assumption that you came to. Prove it. In a single threaded program with scope based ownership, that shared_ptr is going to be freed somewhere, so why not just have it exist in that scope as a unique_ptr so the ownersh…

Not sure if this is what GP was getting at, but in games a shared pointer (or similar custom resource handle) to something like a texture can be very useful - you want to share resources between objects in the scene so that you don't load a thing from disk when it's already in memory, but don't want to hold onto it forever to save RAM.

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

#120

Post by worstspotgain »

a_t48 wrote: post #118
Maxatar wrote: post #108

Earlier quoted context omitted.

That is correct and I can see that being a justification for passing a const&, in fact the C++ Core Guidelines agree with you that such a scenario is the only acceptable reason for passing a shared_ptr by const&, although they encourage passing by value, or just passing a const T&.

Obviously the correct way is to accept a templated type and use perfect forwarding. /s /s /s /s /s

Bonus points for using static_cast(p) instead of std::forward(p) ;)
Post reply on HN