Comment by AlotOfReading
4 hours ago
I don't know what it is that Rust demonstrates given that few large scale projects have chosen it, but I've seen nothing to indicate that it doesn't suffer from the same performance issues as C++ compared to Java.
The point of bringing up Rust is that it also gives the compiler much more information to optimize on than C++, but actual performance is comparable or slightly worse in most benchmarks because the quality of C++ codegen is so high. Some of those Rust advantages are exactly the same things that have been touted as major advantages for Java over C++, like escape analysis and lifetimes.
Of course, in principle it's always possible to match and perhaps even exceed Java's performance in a low-level language, but in practice it becomes ever more difficult as the program grows (and the cost remains with maintenance forever).
Sure, which is why I asked for real examples of whatever you consider a "large scale" program. I wasn't able to find anything via search before I replied, and the wiki page on Java performance [0] is repeating what I understood.
> Some of those Rust advantages are exactly the same things that have been touted as major advantages for Java over C++, like escape analysis and lifetimes.
These aren't the biggest advantages. I would say that the biggest ones are aggressive speculative optimisations that allow inlining of virtual calls (by default, up to a depth of 15 calls) and the ability to freely move pointers, which allows alternatives to free-list-based memory management. Low-level languages can't afford pervasive speculative optimisation (as they're focused on the worst case) and can't allow most of their pointers to be moved (because they often share them directly with the hardware and/or device drivers).
> and the wiki page on Java performance [0] is repeating what I understood.
That may be because the information on that page seems to be up to date to 2011-2. Java is now on version 26, BTW.
LLVM does speculative devirtualization as well these days, though it's not as aggressive as Hotspot. High-performance native code tries to avoid deep dynamic hierarchies anyway, so it's mitigated by cultural practices.
GCs are definitely a strong point for Java, but most high-performance code can be rewritten to avoid pummeling memory management. This used to be common for Java in financial applications, not sure if it still is.
C++ has evolved its own compacting GCs like oilpan [0] for applications where high performance is inherently tied to allocation. Oilpan runs into pointer issues and isn't remotely comparable to G1GC or ZGC, but I think the speed of V8 speaks for itself. Rust allows you to drop in non free-list based allocators and GCs (e.g. Bumpalo), but they're relatively immature.
The last time I dove into JVM internals was around the same time. I figured that someone who's worked with it more recently might have better examples than what's easily searchable.
[0] https://chromium.googlesource.com/v8/v8/+/main/include/cppgc...
> LLVM does speculative devirtualization as well these days, though it's not as aggressive as Hotspot. High-performance native code tries to avoid deep dynamic hierarchies anyway, so it's mitigated by cultural practices.
Sure, AOT compilation also didn't stand still, and overall I'd say that Java and low level languages are closer today than they were 20 or even 10 years ago on all fronts: both have improved in areas where they were behind.
> This used to be common for Java in financial applications, not sure if it still is.
Given that low-latency collectors are only 3 years old, I'm sure some existing Java applications still do it, but new ones no longer need to (and it may turn out to be counterproductive with the new collectors)
> Rust allows you to drop in non free-list based allocators and GCs (e.g. Bumpalo), but they're relatively immature.
The problem isn't so much the immaturity, but the integration with the standard library that requires significant code changes (e.g. you need to use different string and collection implementations). However, even where there is good integration - as in the case of Zig - arenas impose limitations that make the program less flexible. But yes, when all the stars are aligned, arenas can beat moving collectors (that's about the only thing that can), but moving collectors aren't standing still and resting on their laurels, either.
> I figured that someone who's worked with it more recently might have better examples than what's easily searchable.
I don't know about a single unified resource, but you can find everything here: https://openjdk.org/jeps/0
JIT improvements are usually too low-level to merit a JEP, but all the major GC changes are there. For a taste of what's going on in the JIT these days, see this recent talk: https://youtu.be/J4O5h3xpIY8
Slightly off topic -- java-related wiki pages are notoriously bad and possibly biased for some reason. They are laughably outdated and have a bunch of non-objective sentences that paint a much worse picture of the language than deserved.
I have even tried removing/rewriting some of the questionable sentences but my edits weren't accepted.