Hacker News Reader

Comment by dcolkitt | Hacker News Reader

> any excess latency that Java introduces into your software is likely to be much smaller than existing latency sinks, such as network communication delays, in (at least)

In a co-located datacenter with high performance network equipment this isn't true at all. The time from my CPU to a kernel bypass NIC to a cut-through switch to the exchange's FPGA gateway is in the low single-digit microseconds.[1][2]

[1]https://www.eurexchange.com/resource/blob/48918/ba7e2c5900f1... [2]https://www.arista.com/en/products/7150-series-network-switc... [3]https://technologyevangelist.co/2015/11/04/1-44-microseconds...

View on HN

> The time from my CPU to a kernel bypass NIC to a cut-through switch to the exchange's FPGA gateway is in the low single-digit microseconds

Single digit microsecond latency is also what you should expect from a well written market data gateway or a fix engine. Java definitely competes with C++ in this space.

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.

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.

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.

Thanks, this makes sense.

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

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.

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.

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

Furthermore, if all your competitors have to incur the same fixed latency, then this is irrelevant. Just because one system is 200mics and another is 201mics doesn’t mean the 201mic one is good enough. HFTs are competing on what they can control, because if that trade comes with 199mics of network latency, it means the first firm will make a good trade every time, and the second will be shut out.

This is true, but also misses a bigger point: in the particular case of low latency trading, once everyone has similarly fast network infrastructure, the only place left to improve is the time spent executing the algorithm on the CPU. Certainly not all strategies are so latency-sensitive, but for those that are, even a small speed difference there can have a significant economic impact.

Reply on news.ycombinator.com