GraalVM 20.2 Released With Compile Time Improvements, Better Error Reporting

[caligula]

nope but I have already started to investigate. IMHO Javas weakest point but unavoidable by the concept is(was) the low performance. Best example Android Phones before JIT and AoT Compilation tweaks.

Keep in mind the hardware was a lot slower before ART (Android 6?). Phones typically had only 1 or 2 ARMv6 cores. I've tried reflashing old phones with more recent Androids and those actually seem much slower on the old phones. Other than that, many Android apps are actually built using native C++.

Comparing desktop OpenJDK, Graal, and Android Java isn't all that simple since the typical use cases differ quite a bit. Graal even has all kinds of problems compiling desktop apps due to reflection. All Java packages need to provide hints in the package metadata for Graal to tell how to include reflective accesses at compile time.

[caligula]

It can't. Java is obese by design. But that is no problem. Back the in the Renaissance people found fat women sexy. I think it was a sign of being wealthy. And many do so today. They are called architects.

Is that so? Would love to see few examples of this bloat.

[CochainComplex]

Keep in mind the hardware was a lot slower before ART (Android 6?). Phones typically had only 1 or 2 ARMv6 cores. I've tried reflashing old phones with more recent Androids and those actually seem much slower on the old phones. Other than that, many Android apps are actually built using native C++.

Comparing desktop OpenJDK, Graal, and Android Java isn't all that simple since the typical use cases differ quite a bit. Graal even has all kinds of problems compiling desktop apps due to reflection. All Java packages need to provide hints in the package metadata for Graal to tell how to include reflective accesses at compile time.

That is also true and should not be underestimated. But I remember that time when I was using a lot of Physics Software tools based on Java (at least the UI) Matlab, Comsol, Maple, etc back 10 years ago and even on decent hardware it was slow not snappy (the UI not the engine). This was also true for a lot of other small tools based on java.
Sure the software didn't care if I'm on Linux, Mac or Win (have used all of them at that time) and it looked all alike which can be nice.
But it was not snappy compared to e.g. QT based UI's. I'm rather sensitive to this...Im still always complaining about the not responsive "Command Centers" in modern (Premium) cars.

Comming back to old phones. Have you tried to compare flagship android phones vs iOS devices with comparable specs? Btw this was the only thing I liked about the windows phones. Even with mediocre hardware the UI felt very smooth and fast. So yes Hardware today is much more powerfull - but thats not the only explanation.

Recompiling drm and mesa with more aggressive flags can lead to improved snappiness on Linux Desktop environments too. Inspite of the already fast hardware under the hood.

[bug77]

Is that so? Would love to see few examples of this bloat.

I've seen this with some number crunching. Go was about 10x as fast as Java. Rust was about 10x as fast as Go. It's probably a worst case scenario, but it's there.

[aksdb]

I've seen this with some number crunching. Go was about 10x as fast as Java. Rust was about 10x as fast as Go. It's probably a worst case scenario, but it's there.

Not to defend Java (I try to avoid it where possible), BUT that sounds like you might have been doing it wrong. If you just start a Java process and start measuring, you will not get a good representation of what the JVM is capable of. It needs a few iterations on your code before it has decided on a hot path and applied the necessary optimizations.

That is also, why Java is/was good in the "old days", where you start a JVM process which can take over the whole machine and keeps running for weeks or months. If, however, you throw away JVM processes and spawn them anew as you do with Kubernetes or similar, then the whole "warmup" and "learning" process is horribly wasted and cumbersome.

[caligula]

Comming back to old phones. Have you tried to compare flagship android phones vs iOS devices with comparable specs? Btw this was the only thing I liked about the windows phones. Even with mediocre hardware the UI felt very smooth and fast. So yes Hardware today is much more powerfull - but thats not the only explanation.

iOS is definitely faster on the same class of hardware. It's difficult to tell if the slow response time is due to the Java VM or bad framework design.

[caligula]

Not to defend Java (I try to avoid it where possible), BUT that sounds like you might have been doing it wrong. If you just start a Java process and start measuring, you will not get a good representation of what the JVM is capable of. It needs a few iterations on your code before it has decided on a hot path and applied the necessary optimizations.

That is also, why Java is/was good in the "old days", where you start a JVM process which can take over the whole machine and keeps running for weeks or months. If, however, you throw away JVM processes and spawn them anew as you do with Kubernetes or similar, then the whole "warmup" and "learning" process is horribly wasted and cumbersome.

Also according to benchmarks Java is indeed somewhat slower than native code (10x sounds feasible) when doing number crunching, but 100x slowdown sounds quite unlikely unless the C/C++ code is heavily utilizing AVX512. Even purely interpreted R/Python frameworks aren't that slow (Although nowadays even R uses JIT IIRC).

[bug77]

Not to defend Java (I try to avoid it where possible), BUT that sounds like you might have been doing it wrong. If you just start a Java process and start measuring, you will not get a good representation of what the JVM is capable of. It needs a few iterations on your code before it has decided on a hot path and applied the necessary optimizations.

That is also, why Java is/was good in the "old days", where you start a JVM process which can take over the whole machine and keeps running for weeks or months. If, however, you throw away JVM processes and spawn them anew as you do with Kubernetes or similar, then the whole "warmup" and "learning" process is horribly wasted and cumbersome.

Oh believe me, I know about JIT and all that. Java pays my bills. But that doesn't stop me from keeping an eye on the bigger picture
I should probably revisit that test and try native image. That will tell me how much of the slowness is built into the design and how much comes from the JRE implementation.

[cynical]

I've seen this with some number crunching. Go was about 10x as fast as Java. Rust was about 10x as fast as Go. It's probably a worst case scenario, but it's there.

Java numerics are not 10x slower than Go. How would that even be possible? Maybe if you had some unintended boxing going on.

[bug77]

Java numerics are not 10x slower than Go. How would that even be possible? Maybe if you had some unintended boxing going on.

I was surprised, too, but numbers don't lie (pun intended). No boxing, but I had some trigonometrical and power functions in there.