Announcement

Collapse
No announcement yet.

OpenJDK 8/11 vs. GraalVM 20 vs. Amazon Corretto JVM Benchmarks

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

  • #11
    Originally posted by cynical View Post

    Yeah exactly. I can't wait for it to catch up, not just for better performance with functional Java, but for other languages on the JVM like Scala, Kotlin, and Clojure.
    I love Clojure the language, but the startup time is awful.

    On the other hand, you can connect a REPL to a running Clojure program and add and remove running code on the fly. That's really handy for development and runtime debugging. I'm 99% sure that if you compile Clojure to native with GraalVM you would lose that.

    Comment


    • #12
      Originally posted by tildearrow View Post

      Because I thought GraalVM was like a full compiler for Java...
      No, it's a new virtual machine for Java. It CAN do AOT compilation, but that's actually slower than JIT compilation. The reason Java can perform equally to C or C++ (albeit with far higher memory consumption) is because it is able to do optimizations at runtime that are impossible for the former. (which lets it be more aggressive)

      Originally posted by Michael_S
      Graal gives you much faster startup and much smaller file size (since it only bundles what you use and not the entire Java standard library). But it only uses on garbage collector instead of the four or more (?) that are available in the JVM and can't do runtime optimizations like the JVM.
      It can do runtime optimizations. Think of it as a replacement for HotSpot.

      Comment


      • #13
        Originally posted by cynical View Post

        No, it's a new virtual machine for Java. It CAN do AOT compilation, but that's actually slower than JIT compilation. The reason Java can perform equally to C or C++ (albeit with far higher memory consumption) is because it is able to do optimizations at runtime that are impossible for the former. (which lets it be more aggressive)



        It can do runtime optimizations. Think of it as a replacement for HotSpot.
        I think that Graal can be used to build native executables (under certain circumstances).
        In this case you can just optimize code when compiling not at runtime as HotSpot does.

        Comment


        • #14
          Originally posted by cynic View Post

          I think that Graal can be used to build native executables (under certain circumstances).
          In this case you can just optimize code when compiling not at runtime as HotSpot does.
          Sure but some Java specific OOP optimizations are quite hard to do at compile time since you can't figure out how the program will behave at runtime. Ok, you could do PGO, but it's not the same.

          Comment


          • #15
            Originally posted by Michael_S View Post

            I love Clojure the language, but the startup time is awful.

            On the other hand, you can connect a REPL to a running Clojure program and add and remove running code on the fly. That's really handy for development and runtime debugging. I'm 99% sure that if you compile Clojure to native with GraalVM you would lose that.
            Or,... switch to golang (after/when it gets generics), incremental compilation is ultra-fast, and startup time almost instant, assuming there are no I/O depending blocking tasks on startup... If golang had got generics, there's nothing missing for me, from Java world, well, except a bit more mature ecosystem and amount of stable libraries,...

            Comment


            • #16
              Originally posted by kravemir View Post
              For example, when delivering SaaS, where every customer has got separate virtualized/dockerized instance, and load per customer is only ~5%, then having native binary, instead of JIT execution in JVM, will make RAM usage much lower,... And that reduces costs a lot,...
              Do you happen to have any numbers of the Graal memory consumption?

              Comment


              • #17
                Originally posted by caligula View Post

                Do you happen to have any numbers of the Graal memory consumption?
                I never went through the hassle to setup/install graal myself,... I had some intentions in past, as I've made CLI app based on picocli,... So, numbers I know are only, what I had read in articles / blog posts. And, it's pretty impressive improvement regarding memory usage and startup times. Graal would need some build/run/install ecosystem improvement. For example, go compiles to native code, but CLI usage/ecosystem is as convenient, as it is for various scripting languages.

                Comment


                • #18
                  Originally posted by tildearrow View Post
                  I thought GraalVM was going to be much faster than that...
                  A lot of people do. Some of the think of the native image actually, which is an entirely different beast. But GraalVM itself is quite young. So far it's a miracle it works correctly. Performance I expect will take several more years to figure out.

                  Also, while I understand why Michael always tests using default settings, in this case the GC can make or break a JVM. And it's not like people are going to production using default settings. These are not your average desktop users. I understand it's probably not worth testing each GC available, but it would have been nice if only one was used throughout.

                  Also, for bonus points, Java 6 was generally faster then 8

                  Comment


                  • #19
                    Originally posted by bug77 View Post
                    Also, while I understand why Michael always tests using default settings, in this case the GC can make or break a JVM. And it's not like people are going to production using default settings. These are not your average desktop users. I understand it's probably not worth testing each GC available, but it would have been nice if only one was used throughout.
                    Actually,... usually, the only setting, which gets manually changed, is maximum heap size. Beyond that, I haven't seen yet much tweaking of default settings (for JVM itself, not application specific configuration).

                    Comment


                    • #20
                      Originally posted by kravemir View Post

                      Actually,... usually, the only setting, which gets manually changed, is maximum heap size. Beyond that, I haven't seen yet much tweaking of default settings (for JVM itself, not application specific configuration).
                      You can certainly do that, but those that do, don't care about performance to begin with
                      I mean, just look at all the criticism around Go, precisely because its GC does its own thing with no way to be told otherwise.

                      Edit: I get why there are instances where you don't change the default GC: the default is selected to cover a good chunk of the use cases out there. Therefore, if you don't see a java app specifically selecting a GC, it doesn't automatically mean that no one has looked at GC performance; they may just concluded the default works best for them.
                      Last edited by bug77; 26 March 2020, 11:30 AM.

                      Comment

                      Working...
                      X