Chris Seaton @ VMSS16: JRuby+Truffle: Why it’s Important to Optimise the Tricky Parts
softdevteamuk2 HN recommenders · recommended in 2 months, 2016–2019
talk · advanced · 2016–2019 on HN
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.
HN recommends it for specifics on how Truffle and Graal achieve strong dynamic-language performance.
Up next
10 mo on HNTransformers, the tech behind LLMs | Deep Learning Chapter 5
3Blue1Brown
13 HN recommender · 2024–2026
7 mo on HNA Swift Introduction to Geometric Algebra
sudgylacmoe
7 HN recommender · 2020–2024
5 mo on HNWhy can't you multiply vectors?
Freya Holmér
9 HN recommender · 2023–2025
13 mo on HNRich Harris - Rethinking reactivity
You Gotta Love Frontend
15 HN recommender · 2019–2026
12 mo on HNLexical Scanning in Go - Rob Pike
GoogleFOSSSydney
13 HN recommender · 2012–2025
12 mo on HNWilliam Byrd on "The Most Beautiful Program Ever Written" [PWL NYC]
PapersWeLove
11 HN recommender · 2017–2026
10 mo on HNCppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
CppCon
13 HN recommender · 2016–2024
8 mo on HNClasp: Common Lisp using LLVM and C++ for Molecular Metaprogramming
Google TechTalks
8 HN recommender · 2015–2024
7 mo on HNCompiling C to printable x86, to make an executable research paper
suckerpinch
8 HN recommender · 2018–2023
7 mo on HNBreak Me00 The MoVfuscator Turning mov into a soul crushing RE nightmare Christopher Domas
Adrian Crenshaw
6 HN recommender · 2017–2026
7 mo on HNA Talk Near the Future of Python (a.k.a., Dave live-codes a WebAssembly Interpreter)
David Beazley
7 HN recommender · 2019–2025
7 mo on HNMiguel de Icaza: Swift Godot: Fixing the Multi-million dollar mistake #GodotCon2023
Godot Engine
6 HN recommender · 2023–2026
3 comments from Hacker News
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
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
> 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 .