Comment by xondono
1 day ago
And here we get into the absurdity of microbenchmarks like these.
Yes, you can get the JVM to crunch some numbers relatively fast, particularly if the operations are repetitive enough that you can pull JIT tricks.
Now try to run something that looks a bit more like an actual application and less like a cherry picked example, and as soon as you start moving memory around the gap jumps to orders of magnitude.
> and as soon as you start moving memory around the gap jumps to orders of magnitude.
Depends on what you mean by "moving memory". In terms of heap allocation performance, the JVM and I suspect the JS engine will end up trouncing C/C++. Why? Because a GC allocator will outperform manual memory management in terms of absolute allocation rate. Because memory for a C++ allocator is pinned, unless you do a bunch of work utilizing things like bump allocators you'll simply flounder in terms of what the JVM does by default.
All(?) of the JVM GCs are moving collectors. That means new allocation ends being a simple pointer bump with a bounds check. Really hard to beat in terms of perf.
But it doesn't stop there. If we are talking real applications, then one real thing the JVM does better than C++ is concurrent programming. A GC works far better for managing concurrent data. So much so that when you look at high performance multithreaded C++ code you'll often find a garbage collector implementation. Something that Java gets by default. If you aren't google writing chrome, you are either aggressively copying memory or you are using something like atomic reference counters. Both of which will absolutely nuke performance.
But that's not all. One other thing the JVM does better than C++ can generally hope to do is devirtualization. In real applications, you are likely either in template hell for C++ to get performance or you are dealing with some form of interfaces and inheritance which ultimately creates code that the compiler will struggle to optimize without going to an extreme like PGO. The JVM gets PGO for free because it doesn't have to blindly optimize methods.
These simple microbenchmarks are a gift to C/C++, not the JVM.