8 ms·

An obscure research project could accelerate innovation in language design

133 points by phreeza 10y ago

hacker_9 10y ago
"Graal is designed from the start as a multi-language compiler, but its set of optimisation techniques is especially well suited to compiling programs with high levels of abstraction and dynamism. It runs Java as fast as the existing JVM compilers do, but when applied to Scala programs it runs them about 20% faster. Ruby programs get 400% faster than the best alternative runtime (i.e. not MRI)." Pretty amazing claims being made here, but I do like the idea of it. Build up your language grammar, then get a compiler, debugger and runtime for basically free. Definitely will have to play around with this soon.
lilott8 10y ago
JetBrains has something that is similar to this: MetaProgramming System (MPS)(https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/). It resides exclusively within the context of Java (so DSL) -- so it's not as, shall we say, far reaching as Graal and Truffle claim to be? It works really well though; abstract the complexities of the AST through the use of various different methodologies so that designers can do what they do best, design. The shortcomings, I'd imagine, are the same with MPS in-so-much that the limitations imposed are defined by the system. And when you run into those boundaries, they are hard and unforgiving -- much like trying to use Python in a non-pythonic manner.
- hacker_9 10y ago
  The main problem actually is it only generates projection editors, not text editors. So you interact with the language like an excel spreadsheet, which is pretty awful to be frank.
- mike_hearn 10y ago
  MPS is rather different. I've played with that too, perhaps it should be the topic of another essay. MPS is fascinating because it lets you create non-text based programming languages and have them actually interop with text based programming in a useful way.
nottorp 10y ago
[quote] Graal & Truffle are a product of Oracle Labs, the part of the Java team which does VM and compiler research. [/quote] So if a language using this becomes successful, Oracle will hit you with an intellectual property lawsuit?
- ColanR 10y ago
  It would be really nice to sort that out. This looks like a really useful tool.
  - vorg 10y ago
    That's never going to be sorted out because Oracle intended it that way. Like in 2011, just after they bought Sun, they started bundling payment-required components (e.g. JavaSE Advanced) in their supposedly "free" (as in beer) JavaSE download. Only this year did they start hunting down people who have been using those extra components, with some businesses owing back-charges of $1 million or more to Oracle. See http://www.theregister.co.uk/2016/12/16/oracle_targets_java_users_non_compliance/ http://www.theregister.co.uk/2016/12/16/oracle_targets_java_... Based on past behavior, Oracle intends Graal and Truffle to do the same. Edit: Actually, I suspect the name Graal is a play on JVM-based Grails, which, along with Apache Groovy, has the same culture of drawing users in with false promises then charging them for OCI consulting and G2One conferences to manage the resulting technical debt. Perhaps Graal means Oracle ain't buying theirs, they're building their own.
    - mike_hearn 10y ago
      No, Java SE had commercial features forever and you can't use them accidentally. You have to pass a command line switch called -XX:+UnlockCommercialFeatures. They are free for development use and as such there's no DRM, it works on the honour system. Oracle have simply started stepping up their efforts against people who were, shall we say, not able to handle the honour system. The commercial features aren't relevant to most developers, so it's all a bit of a storm in a teacup. There's certainly no bait and switch.
