Hacker News Reader

Comment by dcolkitt | Hacker News Reader

I'm not saying it's impossible for JVM to compete at the level. But you definitely don't get O(5 uSec) performance out of the box. The author is trying to argue that language considerations are irrelevant, because network latencies are orders of magnitude higher. That may be true for web networking, but it's definitely not true for HFT networks.

If you hit a GC pause or have to do heap allocation or don't vectorize a calculation because you're not running native code, it all costs way more than the network stack. Again, I'm not saying that there aren't techniques to deal with that in Java. But what I am saying is that you can't just ignore those issues, like the author seems to suggest.

View on HN

> But you definitely don't get O(5 uSec) performance out of the box.

Tick-to-trade? The first version of our trading system in Java, had this level of performance in the first version.

> If you hit a GC pause or have to do heap allocation

We ended up running the code through profiler on our CI system which would fail the build if it detected any potential paths of GC. Object pools and flyweights everywhere.

> We ended up running the code through profiler on our CI system which would fail the build if it detected any potential paths of GC. Object pools and flyweights everywhere

Pretty standard practice in HFT Java, but the GP correctly points out this is not idiomatic Java.

Agreed. From the article:

> In other words, it’s possible to write Java, from the machine level on up, for low latency. You just need to write it like C++, with memory management in mind at each stage of development.

That's the tl;dr for the whole article.

Agreed, low latency Java is very far from standard Java programming.

> or have to do heap allocation

FYI, heap allocation in Java is much cheaper (~11 cycles) than in C++ as it's just a bump-the-pointer in TLAB.

https://stackoverflow.com/a/38298326/1278647

Well, my point is that in C++ objects can be allocated on the stack.

Java can allocate on the stack too or perform partial allocation of exploded objects thanks to escape analysis.

Thanks, didn't know that. Will have to look into it.

FWIW, there's actually a large amount of industry experience in ultra-low-latency Java kicking around the ATS/exchange/HFT space. Island's ECN was Java, and that incubated a lot of this kind of talent.

It's absolutely not your everyday java (I've heard the answer to "how do you handle gc's" is just "don't allocate memory") but it's a Thing.

Yup, Java is common among low-latency-ish market makers like Goldman Sachs, UBS, HSBC, Morgan Stanley and others.

Edit: since I'm being down-voted for this comment - I worked in all the above banks on low-latency Java projects. That you don't like the language/runtime doesn't change the facts.

The question is, one you are no longer writing anything close to idiomatic java, does the (sketchy) argument that Java is easier to write than C++ still holds?

It still is as there's plenty of non-low-latency related stuff that you still need from the ecosystem such as portability, dependency management, common libraries and utilities, debuggers, profilers, etc.

but if any of those common libraries allocate short lived objects, doesn't that ruin things?

Thanks, this makes sense.

Reply on news.ycombinator.com