> 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)<p>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]<p>[1]<a href="https://www.eurexchange.com/resource/blob/48918/ba7e2c5900f1069bc04f4785b15783eb/data/presentation_insights-into-trading-system-dynamics_en.pdf" rel="nofollow">https://www.eurexchange.com/resource/blob/48918/ba7e2c5900f1...</a>
[2]<a href="https://www.arista.com/en/products/7150-series-network-switch-datasheet" rel="nofollow">https://www.arista.com/en/products/7150-series-network-switc...</a>
[3]<a href="https://technologyevangelist.co/2015/11/04/1-44-microseconds-full-round-trip-latency-unlikely/" rel="nofollow">https://technologyevangelist.co/2015/11/04/1-44-microseconds...</a>
> Well, C++ might be “low latency” when it comes to executing code, but it’s definitely not low latency when it comes to rolling out new features or even finding devs who can write it.<p>Every time one of these articles roll around it's always the same point. At the end of the day some systems actually do need low-latency in real time and you will be steamrolled by competitors if it is not.
For my, possibly limited, personal experience writing trading systems, fighting UB in C++ is not even in the top 10 of the issues you have to deal with. The vast majority of the problems are business level issues.<p>C++ also allows expressing complex concepts in types without overhead (can you have price abstraction in java with no overhead? Can you write an efficient fix point numeric type? Can you post lambdas between threads without memory allocations?).
> Well, C++ might be “low latency” when it comes to executing code, but it’s definitely not low latency when it comes to rolling out new features or even finding devs who can write it.<p>Yikes, this article is terrible.
> You just need to write it like C++, with memory management in mind at each stage of development.<p>Having worked on a 'low latency' trading system written in Java, this is true. Ultimately you end up using a flyweight pattern over shared memory, and you have to be aware of alignment and cache sizes. Then there are other tricks like zero GC, or pushing the collection back to once a day.<p>You also spend a fair amount of time analyzing performance to the nanosecond looking for, and eliminating, jitter.<p>I've also written the same in C++, and it's a similar exercise, along with dashes of [[unlikely]], template specialization, and far too much time inside godbolt.org looking at assembler to see if gcc/clang has "optimized" something in the latest release.
Well I did trading systems in both of these, and I think it's much more natural to do it in C++.<p>The thing about banks doing systems in Java doesn't really convince me, the times I was facing a Java engine it didn't really matter how fast the thing was, due to the particular thing we were doing. (Not everything is a speed race).<p>The thing about C++ is you get ultimate control, but you have to use it. For instance if you just write a dummy application where you populate a hashmap and pull out some values, it's easy to do this slower than a managed solution, because C++ allows you to leave out the allocator, meaning you end up using a default one that isn't so great. On the surface it will look like any old hashmap, because if you've looked at a few languages that kind of thing will tend to look like `map<mytype>` in most languages, but there's actually a way to say `map<mytype, myallocator>` in C++.<p>I find it's actually easier to perf debug c++ than managed languages. With managed, you end up having to think about how the GC works, and the GC is actually not a very simple piece of software. You can sidestep the GC, but then you're not in a very idiomatic Java. There's a bunch of extra rules you have to adhere to.
Almost every point of significance in this article was subjective. You can go low-level and faster in Java as easily as you can go high-level, safer and slower in modern Cpp.
> 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.<p>If you do that, you lose on a lot of stuff in C++ that supports that. For example, destructors/RAII make managing memory resources a lot better. Tooling like Valgrind, ASan, etc make it easier to find issues in your memory management. With Java, you don’t have those. The vast majority of Java is written with GC in mind, and when you go off the beaten path and do memory management on your own, you won’t have the language features and tools to support you, making it harder to do than in C++.
> People who enjoy coding in C++ (all three of them)<p>I have coded both in Java and C++. I enjoy coding in C++, and I detest with a passion coding in Java.
I've read some many of these Java is actually better/faster/lighter than you think articles; I now always expect Java to be the right choice whenever I see a headline like that..
Because of the domain name, I expected this to be a quality blog post from the stackoverflow engineering team--they always have good content.<p>But this website appears to be a place for free-lance writers to post articles of somewhat lesser quality. I wonder what happened? Appears the Engineering Blog is now here: <a href="https://stackoverflow.blog/engineering/" rel="nofollow">https://stackoverflow.blog/engineering/</a>
What the author is describing is not a “low latency system” with regards to finance. That term is used to describe a system that will successfully make a trade that is regarded as a good trade at the time of a signal. For example, if an order comes in to sell XYZ, and Optiver/Citadel/Virtu all want to buy it, a low latency system is one where you can buy that order at least some of the time.<p>In one sense, the author is right that C++ based systems do not suffice to trade that order, but he is very wrong that Java ones do.<p>His justification that banks use Java is not compelling. Morgan Stanley is the only bank that is remotely competitive technologically. And his justification that dev time is faster on Java is just ridiculous. It’s even faster on Python, but we aren’t talking about dev time. We’re talking about building systems that can reliably execute ingress-egress in less than a microsecond. Even using kernel bypass cards and assembly doesn’t get you there. So, no, Java isn’t a good choice for low latency systems.
Reads like "I cannot code C++ but Java. Therefore Java is better!". Okay, probably I'm one of the three developers enjoying coding with C++ and therefore biased?<p>The JVM and especially the GC are the definition of undefined behavior. You don't know what happens, when it happens and how it happens. When GC is working fine your likely doing okay, if not - good luck.
Are there numbers on this topic? Without it, an article it's just fluff. And the previous article on the C4 was the same.<p>The articles from Azul are supposed to be a "goldmine". I've randomly opened two of them:<p>- <a href="https://www.azul.com/low-latency-effect-application-performance/" rel="nofollow">https://www.azul.com/low-latency-effect-application-performa...</a><p>- <a href="https://www.azul.com/garbage-collection-application-performance-impact/" rel="nofollow">https://www.azul.com/garbage-collection-application-performa...</a><p>and laughably, they recycle the same (stock) diagram, which, by the way, has no unit on the Y axis.<p>I'd love to see a GC that is as high-performing as manual memory management. But all these articles are meaningless without numbers (and a rigorous methodology).
Maybe someone has more "real" experience than me on this, but the article says :<p>> Since IDE support for Java is much more advanced than for C++, most environments (Eclipse, IntelliJ, IDEA) will be able to refactor Java. This means that most IDEs will allow you to optimize code to run with low latency, a capability that is still limited when working with C++.<p>He cites IntelliJ IDEA as a powerful Java IDE, but JetBrains does have a C++ IDE which is quite advanced (CLion) and whose refactor function always impressed me. I'm sure Visual Studio has some pretty impressive refactoring capabilities by itself or with JetBrains plugins. Is it really that bad and I've just not worked on large enough projects ?
I thought this related thread was interesting with discussion about Java in the HFT space <a href="https://news.ycombinator.com/item?id=12051442" rel="nofollow">https://news.ycombinator.com/item?id=12051442</a>
This is a terrible article, no actual data, lots of qualifying adjectives.<p>However, even though at heart I still feel like a C++ programmer since I started my career before Java existed, I actually end up using C or C++ less and less. I started transitioning to C# (which I equate somewhat with Java) and Python for small projects but I'm finding that I'm spending most of my time there.<p>Things I still do in C or C++:<p>- embedded systems (small memory footprint, no MMU)<p>- OS-like work<p>- numerical algortihms, especially anything with pixel data or large matrices (the good stuff stitched together with Python code)<p>Unexpectedly, I don't miss manual memory management at all but still sometimes want something closer to RAII.
These HFT folks should really write a book on this. Writing in Java the traditional OO way doesn't work for extreme-performance. And there are way too many tricks that the everyday programmer simply doesn't know.
Java can be written with no garbage collection.
1. Pool the business objects and create them all ahead of time. Restore them to the pool after a thread uses them.<p>2. Create a String pool and use == for equality checks.<p>3. Avoid Java constructs that create temporary iterators.<p>for (i = 1, size=myList.size(); i<size; i++)<p>creates no iterator whereas<p>for (Object obj : myList)<p>does. You employ a profiling tool to find the garbage-creating sections of Java code and rewrite them.<p>I know of a wall street trade matching engine that operates with no pauses for garbage collection that uses these techniques.
>Well, C++ might be “low latency” when it comes to executing code, but it’s definitely not low latency when it comes to rolling out new features or even finding devs who can write it.<p>It's certainly fast when adding more useless template trickery to the language instead of fixing real problems with it. I wish people never found out that templates are turing-complete.
Why would I ever use Java for high-performance anything when C# is a better feeling language with native memory management support?<p>Edit: the author’s <i>entire</i> point is his claim (never backed up) that Java is better at optimizing away less-used branches in code. OpenMP lets the programmer do exactly that with C++, if the C++ compiler isn’t already superior.