- 10y ago
pg_is_a_butt 10y ago
obscure? it's run by oracle. heard of them? you're all idiots.
chubot 10y ago
Nice article, especially the section on downsides at the end. A lot of VM design is at the expense of memory consumption over speed. Not just the JVM, but I think v8 memory usage got out of control recently and they had to go back to an interpreter in some cases. VMs in the future should probably be optimized for power. More memory usage means more power usage. It matters both on mobile devices and in data centers. The startup time issue is annoying as well. I like the general idea, but making startup time even worse than the JVM itself makes it unattractive.
- chrisseaton 10y ago
  If you want to reduce the time required to handle an individual request in a given program that you already have there's not much you can do automatically. You can't use a processor that's twice as fast because if you are already using a modern system we don't have one of those. You can't use two processors as we don't really know how to parallelise effectively enough in general cases. But you can double the RAM in a system with reasonable effort and cost. The startup time issue is being solved with ah ahead-of-time Java compiler with whole-world analysis that we are developing. It runs hello-world in our Ruby implementation in about 100ms, which is an order of magnitude faster than the normal JVM.
  - mike_hearn 10y ago
    That's an interesting argument I hadn't considered before.
  - deleted 10y ago
    [deleted]
  - chubot 10y ago
    OK, if those are your design constraints, then that's fair. I'm just questioning how widely those constraints will apply in the future. I'm pretty sure the v8 changes were motivated by phones, so maybe there is room for another project like Graal and Truffle with a different set of constraints. Also, for web services in particular (not sure if that is a major use case), I would question the view of making individual requests faster. I recall Steve Souders said he was a back end guy at Yahoo working on latency, and then he switched to front end performance because he found that the front end was eating up all the time. In my experience this is too true. In other words, if you had a server where requests were taking 100 ms, and you made them take 50 ms through VM design, you would be a hero! But somehow front end engineers are still constructing pages with 10 - 30 full seconds of latency (especially on mobile) out of back end requests that take 100ms. There's just a lot more room to optimize there, whereas sometimes I feel like VMs are trying to squeeze blood out of a stone. And I agree that there will be demand for such a "black box" approach, where you just take an arbitrary program and make it faster. But I'm interested in overall system performance, and in that case, a little bit of application knowledge can work wonders. One of my pet peeves is that often performance tools like time and space profilers are sort of an afterthought that programmers use only when they have problems. They write this huge spagehetti of allocation, and then 2 years later they start tuning the GC. This is partly the fault of programmers and partly the fault of the language ecosystem. It would be nicer if the language exposed integrated tools. I dont' know that much about the JVM ecosystem, but they always feel like a "separate thing" you have to go research and choose and download and install. I think Go's tooling is a good example here. Anyway, I think this is an interesting project. In particular I think the focus on polyglot programming is fantastic. I too feel the pain of enormous amounts of duplicated work -- e.g. even at say Google with a relatively small set of languages like C++, Java, and Python, there were still all these separate "worlds" and gradually engineers became sequestered in their own world. IMO Go made things worse and not better -- it was yet another native runtime that didn't even interoperate all that well with C++, let alone Java or Python!!!
Athas 10y ago
When I think of "innovation in language design", I don't really think of JIT-compiling highly dynamic behaviour. I think of inventing languages with programming models that can be used for programming the heterogeneous hardware of the future (and, well, present). For example, massive parallelism is needed for both GPUs, FPGAs, clusters, and other more exotic systems, and the trick becomes how to translate portable and high-level problem descriptions to, say, highly vectorised code for GPUs, deep FPGA pipelines, or asynchronous message-passing cluster code. You can't solve that with JITs. From what I have seen, JITs are very useful for taking away the overhead of indirect calls and similar dynamic behaviour, but I don't think that's going to be the primary language design challenge of the future. No compiler can (usefully) extract significant amounts of parallelism from an algorithm which has none, and current programming models are not particularly convenient for expressing parallel algorithms. While current languages allow you to express parallelism by using low-level features, the resulting program will invariably be non-portable. High-level parallel languages (or maybe libraries) are the only solution I can see.
- mike_hearn 10y ago
  Actually that's not quite true: https://github.com/pcpratts/rootbeer1 https://github.com/pcpratts/rootbeer1 http://openjdk.java.net/projects/sumatra/ http://openjdk.java.net/projects/sumatra/ There has been work done on automatically identifying and running ordinary JVM hotspots on the GPU. That said, I agree that automatic parallelisation is a hard problem. I don't think it's the only interesting area of language innovation: most of the innovations making programmers lives easier in recent years have nothing to do with it.
  - Athas 10y ago
    Both of those projects look like they are about designing a convenient GPU programming API for Java. Which is fine and useful, but you still have to program with an understanding of the GPU model (notably, massive threading), so it's not quite as high-level as what I believe is needed for portable performance.
    - 10y ago
JackC 10y ago
Previous discussion of this article when it was hosted at Medium: https://news.ycombinator.com/item?id=12122557 https://news.ycombinator.com/item?id=12122557
- mike_hearn 10y ago
  It's actually still hosted by Medium, I just got around to setting up a custom domain as I noticed a few people saying they've learned to associate the medium.com domain with low quality writing. That's a pity, but at least it's easier to move off Medium now when something better comes along (or they go bankrupt).
fritzo 10y ago
Another perspective is that Graal & Truffle prove that a large swath of programming language space is semantically equivalent, suggesting that we shift focus of innovation elsewhere.
gwenzek 10y ago
The question is can you create a language like Scala with it? Ie with complex type inference? Or Haskell? Because if it constrains you to Java like languages, I don't see this as "innovation in language design".
- jerven 10y ago
  This is the execution layer, i.e. how is that Scala program turned into machine code. You can make a Haskell implemented using Truffle. Or Rust etc... Haskell, defines the semantics of a program, while truffle turns that semantics into executable code.

