M. Edward (Ed) Borasky wrote:
> 2. Given that the core Ruby 1.9 virtual machine is so much faster than
> the core Ruby 1.8 "virtual machine", and that Koichi is still tweaking
> it, and that Charlie Nutter et. al. on jRuby are still tweaking the
> jRuby implementations of both 1.8 and 1.9, shouldn't gem developers be
> looking at porting their stuff back to pure Ruby whenever possible? I
> can understand C interface code for OS-specific functionality, but is it
> really that necessary for raw speed any more?

I've been advocating this for JRuby for newcomers looking to write 
extensions or new libraries. I always prefer they write a pure-Ruby 
version first, and if performance is really a problem to write a 
Java-based version later. This guarantees two things:

1. I think they'll attack the problem better in Ruby and come up with a 
better solution overall.
2. Having a pure Ruby version around will push JRuby harder and 
ultimately help both JRuby and other implementations too.

But JRuby offers something neither Ruby 1.8 nor Ruby 1.9 does, and I'm 
curious what you all think will be the effect...

JRuby will allow enabling most Ruby 1.9 features selectively.

So we already offer improved performance with 1.8-compatible semantics. 
And there are a few limited places where we're offering 1.9 features. 
But in general, since 1.8 and 1.9 will be supported by basically the 
same binary, many of the optimizations or features in 1.9 will be 
configurable by a flag.

For optimizations, this is fairly non-invasive. Most of the big 
optimizations in 1.9 are there because people won't miss them (fast 
fixnum math, constant-time literal whens, etc). So users of 1.8 may 
choose to turn those optimizations on right away as we implement them.

But for features...would it be useful to be able to turn on e.g. M17N 
strings or Fibers but leave the rest of 1.8 semantics intact?

- Charlie