Announcement

Collapse
No announcement yet.

Oracle Ships GraalVM 1.0 To "Run Programs Faster Anywhere"

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

  • #11
    Originally posted by discordian View Post
    How can you not use the heap in Java?
    If the JVM's escape analysis can prove the object doesn't escape, it can be allocated on the stack instead, and if it can prove you never use it in "synchronized (object) {...}", it can even eliminate the "object" and store its fields directly in CPU registers.

    Comment


    • #12
      Originally posted by cthart View Post
      Use it and get lumped with a lawsuit. No thanks.
      lol, you've got it backwards. google was sued for *not* using java and inventing dalvik instead

      Comment


      • #13
        Originally posted by Michael_S View Post
        So finally, 'Hello World' in Java will run exactly as fast as 'Hello World' in C.
        doubtful

        Comment


        • #14
          Eclipse OMR is apache 2, but GraalVM does much more. AOT compilation for the JVM is finally here, after first hearing Android was going get it probably ~5 years ago and Oracle was doing this maybe ~2 yrs ago.

          You can optimize Java using static, and native types; Scala using @specialized and just be careful about using new and var in both respectively. You can get close to 2x-3x slower performance writing even naive code compared to C++ and probably in less than 1/2 the time it took the C++ developer. Figures from this ~6 year old paper: https://research.google.com/pubs/pub37122.html

          The cost of using the heap and getting this performance is 3x the RAM (there is an Uppsala paper on GC/tuning), which GraalVM also reduces. The resource usage figures are more than the jump from assembly to compiled languages, so maybe we're seeing diminishing returns in terms of higher level languages vs. raw performance. But yeah, AOT is a big step for Java/JVM. Embedded Java on something like RPi is looking much better and the ability to run llvm bitcode should be interesting.
          Last edited by audir8; 19 April 2018, 11:37 PM.

          Comment


          • #15
            Originally posted by pal666 View Post
            doubtful
            Not if 'Hello World' in C runs slower under GraalVM and they meet in the middle.

            Comment


            • #16
              Originally posted by jacob View Post

              Good on them for using the GPLv2 but otherwise I say wait and see. I know nothing about the project but judging by the announcement, this sounds actually like some pretty terrible piece of bloatware/hypeware. Software that promises to be all things to everyone has never ever turned out to be any good so far.
              If you read the release posts, you'll see a link to a talk given by Twitter, who have been switching parts of their infrastructure over to leverage Graal. They've seen notable performance improvements from using it. Key part kicks in about here: https://youtu.be/pR5NDkIZBOA?t=25m35s , they're seeing 11% reduction in CPU usage for the same work.

              Taking TruffleRuby, an implementation of ruby leveraging Graal, if you dig through here, you'll see the phenomenal improvements, even compared to JRuby which runs on the JVM: https://medium.com/square-corner-blo...t-91a5c864dd10 "After warming up, TruffleRuby pulls well ahead of the pack with its highly optimized GraalVM JIT. (See also TruffleRuby with SubstrateVM, which significantly improves startup time with only slightly less speed once warmed up.)" You'll see the warmup is really quick, and when you're talking about server side stuff, that warmup is pretty negligible.

              Also: https://pragtob.wordpress.com/2017/0...-a-year-later/ writing a Go AI in Ruby, comparing across multiple different Ruby implementations.

              Comment

              Working...
              X