RubyConf: YARV on Rails

Posted by Nick Sieger Mon, 23 Oct 2006 14:15:00 GMT


Update: corrected performance numbers -- 20x, not 20%!

  • Got a job developing YARV at the University of Tokyo! He’s now employed at Akhihabara, Otaku City.
  • Member of Nihon-Ruby-no-Kai
  • Present at RubyKaigi 2006 (200 tickets sold in 3 hours). RubyKaigi 2007 will be June 9-10 (Saturday and Sunday).
  • Member of Nihon-Perl-no-Kai
  • Co-author of Perl book on Parrot in Japanese


  • [Demo creating Rails app]
  • Create app with YARV (rails foobar)
  • Edit config/boot.rb, add a GC.disable line (there’s a bug to be fixed when he gets back to Japan).
  • Start up WEBrick, and it works!


  • Rite: code name of Ruby 2.0 (a.k.a. vaporware!)
  • YARV: Yet Another Ruby VM


  • Supported by funds from IPA (now finished)
  • Simple stack machine, with VM instructions, a compiler and interpreter
  • Optimization techniques to improve performance
  • Open source

Optimizations include compile-time optimization, native threading, specialized instructions, instruction unification, inline method cache, and stack caching. YARV can build with configure/make, but doesn’t work with AC 2.6 (maybe you know why?). It passes most of the Ruby tests, but misses a few due to implementation differences.

[Koichi showed a demo controlling iTunes on Windows with Win32/OLE with YARV, and a native-threaded scenario in IRB.]

Myths of YARV: YARV is great! YARV will solve all problems! It makes Ruby programs go 50 times faster! It solves character issues! It finds your girlfriend!

Truths: YARV is for running Ruby programs, fast. It provides up to a 20x speed up for some algorithm benchmarks (Ackermann, Fib), but not for others [graphs shown]. You assemble and disassemble YARV instruction sequences, or serialize and de-serialize them. They are just Ruby literals, so they can be packed in YAML or some other human-readable format.

require 'yasm'
require 'yaml'

iseq = YASM.toplevel([:a, :b]) {|ib|

p iseq.to_a.to_yaml # => (gave a readable YAML view of the assembly)


  • Ruby thread is mapped 1:1 to a native thread
  • Supports POSIX and Win32
  • Many existing Ruby libraries are not synchronized at the C level, so many C libraries need synchronization added to them
  • Thread model 2: 1:1 mapping, with a Giant Lock (GL). Only the thread that has the lock can run. No need for sync, but no parallelism
  • Thread model 3: Ruby threads in parallel, but when thread-unsafe code is executing, GL needs to be obtained
  • Mutex class will become builtin
  • Thread.critical will vanish (not obsolete, but unsupported) [this was a controversial point for some -- the comment was that it’s a near impossibility to keep it with a native threading model though, the two are in compatible]

Matz: 1.9.1 in 2007 Christmas, but Ruby 1.9.1 is also to be merged with YARV, so Koichi hopes to complete the merge by spring or summer 2007. Thread model 2 will need to be used to begin with.


  • set_trace_func hook functions -- what to do here? [It was suggested by Charles Nutter to remove it, to which Matz replied that we could as long as we have a good replacement debugging API.]
  • Catch up with Ruby 1.9
  • JIT/AOT compiler (AOT compiler started but incomplete)
  • Koichi also has a side project: high-performance Ruby, with the goal of making it easy to write performant code.


More developers and testers are welcomed to the project!

Posted in  | Tags ,  | no comments | no trackbacks



Use the following link to trackback from your own site: