3 ms·

I’m unaware of HFT systems running entirely on a JVM. Do you know of such cases? Safe Rust isn’t fast enough for HFT in my opinion. What kind of HFT? Amusingly

by jmaker 3y ago

I’m unaware of HFT systems running entirely on a JVM. Do you know of such cases? Safe Rust isn’t fast enough for HFT in my opinion. What kind of HFT? Amusingly, though somewhat tangential, I observed a rather simple Go implementation (nothing fancy, ordinary channel bound message passing) outperform a fairly sophisticated Rust implementation for the same logic when we were toying with a prototype. But that was at an IO boundary. There are many other variables of course, but an amusing anecdote to share.

MrBuddyCasino 3y ago
I will not pretend to have any inside information, I just picked up some of the related discussions on HN over the years. I'll easily believe that it can take significant work to outperform Golang (or Java) in Rust where application complexity is high (not just a simple cmd app), they do have an excellent baseline out of the box.
- jmaker 3y ago
  Definitely, microbenchmarks are what’s most striking especially because they seem immediately approachable, as opposed to a full fledged app with a variety of integrations. In that case the quality of the dependencies is much more important to me than any benchmark runs. Great point, totally agreed. I personally am often quite astonished by the amazing performance Go apps squeeze out of the box, with many efficiency tweaks and tricks we way too often take for granted, which you need to be aware of to come by in C++, Rust, or even Java. But I do also often get disappointed by the sudden inconsistency of that performance in Go after a while, the variance is a bit high, with C++, Rust, and Java runtime behavior being very consistent in general.
pjmlp 3y ago
"Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94 https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-... LMAX Disruptor customers https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ Among many other examples.
- jmaker 3y ago
  Much appreciated indeed. Though I’m unconvinced by that particular piece on Medium. There’s no mention of their purported trading workloads, reads rather like a pile of SEO keywords spiced up by a couple charts and appears more like an attempted product placement for Azul Zing instead of HotSpot Zulu or other distributions. The author doesn’t seem to associate with finance either. I know Disruptor fairly well, it’s been underwhelming.
  - ackfoobar 3y ago
    > I know Disruptor fairly well, it’s been underwhelming. The newer, better thing from the same author is aeron.
kaba0 3y ago
Yes, Java is often used in HFT, due to one being able to quickly modify the algorithm, while keeping it safe and performant. This is used for mostly the algorithms that have to be fast, but not to the degree of “let’s buy this building which is closer to the bank, because the internet cable length matters”. Do note, that for the latter kind, general purpose CPUs (and thus, programming languages) themselves are not fast enough and is dominated by ASICs.

by jmaker 3y ago

MrBuddyCasino 3y ago

I will not pretend to have any inside information, I just picked up some of the related discussions on HN over the years. I'll easily believe that it can take significant work to outperform Golang (or Java) in Rust where application complexity is high (not just a simple cmd app), they do have an excellent baseline out of the box.

jmaker 3y ago
Definitely, microbenchmarks are what’s most striking especially because they seem immediately approachable, as opposed to a full fledged app with a variety of integrations. In that case the quality of the dependencies is much more important to me than any benchmark runs. Great point, totally agreed. I personally am often quite astonished by the amazing performance Go apps squeeze out of the box, with many efficiency tweaks and tricks we way too often take for granted, which you need to be aware of to come by in C++, Rust, or even Java. But I do also often get disappointed by the sudden inconsistency of that performance in Go after a while, the variance is a bit high, with C++, Rust, and Java runtime behavior being very consistent in general.

pjmlp 3y ago

"Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94 https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-... LMAX Disruptor customers https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ Among many other examples.

jmaker 3y ago
Much appreciated indeed. Though I’m unconvinced by that particular piece on Medium. There’s no mention of their purported trading workloads, reads rather like a pile of SEO keywords spiced up by a couple charts and appears more like an attempted product placement for Azul Zing instead of HotSpot Zulu or other distributions. The author doesn’t seem to associate with finance either. I know Disruptor fairly well, it’s been underwhelming.
- ackfoobar 3y ago
  > I know Disruptor fairly well, it’s been underwhelming. The newer, better thing from the same author is aeron.

kaba0 3y ago

Yes, Java is often used in HFT, due to one being able to quickly modify the algorithm, while keeping it safe and performant. This is used for mostly the algorithms that have to be fast, but not to the degree of “let’s buy this building which is closer to the bank, because the internet cable length matters”. Do note, that for the latter kind, general purpose CPUs (and thus, programming languages) themselves are not fast enough and is dominated by ASICs.