Live data from Hacker News

Graal and Truffle could accelerate programming language design

medium.com

11–20 of 204 posts

Re: Graal and Truffle could accelerate programming language design

#11
The Oracle flavors of the JVM/JDK probably scare too many away with regards to redistribution of their product. That coupled with the fact that things like the AOT engine is closed source and the weight of the JVM for anything besides daemons (both mentioned towards the end of the article) probably keep language designers away these days.

I would love a lightweight toolkit that made for easy language development. VMKit[0] is dead, MicroVM[1] is a nice idea but not full fledged. Many like myself looking to implement a toy language would love to be fast out of the gate and would rather not mess with the OS-specific constructs and specifics of LLVM IR. So we end up cross-compiling to existing languages or marrying ourselves to a certain runtime (e.g. the CLR). Any other lightweight VMs or AOT compilers that are cross-platform that language designers can use these days?

0 - http://vmkit.llvm.org/ 1 - http://microvm.github.io/

Re: Graal and Truffle could accelerate programming language design

#12
post #9
post #5

Earlier quoted context omitted.

> The TruffleC engine is roughly competitive with GCC It is not surprising in sense Java is competitive to C/C++ as per many Java developers.

I work with .NET, Java and C++ stacks. In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. The biggest issue is of course than one needs to learn how to optimize code, use the right algorithms and data structures in first place.

I agree mostly. Any Java application which does not need GUI other than web is just fine in most use cases.

Re: Graal and Truffle could accelerate programming language design

#14

The Oracle flavors of the JVM/JDK probably scare too many away with regards to redistribution of their product. That coupled with the fact that things like the AOT engine is closed source and the weight of the JVM for anything besides daemons (both mentioned towards the end of the article) probably keep language designers away these days. I would love a lightweight toolkit that made for easy language development. VMK…

Graal/Truffle is not a proprietary part of the JDK, i.e. it's also part of OpenJDK. The article mentions this.

Some tangential things mentioned are proprietary though.

Re: Graal and Truffle could accelerate programming language design

#15

The Oracle flavors of the JVM/JDK probably scare too many away with regards to redistribution of their product. That coupled with the fact that things like the AOT engine is closed source and the weight of the JVM for anything besides daemons (both mentioned towards the end of the article) probably keep language designers away these days. I would love a lightweight toolkit that made for easy language development. VMK…

Also sometime back there use to be OpenJDK maxine VM project which is gone and now an option of closed source SubstrateVM appeared.

It may be unlikely but Oracle can simply remove highly paid staff from above mentioned projects and put in some closed source alternative/analogous projects. Open source project may then be left to rot. As it is almost every single developer on Graal etc is Oracle labs or Oracle funded research group at university.

Re: Graal and Truffle could accelerate programming language design

#16
post #10

There are a lot of weasel words for the other languages, but the comment about ruby is extremely interesting: "For example, the TruffleJS engine which implements JavaScript is competitive with V8 in benchmarks. The RubyTruffle engine is faster than all other Ruby implementations by far. The TruffleC engine is roughly competitive with GCC."

I believe those benchmarks are for throughput, though. JS VM startup times (including v8) are highly optimized, while Graal+Truffle run on the JVM which is more optimized for sustained speed. JS VMs also tend to have multiple tiers for that reason - interpreter, baseline, and full JIT, etc. - while AFAIK the Graal+Truffle/JVM approach has just 2 (which is optimal for Java, but not for startup times of JavaScript and…

Startup times are mostly important for scripting or running things in the browser. If you start applications once on the server or desktop and keep them running then steady-state performance is more important.

There also are projects underway to bring AOT compilation / caching of compiled code to the JVM. Right now they're only available to commercial customers due to their experimental nature and the needed support but if I remember the talk correctly they're supposed to be added to openjdk eventually

Re: Graal and Truffle could accelerate programming language design

#17
There's actually a fairly long history of cross-language VMs, with various degrees of success. What usually happens is that they work fine for languages that look, semantically, basically like the native language on the VM. So LLVM works well as long as your language is mostly like C (C, C++, Objective-C, Rust, Swift). Parrot works if you language is mostly like Perl 6 (Perl, Python, PHP, Ruby). .NET works if your language is mostly like C# (C#, F#, Boo, IronPython). The JVM works if your language is mostly like Java (Java, Clojure, Scala, Kotlin). Even PyPy has frontends for Ruby, PHP, Smalltalk, and Prolog.

"Mostly" in this case means semantically, not syntactically. It's things like concurrency model; floating point behavior; memory layout; FFI; semantics of basic libraries; performance characteristics; and level of dynamism. You can write a Python frontend for both the JVM and CLR, and it will look like Python but act like Java and .NET, respectively, with no guarantee that native CPython libraries will work on it.

The problem is that this is where basically all the interesting language-design research is. I wouldn't use Rust for the syntax; I'd use it because I want properties like complete memory safety, manual control over memory allocation, easy (and fast!) access to C libraries, and short startup time. These are all things that Truffle explicitly does not deliver.

It's a great tool if you work in the JVM ecosystem and want to play around as a language designer. But most of the interesting languages lately have created their own ecosystems, and they succeed by solving problems so fundamental that people will put up with having to learn a new ecosystem to gain the benefits they offer.

Re: Graal and Truffle could accelerate programming language design

#18

The Oracle flavors of the JVM/JDK probably scare too many away with regards to redistribution of their product. That coupled with the fact that things like the AOT engine is closed source and the weight of the JVM for anything besides daemons (both mentioned towards the end of the article) probably keep language designers away these days. I would love a lightweight toolkit that made for easy language development. VMK…

check out RPython.

Re: Graal and Truffle could accelerate programming language design

#19

The Oracle flavors of the JVM/JDK probably scare too many away with regards to redistribution of their product. That coupled with the fact that things like the AOT engine is closed source and the weight of the JVM for anything besides daemons (both mentioned towards the end of the article) probably keep language designers away these days. I would love a lightweight toolkit that made for easy language development. VMK…

I think we should start to see post-Java9 a less resource intensive JVM, even more so with Java10. The problem boils down to if there exists an alternative ecosystem that is going to be as featureful and as powerful in the meantime. I am bullish on Oracle here, as much as I hate to say it

Re: Graal and Truffle could accelerate programming language design

#20

There are a lot of weasel words for the other languages, but the comment about ruby is extremely interesting: "For example, the TruffleJS engine which implements JavaScript is competitive with V8 in benchmarks. The RubyTruffle engine is faster than all other Ruby implementations by far. The TruffleC engine is roughly competitive with GCC."

Chris Seaton gave this talk recently about JRuby+Truffle and some specifics about how it optimises so well compared to other Ruby implementations. https://youtu.be/b1NTaVQPt1E Previous discussion https://news.ycombinator.com/item?id=12062454

Chris is also reasonably active here.

I've had the pleasure of discussing some of his jRuby work with him in the past (I occasionally plod along with own Ruby compiler in Ruby - it's nowhere near complete) and they've done a lot of impressive work to demonstrate how compiling Ruby into fast code is largely about assuming people will behave sanely (e.g. people won't usually give Fixnum#+ side-effects, or make it return weird stuff), but add fallbacks for when they do.

This is the big challenge with Ruby: The subset of Ruby that people actually tend to work in is largely very predictable and possible to compile efficiently, but there's a lot of stuff around the fringes that people expect to work on the very rare occasions that we use it.

Post reply on HN