133 points by phreeza 10y ago

"Graal is designed from the start as a multi-language compiler, but its set of optimisation techniques is especially well suited to compiling programs with high levels of abstraction and dynamism. It runs Java as fast as the existing JVM compilers do, but when applied to Scala programs it runs them about 20% faster. Ruby programs get 400% faster than the best alternative runtime (i.e. not MRI)." Pretty amazing claims being made here, but I do like the idea of it. Build up your language grammar, then get a compiler, debugger and runtime for basically free. Definitely will have to play around with this soon.

lilott8 10y ago

JetBrains has something that is similar to this: MetaProgramming System (MPS)(https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/). It resides exclusively within the context of Java (so DSL) -- so it's not as, shall we say, far reaching as Graal and Truffle claim to be? It works really well though; abstract the complexities of the AST through the use of various different methodologies so that designers can do what they do best, design. The shortcomings, I'd imagine, are the same with MPS in-so-much that the limitations imposed are defined by the system. And when you run into those boundaries, they are hard and unforgiving -- much like trying to use Python in a non-pythonic manner.

hacker_9 10y ago
The main problem actually is it only generates projection editors, not text editors. So you interact with the language like an excel spreadsheet, which is pretty awful to be frank.
mike_hearn 10y ago
MPS is rather different. I've played with that too, perhaps it should be the topic of another essay. MPS is fascinating because it lets you create non-text based programming languages and have them actually interop with text based programming in a useful way.

nottorp 10y ago

[quote] Graal & Truffle are a product of Oracle Labs, the part of the Java team which does VM and compiler research. [/quote] So if a language using this becomes successful, Oracle will hit you with an intellectual property lawsuit?

ColanR 10y ago
It would be really nice to sort that out. This looks like a really useful tool.
- vorg 10y ago
  That's never going to be sorted out because Oracle intended it that way. Like in 2011, just after they bought Sun, they started bundling payment-required components (e.g. JavaSE Advanced) in their supposedly "free" (as in beer) JavaSE download. Only this year did they start hunting down people who have been using those extra components, with some businesses owing back-charges of $1 million or more to Oracle. See http://www.theregister.co.uk/2016/12/16/oracle_targets_java_users_non_compliance/ http://www.theregister.co.uk/2016/12/16/oracle_targets_java_... Based on past behavior, Oracle intends Graal and Truffle to do the same. Edit: Actually, I suspect the name Graal is a play on JVM-based Grails, which, along with Apache Groovy, has the same culture of drawing users in with false promises then charging them for OCI consulting and G2One conferences to manage the resulting technical debt. Perhaps Graal means Oracle ain't buying theirs, they're building their own.
  - mike_hearn 10y ago
    No, Java SE had commercial features forever and you can't use them accidentally. You have to pass a command line switch called -XX:+UnlockCommercialFeatures. They are free for development use and as such there's no DRM, it works on the honour system. Oracle have simply started stepping up their efforts against people who were, shall we say, not able to handle the honour system. The commercial features aren't relevant to most developers, so it's all a bit of a storm in a teacup. There's certainly no bait and switch.
10y ago

pg_is_a_butt 10y ago

obscure? it's run by oracle. heard of them? you're all idiots.

chubot 10y ago

Nice article, especially the section on downsides at the end. A lot of VM design is at the expense of memory consumption over speed. Not just the JVM, but I think v8 memory usage got out of control recently and they had to go back to an interpreter in some cases. VMs in the future should probably be optimized for power. More memory usage means more power usage. It matters both on mobile devices and in data centers. The startup time issue is annoying as well. I like the general idea, but making startup time even worse than the JVM itself makes it unattractive.

chrisseaton 10y ago
If you want to reduce the time required to handle an individual request in a given program that you already have there's not much you can do automatically. You can't use a processor that's twice as fast because if you are already using a modern system we don't have one of those. You can't use two processors as we don't really know how to parallelise effectively enough in general cases. But you can double the RAM in a system with reasonable effort and cost. The startup time issue is being solved with ah ahead-of-time Java compiler with whole-world analysis that we are developing. It runs hello-world in our Ruby implementation in about 100ms, which is an order of magnitude faster than the normal JVM.
- mike_hearn 10y ago
  That's an interesting argument I hadn't considered before.
- deleted 10y ago
  [deleted]
