All mainstream JVM GCs are compacting, but I agree that without “value” types, an ArrayList for example will point to objects that can hurt performance. But that’s why you profile, if a given part is a hotspot, then you can rewrite it as an array of primitives. But due to compacting, allocating objects randomly in C++ vs in Java, Java will likely win.
And valhalla is coming, and with primitive types, the JVM will have a way for that last piece of performance.
There is an interesting issue on benchmarkgame’s repo, where C# is ahead a bit using a clever trick. It basically halves the required allocations. And Java is insanely close with double the allocations.
I am as much of a Java fanboy as it gets, but football team level love-hate of languages is stupid. Also, this benchmark is not necessarily applicable to reL world programs.
The CLR provides some access to low level primitives, while the JVM rather hides them. The first choice allows for more optimization by the developer, but that will be explicit and will potentially disallow some automatic ones.
Java on the other hand hides most of these details and depends on a very advanced JIT compiler for most optimizations (like escape analysis), in which way even a decade old program will get magically faster. Of course it is only a crude difference between them, with Java getting primitive types, and CLR continuously improving in JIT and GC.
No.
There was an interesting issue.
The clever trick was disallowed and the programs that used the clever trick were removed.
> … insanely close with double the allocations…
No, what you see is not with double the allocations.
The clever trick was disallowed and the programs that used the clever trick were removed.
Read the program source code.
Especially that my whole comment was actually defending C#, even though I’m not particularly fond of it.
That only works when you make little quoting gestures with your fingers.
The problem with Java is that it clearly shies away from more direct memory control, and as a result it's significantly disadvantaged on modern hardware in terms of raw performance.
You may dismiss this and say "but Java is faster than C++ in some cases". In some cases yes, like when you do raw math and don't load and store much state. But handling state efficiently is Java's weak spot. Objects are tiny fragments scattered around the heap.
Look at .NET and C#. Unity can implement architectures like Entity Component Systems, because C# has decided long time ago to be the "Java for everything" and that's precisely what it ended up as. It started as a Java clone, but added some features of C and C++, it has some features of JavaScript and Python, it has everything. EVERYTHING. It even has a native AOT profile, in case you wanna write a kernel driver or an entire OS in C#.
The only thing stopping C# from taking over the world is the association with Windows, I bet, otherwise everything would be C# by now.
As for Java... it FELT completed a decade or two ago. But now, it feels lacking. It's basically become EnterpriseScript. We'll see how Valhalla and Panama pan out, but for now evolution is a bit slow.