Skip to content
0:00 / 0:00

#jruby#truffle#graalvm

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

softdevteamuk

247 subscribers • 2 videos on Hallway

YouTube
  • Recommended by 2 people: 2 on Hacker News.
  • Presented by Chris Seaton

Advanced. Deep dive for people who know the field.

5K views10 years ago2 recommendations

Systems programmingProgramming languagesCompilers and interpretersPerformance and optimizationRuby

Chris Seaton explains how the Truffle and Graal framework optimizes the complex parts of Ruby, enabling significant performance improvements over other implementations.

Slides and other VMSS16 talks at soft-dev.org/events/vmss16/

Why it's here

2 people recommend this

What people say. Recommended for its detailed explanation of how Truffle and Graal optimize dynamic language features that traditional JIT compilers struggle with.

matthewrudyon Hacker News • Recommends

On “Graal and Truffle could accelerate programming language design”

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

BenoitPon Hacker News • Recommends

On “The Ruby+OMR JIT”

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 link to this video 2 link 3 link

chrisseatonon Hacker News • Mentions

On “PHP 8 to Add a JIT”

> 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 link to this video .