- chubot 10y ago
  OK, if those are your design constraints, then that's fair. I'm just questioning how widely those constraints will apply in the future. I'm pretty sure the v8 changes were motivated by phones, so maybe there is room for another project like Graal and Truffle with a different set of constraints. Also, for web services in particular (not sure if that is a major use case), I would question the view of making individual requests faster. I recall Steve Souders said he was a back end guy at Yahoo working on latency, and then he switched to front end performance because he found that the front end was eating up all the time. In my experience this is too true. In other words, if you had a server where requests were taking 100 ms, and you made them take 50 ms through VM design, you would be a hero! But somehow front end engineers are still constructing pages with 10 - 30 full seconds of latency (especially on mobile) out of back end requests that take 100ms. There's just a lot more room to optimize there, whereas sometimes I feel like VMs are trying to squeeze blood out of a stone. And I agree that there will be demand for such a "black box" approach, where you just take an arbitrary program and make it faster. But I'm interested in overall system performance, and in that case, a little bit of application knowledge can work wonders. One of my pet peeves is that often performance tools like time and space profilers are sort of an afterthought that programmers use only when they have problems. They write this huge spagehetti of allocation, and then 2 years later they start tuning the GC. This is partly the fault of programmers and partly the fault of the language ecosystem. It would be nicer if the language exposed integrated tools. I dont' know that much about the JVM ecosystem, but they always feel like a "separate thing" you have to go research and choose and download and install. I think Go's tooling is a good example here. Anyway, I think this is an interesting project. In particular I think the focus on polyglot programming is fantastic. I too feel the pain of enormous amounts of duplicated work -- e.g. even at say Google with a relatively small set of languages like C++, Java, and Python, there were still all these separate "worlds" and gradually engineers became sequestered in their own world. IMO Go made things worse and not better -- it was yet another native runtime that didn't even interoperate all that well with C++, let alone Java or Python!!!

Athas 10y ago

When I think of "innovation in language design", I don't really think of JIT-compiling highly dynamic behaviour. I think of inventing languages with programming models that can be used for programming the heterogeneous hardware of the future (and, well, present). For example, massive parallelism is needed for both GPUs, FPGAs, clusters, and other more exotic systems, and the trick becomes how to translate portable and high-level problem descriptions to, say, highly vectorised code for GPUs, deep FPGA pipelines, or asynchronous message-passing cluster code. You can't solve that with JITs. From what I have seen, JITs are very useful for taking away the overhead of indirect calls and similar dynamic behaviour, but I don't think that's going to be the primary language design challenge of the future. No compiler can (usefully) extract significant amounts of parallelism from an algorithm which has none, and current programming models are not particularly convenient for expressing parallel algorithms. While current languages allow you to express parallelism by using low-level features, the resulting program will invariably be non-portable. High-level parallel languages (or maybe libraries) are the only solution I can see.

mike_hearn 10y ago
Actually that's not quite true: https://github.com/pcpratts/rootbeer1 https://github.com/pcpratts/rootbeer1 http://openjdk.java.net/projects/sumatra/ http://openjdk.java.net/projects/sumatra/ There has been work done on automatically identifying and running ordinary JVM hotspots on the GPU. That said, I agree that automatic parallelisation is a hard problem. I don't think it's the only interesting area of language innovation: most of the innovations making programmers lives easier in recent years have nothing to do with it.
- Athas 10y ago
  Both of those projects look like they are about designing a convenient GPU programming API for Java. Which is fine and useful, but you still have to program with an understanding of the GPU model (notably, massive threading), so it's not quite as high-level as what I believe is needed for portable performance.
  - 10y ago

JackC 10y ago

Previous discussion of this article when it was hosted at Medium: https://news.ycombinator.com/item?id=12122557 https://news.ycombinator.com/item?id=12122557

mike_hearn 10y ago
It's actually still hosted by Medium, I just got around to setting up a custom domain as I noticed a few people saying they've learned to associate the medium.com domain with low quality writing. That's a pity, but at least it's easier to move off Medium now when something better comes along (or they go bankrupt).

fritzo 10y ago

Another perspective is that Graal & Truffle prove that a large swath of programming language space is semantically equivalent, suggesting that we shift focus of innovation elsewhere.

gwenzek 10y ago

The question is can you create a language like Scala with it? Ie with complex type inference? Or Haskell? Because if it constrains you to Java like languages, I don't see this as "innovation in language design".

jerven 10y ago
This is the execution layer, i.e. how is that Scala program turned into machine code. You can make a Haskell implemented using Truffle. Or Rust etc... Haskell, defines the semantics of a program, while truffle turns that semantics into executable code.