Talks to Watch

Chris Seaton @ VMSS16: JRuby+Truffle: Why it’s Important to Optimise the Tricky Parts

5K views · Jul 7, 2016 · 1:02:44 · 2 HN recommenders · 3 mentions · discussed 2016–2019

Chris Seaton talks about JRuby+Truffle, explaining how the Truffle and Graal combination optimises the tricky parts of Ruby and why it outperforms other Ruby implementations.

Why Hacker News points people here: HN recommends it for specifics on how Truffle and Graal achieve strong dynamic-language performance.

“Chris Seaton gave this talk recently about JRuby+Truffle and some specifics about how it optimises so well compared to other Ruby implementations.”HN comment, 2016

What Hacker News said 3

RecommendsmatthewrudyJul 2016

“Chris Seaton gave this talk recently about JRuby+Truffle and some specifics about how it optimises so well compared to other Ruby implementations.”

Explains how JRuby+Truffle optimises so well compared to other Rubies.

Full comment

Chris Seaton gave this talk recently about JRuby+Truffle and some specifics about how it optimises so well compared to other Ruby implementations. this video Previous discussion link

in “Graal and Truffle could accelerate programming language design” · view on HN
RecommendsBenoitPDec 2016

“I hear the Truffle+Graal combination is getting very good results about Ruby.”

Shows Truffle+Graal giving very good Ruby results.

Full comment

I hear the Truffle+Graal combination is getting very good results about Ruby. Here is video about it (pointed to the missing-method example): [1] They're hitting 35x in some benchmarks [2]. Most benefits being in workloads where Ruby has to continuously talk to C; the result-passing part gets compiled away. It is available in Java 9, if I'm not mistaken. LLVM IR bytecode ingestion is in preparations too [3]. [1] this video [2] link [3] link

Cites itchrisseatonApr 2019

“I gave a lecture about this”

The author's own lecture on optimising dynamic languages.

Full comment

> I understand that a JIT engine cant do this, due to speed. Most serious JIT engines do! For example V8, LuaJIT, Graal, C2. > But would be surprised that a LLVM compiler with a custom-designed heuristic for specific optimizations cant manage this. Rubinius for example tried writing custom optimisations like you're describing and didn't get very far. LLVM is not designed for these kind of optimisations - it understands memory reads and writes, not high-level semantic information about arrays and objects. In practice, it just doesn't seem to work. As I say I think it's a bare minimum for making a dynamic language genuinely fast. I gave a lecture about this this video .