Speeding up Ruby by rewriting C in Ruby

Original Article ↗ Hacker News Discussion ↗

Ruby, YJIT, and alternative implementations

  • Discussion notes the idea of a “Ruby stdlib in Ruby” predates YJIT (e.g., Rubinius, TruffleRuby), with mixed past results (Rubinius slower than MRI).
  • TruffleRuby is highlighted as extremely fast and capable of treating C extensions like Ruby code, allowing JIT optimization of C paths.
  • YJIT’s implementation history (from C to Rust) is mentioned; Rust is seen as a good trade-off despite build-toolchain friction.
  • Some report mixed real-world speedups from TruffleRuby vs MRI and stress careful benchmarking due to startup and warmup behavior.
  • TruffleRuby is open source and based on Graal; seen as “forkable” if Oracle ever changes direction.

Rails on TruffleRuby

  • One view: Rails “doesn’t work” on TruffleRuby and won’t soon, especially with Rails 8 requiring Ruby 3.2.
  • Counterpoint: TruffleRuby claims to run Rails and many gems; not being “100% MRI 3.2 compatible” doesn’t necessarily mean Rails is broken.
  • Overall status of full Rails compatibility is unclear from the thread.

Benchmarks, microbenchmarks, and interpretation

  • Some argue microbenchmarks are often dismissed too quickly: they do expose real issues (e.g., high function-call overhead in dynamic languages).
  • Others stress they are narrow: you can’t responsibly claim “X is N× slower than Y in general” from a tiny benchmark.
  • Links to larger benchmark suites (e.g., Benchmarks Game, other repos) are cited to show wide variance across implementations and tasks.
  • Methodological criticisms appear: too few runs, using wall-clock time, lack of JMH for JVM tests, and ignoring startup costs.

Python performance, C libraries, and mission-critical use

  • Several comments note that many Python workloads push heavy computation into C/Fortran libraries; Python acts as glue.
  • Others respond that any language with FFI can do this; the baseline slowness of pure Python still matters.
  • Debate over acceptability in constrained or mission-critical systems:
    • Some describe successful use of Python even on a satellite where extra milliseconds and milliwatts are acceptable.
    • Others argue that for highly power- or latency-sensitive systems (e.g., long-endurance drones), interpreter overhead and GC are prohibitive.
  • Concerns raised about dynamic languages for mission-critical software, even with optional static typing tools.

Other language comparisons (Dart, Crystal, LuaJIT, JVM languages)

  • Dart’s strong showing surprises some, especially versus C# and LuaJIT; others point out that tiny benchmarks may be dominated by specific optimizations.
  • Background on Dart’s VM lineage (from teams behind Self, HotSpot, V8) and its AOT+JIT design is mentioned.
  • Crystal is brought up as a Ruby-like compiled language with Rails-esque frameworks and static binaries; some think omitting it from Ruby-speed discussions is odd.
  • Others counter that Crystal is not Ruby and doesn’t help existing Ruby codebases.
  • Node vs Deno and Java vs Kotlin differences are attributed to JVM optimization focus and extra bytecode generated by “guest” languages.

Benchmark design and visualization critiques

  • The core Ruby benchmark (nested loops with array updates) is called “weird” and easy to algebraically collapse, suggesting it mostly measures a trivial hot loop.
  • Some note compilers generally don’t do liveness analysis for individual array elements due to cost, even when it could enable dramatic simplifications.
  • The article’s animated visualization of language speeds is criticized as distracting and hard to read quantitatively; static tables or bar charts are preferred by some, while others find the animation intuitive enough.