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?
Graal and Truffle could accelerate programming language design
11–20 of 204 posts
Re: Graal and Truffle could accelerate programming language design
#12Earlier 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.
Re: Graal and Truffle could accelerate programming language design
#13However, I assume one goal of the project is to make the JVM more competitive, which it certainly does.
Re: Graal and Truffle could accelerate programming language design
#14The 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…
Some tangential things mentioned are proprietary though.
Re: Graal and Truffle could accelerate programming language design
#15The 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…
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
#16There 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…
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"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
#18The 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…
Re: Graal and Truffle could accelerate programming language design
#19The 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…
Re: Graal and Truffle could accelerate programming language design
#20There 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
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.