mtnwestruby: Ruby Implementor’s Panel

Mountain West Ruby Conference: Ruby Implementor’s Panel
16 March 2007

Ruby on Parrot has a JIT and garbage collection. Needs to be polished. Has an interop convetion so languages can call into each other. Bytecode runs on most common hardward — Intel, PPC.

John Lam – CLR Ruby: CLR naming conventions are nothing like Ruby naming conventions, but you want to make the interop look like Ruby. CLR was originally envioned to be a static language runtime, so there are similar problems as for the JRuby guys. The CLR platform gives you some things “for free”, like debugging support.

Edwin Pheonix – Rubiness: Rubiness is designed new, from the ground up, and meant for Ruby. The idea is to keep it small and simple while supporting full Ruby. Goal is to hit 1.0 by October. It will be 1.8.5 compliant and support Rails 1.2.

Charles Nutter & Tom Enebo – JRuby: Will release 1.0 in the next couple of months. Goal is to get it faster.

Question and Answer Session

Performance

  • Nutter: The language shootout posted recently was pretty good. JRuby is about twice as slow as Ruby, although some things are starting to run faster. When compiled, JRuby runs faster than Ruby.
  • Ty: Slowly seeing more performance as they work on it.
  • Pheonix: Rubiness is slow and makes the other implementations look awesome. Up to this point, he has done no performance tuning. Since the language shootout, he’s put some time into it. He was beating Ruby 1.8.5 on some of the benchmarks.
  • Lam: Iron Python is the fastest python out there, depending on who’s benchmarks you believe. This proves that using the CLR is viable. Compile chunks of dynamic code, and garbage collect them later.
  • Parrot Guy: Parrot is able to beat C code in some cases, similar to the JVM + Hotspot. Speedups as much as 1.5x over Perl 5, but it depends on what you’re doing.

What features of the Ruby language are the most problematic?

  • Pheonix: Continuations are one of the easiest. Dynamic dispatch is a pain, but it’s a fundamental language feature. Eval.
  • JRuby: Emulating Ruby’s threading model. Eval is a pain, which is why they have a mixed mode interpreter. Compatibility with esoteric features —
  • Pheonix: An esoteric feature is like what you can take in as a block argument.
  • Ty: How many people have passed Nil as a block argument? ….
  • Pheonix & Nutter: Who here has used ‘retry’ from a block? (one person). Do you know what it does? (no). It re-runs the code.
  • Parrot Guy: The dynamic nature of the language makes it difficult.

What advantage does your VM give?

  • Parrot Guy: Interop with already written libraries — SQL, etc.
  • Lam: You get Profiling, Debugging, Code coverage for free. Auto-complete in IDEs.
  • Pheonix: The possibilities are wide open right now. Re-write the byte-code on-the-fly if you want. His goal is to build a platform for other people to get their work done — an extensible VM.
  • JRuby (Nutter): Interop with Java libraries. Most companies already have and use Java, so there is much to leverage.
  • Ty: How many people have trouble getting Ruby deployed in their environment? (No one — everyone here uses Ruby already)
  • Pheonix: Deployment is a big issue. How do we distribute applications without having to ask people to install a VM?

How do your implementations deal with Unicode?

  • JRuby: JRuby can use the Rails multi-byte library natively, or uses the Java unicode support.
  • Pheonix: Rubiness doesn’t have Unicode, but he’d like it to.
  • Parrot Guy: Parrot supports unicode. It’s not that hard to make Unicode work most of the time, today.

Is there a website for a formal specification of Ruby?

  • Nutter: I’m still running the website in my basement, and sometimes people contribute to it. http://headius.com/rubyspec — it’s a community spec for Ruby. Few people are clamoring for a spec, except for the people doing alternative implementations.

Is there a common benchmark suite?

  • Pheonix: Believes that each implementation will have their won benchmark suites. However, they will run each other’s benchmark suites.
  • Nutter: We’re running the test suites that have been written so far, including Rubycon. See the “ruby test” project on Ruby forge.
  • Pat Eyler: Various gems will automatically be run against the different VM implementations, and results submitted to the VM implementors.

Why not compile to C code?

  • Pheonix: There are many things in Ruby that don’t map to C. Two or three projects to this end have stalled.
  • Lam: Iron Python compiles down to static assemblies, so it’s possible to go from Ruby to assembly code, although it still leverages the CLR libraries, garbage collector, etc.
  • Nutter: Why re-invent the wheel of a garbage collector, the VM, boundary between libraries? People have worked hard to implement general purpose VMs, so let’s leverage their work.
  • Lam: Interpretation isn’t as horrible as it seems. (I overheard him say: Slow application startup time is a problem. Microsoft employs a lot of lisp refugees.)