3 ms·

The open source version of Graal does not have poor performance, by any means. It's more or less as good as regular Java, or better for some languages, but it's

The open source version of Graal does not have poor performance, by any means. It's more or less as good as regular Java, or better for some languages, but it's not really worse except perhaps on a few specific microbenchmarks. Moreover, GraalVM is open source. Please don't try and redefine basic terms, as otherwise by your logic Linux would be shareware because Red Hat sell a better version of it, Android would be shareware, Chromium would be shareware etc. Making an open source product and selling a better version that isn't is perfectly legit. If you don't believe that, how do you envision platforms be funded? As for the pricing, it is or was on their online shop. You could buy it with a credit card. Seems they have a problem with their store right now, but I've seen public price lists in the past. It's expensive but not at all "if you have to ask you can't afford it".

mumblemumble 6y ago
From what I've seen, it's only the small benchmarks where the open source version of Graal is on par with regular Java, because their short run-time ensures that all the bits that give HotSpot its name don't have a chance to kick in. I think my point stands regardless of any quibbling about terminology. I've got no objection to some sort of free-however-you-capitalize-it-but-with-paid-premium-features model in general. But baking such a business model into something as fundamental as a cross-platform ABI standard sets a really bad precedent. Having lived through the late '90s, that sort of thing immediately brings the phrase, "embrace, extend, extinguish," to mind. I'm glad to hear they've started publishing a sticker price. My memory isn't what it used to be, but I believe that wasn't the case when I evaluated it.
- thu2111 6y ago
  Are you mixing up Graal the JIT compiler with Native Image the tool that spits out ahead-of-time compiled executables? When I say "Graal" I mean the JIT compiler that can run on regular HotSpot and is just an ordinary Java JITC implemented in Java. You have to distinguish between technical standards and implementations. JVM bytecode is a technical standard for a portable, cross platform, strongly typed ABI. Anyone can implement it based on the docs. Truffle is an open source API with a clear specification for creating interpreters. Anyone can implement it based on the docs, although there's no reason to do so given its permissive licensing. Beyond that it's all implementation: the Graal JIT recognises when it's compiling Truffle interpreters and does it in a fast way, but it doesn't have to and Truffle interpreters can run on any JVM including those that pre-date Truffle's own existence. They just won't be as fast. GraalVM EE is a for-pay version that does an even better job, well beyond state of the art, but the open source free version is no slouch and Scala code can go faster by e.g. 20% or more even with the open source version. There is ALSO the native-image tool that compiles things to native code ahead of time. Many people use the word Graal to mean this, because it's the most eye-catching thing in the suite, but that's not correct. It's called either native-image or SubstrateVM. The open source version of this produces code which is slower than regular HotSpot runs but has no warmup time and starts instantly. The speed drop is due to losing profile guided and speculative optimisations, it's not a pricing issue. The EE version of native-image that you pay for has various other features like the ability to gather profiles using HotSpot and then use them when compiling to win back some of the speed, but not all of it - you can't really beat Graal JITC on HotSpot for peak performance. The EE version also has some other useful features for security and sandboxing. In other words, the Java/Oracle guys seem to be doing exactly what you'd want to see: there are standards, specifications and then implementations - all clearly separated. There are open source implementations, and better ones with support contracts that fund the development of the whole shebang.

mumblemumble 6y ago

From what I've seen, it's only the small benchmarks where the open source version of Graal is on par with regular Java, because their short run-time ensures that all the bits that give HotSpot its name don't have a chance to kick in. I think my point stands regardless of any quibbling about terminology. I've got no objection to some sort of free-however-you-capitalize-it-but-with-paid-premium-features model in general. But baking such a business model into something as fundamental as a cross-platform ABI standard sets a really bad precedent. Having lived through the late '90s, that sort of thing immediately brings the phrase, "embrace, extend, extinguish," to mind. I'm glad to hear they've started publishing a sticker price. My memory isn't what it used to be, but I believe that wasn't the case when I evaluated it.

thu2111 6y ago
Are you mixing up Graal the JIT compiler with Native Image the tool that spits out ahead-of-time compiled executables? When I say "Graal" I mean the JIT compiler that can run on regular HotSpot and is just an ordinary Java JITC implemented in Java. You have to distinguish between technical standards and implementations. JVM bytecode is a technical standard for a portable, cross platform, strongly typed ABI. Anyone can implement it based on the docs. Truffle is an open source API with a clear specification for creating interpreters. Anyone can implement it based on the docs, although there's no reason to do so given its permissive licensing. Beyond that it's all implementation: the Graal JIT recognises when it's compiling Truffle interpreters and does it in a fast way, but it doesn't have to and Truffle interpreters can run on any JVM including those that pre-date Truffle's own existence. They just won't be as fast. GraalVM EE is a for-pay version that does an even better job, well beyond state of the art, but the open source free version is no slouch and Scala code can go faster by e.g. 20% or more even with the open source version. There is ALSO the native-image tool that compiles things to native code ahead of time. Many people use the word Graal to mean this, because it's the most eye-catching thing in the suite, but that's not correct. It's called either native-image or SubstrateVM. The open source version of this produces code which is slower than regular HotSpot runs but has no warmup time and starts instantly. The speed drop is due to losing profile guided and speculative optimisations, it's not a pricing issue. The EE version of native-image that you pay for has various other features like the ability to gather profiles using HotSpot and then use them when compiling to win back some of the speed, but not all of it - you can't really beat Graal JITC on HotSpot for peak performance. The EE version also has some other useful features for security and sandboxing. In other words, the Java/Oracle guys seem to be doing exactly what you'd want to see: there are standards, specifications and then implementations - all clearly separated. There are open source implementations, and better ones with support contracts that fund the development of the whole shebang.