Announcement

Collapse
No announcement yet.

GraalVM 20.2 Released With Compile Time Improvements, Better Error Reporting

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • elatllat
    replied
    https://www.reddit.com/r/java/commen...image_vs_rust/

    Leave a comment:


  • Sin2x
    replied
    GraalVM keeps all the important optimizations to its Enterprise Edition only. Oracle is Oracle is Oracle. I'm rooting for OpenJ9, it's all open.

    Some JVM comparisons from the presentation there : https://youtu.be/fcy7xzAbII4
    Last edited by Sin2x; 08-30-2020, 08:04 AM.

    Leave a comment:


  • bug77
    replied
    Originally posted by cynical View Post

    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.

    Leave a comment:


  • cynical
    replied
    Originally posted by bug77
    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.

    Leave a comment:


  • bug77
    replied
    Originally posted by aksdb View Post

    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.

    Leave a comment:


  • caligula
    replied
    Originally posted by aksdb View Post

    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).

    Leave a comment:


  • caligula
    replied
    Originally posted by CochainComplex View Post
    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.

    Leave a comment:


  • aksdb
    replied
    Originally posted by bug77 View Post

    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.

    Leave a comment:


  • bug77
    replied
    Originally posted by caligula View Post

    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.

    Leave a comment:


  • CochainComplex
    replied
    Originally posted by caligula View Post

    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.

    Leave a comment:

Working...
X