5 ms·
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
by dcolkitt 6y ago
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.
- cashewchoo 6y agoFWIW, 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.
- gpderetta 6y agoThe 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?
- bitcharmer 6y agoIt 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.
- bitcharmer 6y agoYup, 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.
- bitcharmer 6y agoAgreed, 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 https://stackoverflow.com/a/38298326/1278647
- dcolkitt 6y agoWell, my point is that in C++ objects can be allocated on the stack.
- bitcharmer 6y agoJava can allocate on the stack too or perform partial allocation of exploded objects thanks to escape analysis.
- dcolkitt 6y agoThanks, didn't know that. Will have to look into it.
- DrBazza 6y ago> 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.
- bitcharmer 6y ago> 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.
- DrBazza 6y agoAgreed. 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.