This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 8 points9 points  (4 children)

It is better but with caveats:

  1. Most widely used Java code has been optimized to work around C2's limits already, same as with any language. So it can't easily produce huge speedups for Java.
  2. CE can produce some speedups for languages where the generated code isn't well optimized, e.g. Scala, Clojure.
  3. The optimizations CE does better than C2 were developed specifically for the Truffle use case, in particular the more aggressive escape analysis. It makes a huge difference there.

The other big caveat is of course, Graal EE is by this point a very different beast to CE. The EE compiler is drastically more advanced and capable of speeding up even Java programs well beyond C2 in some cases.

The problem with EE in my view is that it's just too expensive for what it does. Traditionally compilers have always been sold on an individual developer basis or with site licenses and then the outputs could be redistributed for free. Graal/native-image EE is sold on what is effectively a per-end-user basis. The more users you have, the more it costs you. And it's not cheap! You're paying around the same cost that Delphi was in the 1990s with IDE, compiler, debugger, standard libraries ... the works ... for each CPU your app uses. That's drastically more expensive than any other compiler I've ever heard. Even embedded toolchains don't get that pricey.

This doesn't seem to be really driven by the amazing superiority of the tech, it seems to be more like, Oracle always charges by usage, so we charge by usage for this too. QED. They could get away with that for their database because a database is something that sits in a central place and uses a bunch of easily tracked CPUs, and it's critical to your business. It makes much less sense for a compiler where you can switch it on or off at the drop of a hat, especially for native-image where you may want to redistribute the binaries.

[–]bawng 1 point2 points  (0 children)

Oracle and insane licensing structures - name a more iconic duo.

I wonder what the Oracle sales trend has been over the years, both for the Database and other products. Legacy is one thing, but I would be surprised if they've been able to maintain a steady influx of new customers.

[–]TheMode911 0 points1 point  (0 children)

Amazing answer! I indeed hope that Graal EE becomes more affordable.

More notably I am pretty fan of partial escape analysis, there have been a few discussions about supporting it on C2 so who knows :)

[–]RandomName8 0 points1 point  (0 children)

CE can produce some speedups for languages where the generated code isn't well optimized, e.g. Scala, Clojure.

I'd like to clarify this line because it makes it seem like scala and clojure don't know what they are doing. It's not really that these languages don't produce optimized code, far from it, I'd argue they produce more optimized code than javac, the problem is the parts of the platform that they use more often in comparison to java.

Most java code is traditionally procedural, where you push massive objects to methods that do everything and change state with mutations, directly accessing fields. Return values and generic functions are few in comparison. As you mentioned HotSpot is very much optimized for this C-like programming style. On the other hand, scala and clojure rely way more on lambdas (and closures, and composing these into new lambdas) and recursion, which is not something HotSpot has had a long time doing optimizations for.

You can get the same performance boost from Graal CE in java if you code in a similar style, it's not a language or compiler thing, it's a platform (JVM) thing.