Stackful Rubinius Interview

Yesterday, Brian Ford (@brixen) unveiled some sharp new work that Evan Phoenix (@evanphx) has been doing on the rubinius internals. (You can read about it here and here.) It's been a while since I've run an interview with members of the Rubinius team, and this seemed like the kind of news that people might like to follow up on, so I decided to shoot off an email to Brian and Evan. Here are the answers I got.

---

An almost 2x speed-up is great work (especially with more optimizations to come). Beyond the Blue Book, where everything started, what are your major influences these days?

BrianI've been trying to spend a lot of time in Virtual Machines by Smith/Nair, Garbage Collection by Jones, Advanced Compiler Design and Implementation by Muchnick, Types and Programming Languages by Pierce, and reading up on JVM papers and other papers that Evan or I come across.

Evan I've got the same "Virtual Machines" book, but I mainly read papers I find, talk with people who've solved similar problems (Slava Pestov, Charles Nutter, etc), and read a lot of other peoples code.>

Getting my head around a problem and how others have solved it is the best way I come up with a solution of my own. Understanding the trade offs of other solutions, their constraints, etc, is key to figuring out how to adapt things.

Lot's of people have talked about Rubinius as a possible future host VM for Ruby proper. With Ezra's offer (on behalf of EY) to take on Ruby 1.8.6 maintenance, what are the odds that Rubinius will be a part of the plan?

Evan I don't see any problems with this. EY is clearly looking to be a stable hand on the rudder of 1.8.6, providing bug fixes and such. Their idea, I'm assuming, is to provide the best 1.8.6 they can under the circumstances. Rubinius is in an entirely different boat, because it's working under a completely different set of goals and constraints.

They're both wonderful consumers of the RubySpecs.

Brian I just heard from you about Ezra's offer this morning. Given the Ruby expertise at Engine Yard and their commitment to providing an outstanding experience of Ruby for their customers, it sounds like a great idea. Rubinius has been trying to help out the larger Ruby community since the beginning through the RubySpec effort. Leveraging the RubySpecs as a common thread among the alternative implementations, I expect Rubinius to continue to be a big support for usage of MRI 1.8.6. At the same time, Rubinius and MRI 1.8.6 will always be distinct beasts. The architecture does not permit sharing code (other than Ruby standard library files).

One of the things that attracted a lot of attention for Rubinius was the early pronouncement that Rubinius would be (mostly) Ruby in Ruby. How far along that path is the project? What are the next obstacles you hope to clear?

Evan There is always going to be a barrier between the Ruby layer and whatever is below it. For quite some time, there has been talk of having some kind of translation layer, that could translate a subset of Ruby into a lower language, to run normal Ruby on top of. We've got no problem with this as a goal, but we simply haven't put any work into it lately.

We have to be pragmatic about how to apply our architecture decisions, so it's a balancing act.

Brian Rubinius has been a mixed architecture since the beginning, first with a C-language VM and now with one written in C++. However, our compiler and vast portions of the core library are written in Ruby. We pushed for using FFI so that even more code could be written in Ruby.

As we make the execution of Ruby code even faster, we can potentially replace some of our primitive operations with Ruby code. The VM has a major division between the primitives for data types like Array and the core VM structures. The primitives for data types are an area where an easily compiled dialect of Ruby could be used (Evan worked on this with Cuby, later renamed Garnet). At the same time, better techniques for runtime-type handling may make a dialect unnecessary.It is an open problem that we are looking at.

For the moment, we're focusing on performance and compatibility toward running Merb/Rails and the other micro web frameworks. In doing so, we write a lot of Ruby code, which is a great thing. It's also a great place for contributors to dive into the project. Hint, hint.

There has been some talk of hosting other languages on the Rubinius VM. To date, I don't think that's really come to fruition. Is it realistic? Do you think it will happen?

Brian Sure, it will be done eventually. The other day, the author of Heist popped into the IRC channel with a problem. (Heist is an attempt to write a Scheme in a little Ruby and a lot of scheme.) Turned out he uncovered a bug in instance_eval. Evan fixed it and Heist is running on Rubinius.

I'm also looking at JamVM and the possibility of running Java code directly on Rubinius. At the core, Rubinius is a pretty slick stack-based VM. You can do a whole lot with that under the hood.

Click here to Tweet this article

Bad News From the Rubinius Team

Yesterday, Evan Phoenix broke the news that Engine Yard has scaled back their Rubinius team to two members. This means a number of formerly employed Rubinius hackers are now going to be looking for work. Developments like this are never good news. It's certainly not the end of the world though. I'm grateful for Engine Yard's support, but I think it's important that we not tie Rubinius to Engine Yard. In addition to their work, there have been huge contributions made by unpaid Rubinius volunteers, part-timers (including multiple GSoC projects), and other companies. Some of the most important work has been the cooperation of multiple projects on common goals like the test suite. Engine Yard has poured a good chunk of resources into Rubinius over the last year or so, and has that investment has paid off in a better, faster, more complete Rubinius (see Tom Mornini's blog post for some details). In fact, they hired more engineers to work on Rubinius than Sun did to work on JRuby. Thanks, Engine Yard, for the contribution to a thriving Ruby community. Good luck in navigating the difficult economic times we're all facing. And good luck to the great hackers who are now looking for a soft landing — if any of you have some Ruby work that you could send their way, I'm sure it would be appreciated. [Note, while Engine Yard sponsors my blog they were not involved in writing the entry.]

New Improved MySQL library

MySQLPlus is a new, non-blocking MySQL driver for Ruby 1.8 and 1.9 (anyone know if it will run on Rubinius?) from eSpace, the folks who created NeverBlock. (They also talk about NeverBlockPG, a postgreSQL driver, but it seems to have been deleted.) To quote eSpace's announcement:

[MySQLPlus does] IO operations concurrently and in a transparent manner, thanks to NeverBlock. An interesting side effect emerged during the development of this driver. We were required to update the current MySQL driver to be able to do async operations. Once those were done, we discovered that the basic foundation for threaded support was there. Hence we went forward and implemented it (with help from Ruby gurus like Aman Gupta and Roger Pack). What we have now is a new general purpose MySQL driver that supports threaded access and async operations. This means that you can send queries to a MySQL server in a concurrent manner from Ruby applications. This is big news for those waiting for Rails thread safety. Finally there is a MySQL driver that can help them achieve that concurrency.

I'd love to see what alternative ORMs like Sequel and DataMapper will do with this kind of library underneath them.

Ruby and V8

Summer is drawing to a close and many of the things which have distracted me from my blog are becoming less pressing, so it's about time for me to crank this back up — we'll have to see how well I keep up with it. Of course, there are a lot of exciting things on the horizon that are prompting me to write. One of the biggest is the release of V8, the JavaScript VM that's part of Google's Chrome. Over on the Strongtalk list, David Griswold wrote:

I still think it or some derivative will quickly become the dominant dynamic language VM, for the following reasons:

• Given who the developers are, and with Google behind it, it will be the fastest JavaScript VM for a long time to come.
• For the same reason, it will be reliable and secure (as much as it can be, anyway; nothing is perfect).
• It will be supported on the three major platforms (Windows, Linux, Mac).
• It can be used with other browsers, so I'm sure it will be ported to Firefox (if only as an option). Some or all of the other browsers may also adopt it, given that it will have a very hard-to-overcome performance advantage (these sorts of VMs can't be pulled out of a hat). Although MS and maybe Safari may have too much of a Not Invented Here problem with it, as well as standards war issues.
• those things, plus the other architectural advantages it brings, will make it a primary target for serious web app development, esp. Google apps.
• So it will be ubiquitous

So it will be an irresistible platform for other dynamic languages, even if they could theoretically run a bit faster on a custom VM. Remember it will still be a lot easier to run other dynamic languages on JavaScript than it is to run them on Java, since at least JavaScript is fully dynamic, unlike Java.

I'm not the language guru that David is, but I not ready agree with him yet. While JRuby is showing good progress at creating a fast, stable Ruby implementation on top of a non-native VM, I don't think we've seen what a native, tuned VM for Ruby can really do. I'm also not sure we'll ever see Ruby's community turn away from their own VM (be it Rubinius or the 1.9 VM) for the 'standard implementation'. This doesn't mean that V8 is without value to the Ruby community though. Again, David Griswold:

The V8 development team has multiple members of the original Animorphic team; it is headed by Lars Bak, who was the technical lead for both Strongtalk and the HotSpot Java VM (as well as a huge contributor to the original Self VM). I think that you will find that V8 has a lot of the creamy goodness of the Strongtalk and Self VMs, with many big architectural improvements:

• open source
• will run (eventually) on Windows, Linux, and Mac
• dynamically JITs to native code
• can run completely independently from the browser
• generates hidden classes behind the scenes, since javascript doesn't have them (very reminiscent of the 'maps' used in the Self VM).
• is multi-threaded from the ground up, with the ability to share VM overhead between different OS processes.
• has even smaller object headers than in Strongtalk, making small object overhead even smaller
• kick-ass compacting, non-conservative garbage collector

Whether Ruby ends up on V8 or not, I'm guessing that some of V8 will end up in Ruby.

MWRC 2008 Roundup

This year’s MountainWest RubyConf was incredible. There were a bunch of great talks, and the hallway track (though too short) was awesome. It was especially great to go hang out at the hacking suite put on by Engine Yard

I’m not going to go into too much detail about any of the talks until the video is released on Confreaks MWRC 2008 page. So far only Evan’s Keynote and Ezra’s have made it up (Gile’s talk was up briefly, but seems to have been pulled due to some audio problems).

Evan’s talk was a great peek behind the curtain at Rubinius development. Of course, since the process is so dynamic, it was kind of like peeking behind one of those clear shower curtains. Nonetheless, having Evan there as a guide pointing out the interesting bits and the philosophy made it quite interesting. It was a great kickoff to the rest of the conference.

Ezra’s talk focused on Merb and was more of a nitty-gritty kind of talk than Evan’s was. One bombshell that dropped was that there’s a Merb book in the works from Manning—I wonder if my predictions of a Ruby web framework to challenge Rails are finally going to come true. It was also interesting to hear Ezra talk about the different use cases for mongrel vs. thin or evented-mongrel.

Finally, there were a couple of neat things that won’t make the videos. We were able to raise over a thousand dollars for the Ruby Mendicant project. We didn’t raise enough money to get Steve Baker to Scotland, but it was pretty cool to have some of our speakers come up and say that they wanted to donate their honorarium to him. We even made a great donation on the local front, giving our leftover boxed lunches on Saturday (about 60 of them) to a local food pantry.

We had some great sponsors who made the conference possible. Addison-Wesley , Apress, and O’Reilly all donated books for us to give away in our binary lottery. Because of our sponsors, speakers, and attendees we ended up with a great conference. Thanks everyone!

The Rubinius Debugger

When I read the posting about Cylon, the Ruby debugger for Visual Studio by SapphireSteel, I immediately thought about the Rubinius debugger highlighted in InfoQ recently. I decided to give it a try and see what I came up with. I wasn’t able to replicate Dermot’s tests exactly (I don’t know where he set his breakpoints, and Rubinius doesn’t support everything he tested), but here are my initial results:

Line Based

Rubinius no debugger	Rubinius w/debugger no breakpoints	Ruby
2.039 seconds	2.399 seconds	0.898 seconds

Call Based

Rubinius no debugger	Rubinius w/debugger no breakpoints	Ruby
13.441 second	13.999 seconds	4.171 seconds

Rubinius still has a long performance road ahead of them in terms of general execution, but it’s pretty exciting to see that their debugger is so fast. The cylon debugger (which smoked the other options in their testing) was 25% slower for line based debugging, and 306% slower for call based. By comparison, Rubinius’ debugger only added 17% for line based and 4% for call based (actually, I’m guessing that had the line based run through more iterations, the Rubinius debugger would have done better, I think most of its time is spent in set up).

Using the Rubinius debugger requires that you add a call to the debugger to the program:

debugger

def fac(n)
  lvar = n
  n == 1 ? 1 : n * fac(n-1)
  return n
end

count = 0

tstart = Time.new
0.upto(1000000) {fac(5)}               # 1ine based
#0.upto(30000000) {count += 1}         # call based
tend = Time.new  
puts "%10.3f" % tstart
puts "%10.3f" % tend.to_f
diff = tend - tstart
puts "%10.3f" % diff.to_f

When you run this, you’ll get something like this:

$ ../shotgun/rubinius debug_fac.rb
[Debugger activated]

debug_fac.rb:1 [IP:5]

rbx:debug> c
[Resuming program]
1201801369.694
1201801372.001
     2.307

There are several commands available:

command	explanation
h	get a listing of commands
b	list breakpoints
b	set a breakpoint at the start of the method
n	Step to the next line
ni	step to the next VM instruction
c	continue execution until the next breakpoint
l	list source code around the current breakpoint
d	decode VM bytecode around the current breakpoint
v	display local variables and their values
vs	display the contents of the VM stack

Some of these are pretty cool, take a look at these examples:

rbx:debug> vs
     VM stack [0-5]:
  sp => 0: TrueClass  true
  fp => 1: Class      Rubinius::VM
        2: String     "" 
        3: String     "debug_fac.rb" 
        4: String     "debug_fac.rbc" 
        5: NilClass   nil
           ...

or:

rbx:debug> d
   Bytecode instructions [5-25] in compiled method script:
           ...
           # line 1
     0005: pop
           # line 3
     0006: push_literal  #
     0008: push_literal  :fac
     0010: push_self
     0011: send_stack    :add_method, 2
     0014: pop
           # line 9
  => 0015: meta_push_0
     0016: set_local     :count
     0018: pop
           # line 11
     0019: push_const    :Time
     0021: send_method   :new
     0023: set_local     :tstart
     0025: pop
           ...

which compares to:

rbx:debug> l
   Source lines [1-18] in debug_fac.rb:
      1: debugger
      2:
      3: def fac(n)
      4:   lvar = n
      5:   n == 1 ? 1 : n * fac(n-1)
      6:   return n
      7: end
      8:
  =>  9: count = 0
     10:
     11: tstart = Time.new
     12: 0.upto(1000000) {fac(5)}               # $-1òølineòù based
     13: #0.upto(30000000) {count += 1}     #$-1òùcallòù based
     14: tend = Time.new
     15: puts "%10.3f" % tstart
     16: puts "%10.3f" % tend.to_f
     17: diff = tend - tstart
     18: puts "%10.3f" % diff.to_f

Like a lot of things in Rubinius, the debugger isn’t quite ready for primetime but it sure shows a lot of promise.

Real World Rubinius Performance

Well, I have good and bad news from the Rubinius front. This morning, I built the latest Rubinius from the git repository, and gave LogWatchR another try … and it worked! This is a huge step forward from my perspective, since I’ve had all kinds of wierd failures in the past.

The bad news (well, bad is an overstatement, let’s say ‘not so good news’) is that the performance is pretty bad at this point. To be fair, the Rubinius team is still focused on completeness. I’d expect performance to improve once they turn their eye to it.

Here’s my 30 second recap:

My ‘real world performance’ timings run a small Ruby app called LogWatchR, which scans syslog data for cataloged good and bad patterns. I feed it about 73,000 syslog entries (about 20 minutes worth) that I’ve got archived. I measure the execution time against repeated runs, and find the average run time and standard deviation.

Rubinius’ first successful run clocked in at an average of 143.03 seconds, with a standard deviation of 0.56 seconds.

Given that things took so long, I thought I’d try a quick profiling run too (I only ran against 1000 log entries though, to save time). Here’s the abbreviated version of what the profiler told me:

../shotgun/rubinius -r profile logwatcher.rb < short_log
Total slices: 160, 2680000 clocks
 % time   slices   name
   8.75       14   String#[]
   8.12       13   Hash#[]
   6.88       11   Array#<<
   6.88       11   Object#kind_of?
   5.00        8   #.single_load
   4.38        7   String#split
   4.38        7   Hash#keys
   4.38        7   Regexp#match_from
   3.75        6   Hash#[]=
   2.50        4   String#substring
   2.50        4   Array#replace

Now for the amazing part, the sampling debugger took almost no extra time, clocking in at 3.009 seconds of real time while a regular run took 2.805 seconds. Wow! I’m looking forward to seeing what the Legion of Rubinius Heroes can do with performance over the next couple of months.

If you’re interested in seeing more performance information, you might want to look at:

• JRuby 1.1 RC1 Real World Performance
• Real World Performance on Boxing Day

I’ve also written about profiling if you’d like to read more about that.

Rubinius Momentum

Evan Phoenix doesn’t update his blog very often, but when he does it’s worth reading. His most recent post is all about momentum, and it covers a cascade of big news in the Rubinius world.

It all started with the team finishing the new compiler. This led to an implementation of Kernel#eval, which led to a working irb, and so on …

Another indication of Brian Mitchell bringing up the idea of Io on Rubinius (which reminds me of my post Will rubinius Be An Acceptable Lisp from a year ago). While Brian hasn’t released working code yet, it’s certainly interesting that someone would even consider tryig to build an Io on top of a VM designed for Ruby.

Rubinius on JRuby

It looks like the JRuby guys are getting serious about running Rubinius on their platform:

"I added the minimum dependencies needed to get it rbx building and running bin/ci the same with JRuby" Charles Nutter

They're not all the way there yet, Charles reports that he's still hitting failure at the end of the build. It's getting closer though, and with the history of cooperation the Rubinius and JRuby teams have built I believe they'll have this licked soon enough.

Real World Performance On Boxing Day

Well, Ruby 1.9.0 landed yesterday, as expected. I’d be remiss if I didn’t start out by thanking matz, ko1, and all the other hackers involved in getting this milestone release out the door. It’s a great step for Ruby, and one that we’ve been waiting a long time for.

The bad news is that 1.9.0 is just a development release branch leading up to 2.0, and it doesn’t yet run Rails or Mongrel. There have been some scattered results on the mailing list of other problems as well. I’m sure they’ll get ironed out over the next several releases (which I hope will be frequent during the next year). There’s even a 1.9 specific library already—rev was released earlier this morning.

Fortunately, 1.9.0 is able to run LogWatchR just fine, so I’ve rolled out a new set of results from my ‘Real World Performance Test’. I hadn’t yet run a test using the JRuby 1.0.3 release, so I’ve included that as well. This time, I decided to show you the raw data for each version of Ruby I tested as well as the final results. I’m still using Ruby 1.8.5-12 for my baseline, as that’s our standard version at work (we may convert to JRuby 1.1 once that’s available—we’ll see). In any case, here are the numbers:

Ruby 1.8.5-12	Ruby 1.9.0-14709	JRuby 1.0.3	JRuby 1.1b
11.40	10.53	28.07	20.97
10.56	10.70	26.67	18.99
10.39	10.36	22.04	18.76
10.47	10.41	21.95	20.43
10.49	10.41	21.79	18.76
10.41	10.53	21.97	18.86
10.81	10.42	22.45	19.35
10.43	10.84	22.23	18.97
10.97	10.34	21.81	19.03
10.41	10.39	21.78	21.43

And here are the results:

	Ruby 1.8.5-12	Ruby 1.9.0-14709	JRuby 1.0.3	JRuby 1.1b
Average	10.63	10.49	23.08	19.56
Std Dev	0.33	0.16	2.3	1.0
Perf	100.00%	101.34%	46.08%	54.38%

I was a bit discouraged to see that 1.9.0 isn’t that much faster for my needs. JRuby is still slow for me too, but the regexp work that Charlie and the boys have been working on holds a lot of promise, I think JRuby 1.1b2 will tell a different story. I’m anxious to see rubinus, but it’s not quite there yet.

Update: Someone on reddit asked why there's not more background on what these numbers mean. I've got more information in some of my previous posts on the topic:

• Some Real World Performance Notes
• More Real World Performance Notes
• JRuby 1.0.1 Real World Performance Notes
• JRuby 1.1 Performance Numbers

The short story is that the times above are the time required for LogWatchR to run through about 75,000 syslog entries (about 20 minutes worth) and report on known bad or unknown log entries.

Breaking Rubinius News (And An Interview Too)!

Ok, I’ve been sitting on some news for a while and it’s finally out in the open, so I guess I can talk about it.

Engine Yard has just snapped up some seriously big guns in the Ruby world. From my conversations with them, is sounds like they’ll be putting in time on Rubinius as well as other Ruby enhancing projects. Here’s what Ezra told me about it:

The big plan for rubinius is that we will be hiring a bunch more top guns to get rubinius production worthy. These folks include Wilson Bilkovitch, Josh Susser, Ryan Davis and Eric Hodel and Yehuda Katz. I can’t think of any better people to get rubinius to 1.0 and beyond and running fast.

Update: Josh Susser isn't going to work for Engine Yard as noted below. I'll add something in a bit to clear things up. He told me "I should point out that I'm not going to work at EY. I'm at Pivotal now, and happy that things worked out that way, and no hard feelings anywhere either. I'll still be contributing to Rubinius, but not as an EY employee.". Sorry to pass along dated/incorrect info.

Update Two: Evan Phoenix says "In addition to Ryan and Eric, Wilson Bilkovich and Brian Ford will be starting with EY to be paid to work on Rubinius in the January. Again, I’m so amazed and thrilled that EY is providing Rubinius with the funds to let these guys work on a project they love fulltime." Maybe this'll teach me not to use a quote I've been sitting on.

Some of this seems to have been an open secret at RubyConf, but with Eric Hodel’s recent post on the current Rubinius spring I think it’s time to celebrate.

Speaking of the sprint, I asked the hackers involved if they’d be willing to answer a couple of questions in between coding up new rubinius goodness. This is what they told me:

This sprint looks like a big deal. What do you hope will come from it?

Eric Hodel Pure awesome.

This one has been part organizational, setting up the details of EY employment, and half hacking on things such as the compiler and RubyGems.

Josh Susser I’ve been looking for a way to get more involved in Rubinius, so to me it’s been an opportunity to find an area where I can contribute that makes sense. I love doing VM work, but I’m not much of a C hacker, which is a little problem if you’re going to work on a VM that’s written in C. As it turns out, one of the goals for the project is to build a simulation of the VM in Ruby itself. This will be the seed of the eventual Squeakification¹ of Rubinius, but in the near term it will help with understanding the operation of the C VM and doing experiments and explorations. If you hear the name Popgun somewhere, that’s the VM-in-Ruby simulator.

Brian Ford Lots of face-to-face time. The opportunity to work in person with folks and talk over process issues, brainstorm, pair, and socialize. We started off making a big and unrealistic but fun list of both serious and fun goals. As with most things, process will likely end up being much more important than the actual checklist of results.

Wilson Bilkovich For me it’s an opportunity to take a vacation from my ‘day job’ and get some actual Rubinius work done. I’ve had far too little time for that recently. We have a long list of sprint goals. Hopefully at least a couple of the major ones will get checked off.

What’s the best part of getting together for a sprint like this?

Brian Personalities. Some bits of technology can be inspiring, but I find people far more inspiring than most things.

Wilson Being able to siphon knowledge out of peoples’ heads at a much higher rate.

Eric Pairing. Having instant feedback for problems is unbeatable.

Also, Wilson and I added unit_diff support to mspec to aid testing of parts of the compiler.

Josh Aside from just getting to hang out with a lot of awesome guys, it’s a really different experience getting to talk in person about stuff. The IRC channel is okay, but it is so high-bandwidth that I have trouble keeping up. I get up to grab a drink and when I come back there are 300 new lines of stuff to catch up on. Also, mango lassis are yummy.

Are there going to be more Rubinius sprints? When, where, and what do you hope to accomplish in them?

Brian Certainly there will be more. The hope is to accomplish a ton of Rubinius development in the shortest time possible. A related goal is to reach out to other Ruby developers in a meaningful way so that their pain points using Ruby permeate our consciousness while we work to make Ruby better.

emacs vs vi? dvorak vs. qwerty?

Brian Textmate, emacs, vi, but I spend most time coding in Textmate. Qwerty, but I paired a bit with Nathan Sobo and he set me up with the input switcher, so now I have no excuse not to learn dvorak.

The first Rubinius specific project (other than Rubinius itself) was recently started at RubyForge. How big a milestone is this? What should we be seeing next from the Rubinius community?

Wilson Surreal.

Brian It is interesting from the perspective that it is a project just for Rubinius. But one of the goals of Rubinius is work wherever MRI works. So, that implies some sense of anonymity ( i.e. you should not even notice your program is running on Rubinius vs MRI). However, we do intend to use Rubinius as a platform to extend the state of the art of Ruby (e.g. with great concurrency primitives), so I fully expect to see new Rubyforge projects popping up that are Rubinius specific.

¹ Squeak

SICP 1.1.6 (Ruby) A look back at a look back

I didn't think to try the abs benchmarks in rubinius when I wrote up my first looking back post. A bit later, I decided to give it a whirl, and the script worked (minus a bug in the real time column). Here are the rubinius results:

$ shotgun/rubinius benchmarking_abs.rb
                     user     system      total        real
ternary:            0.985418   0.000000   0.985418 (       nan)
explicit:           1.039927   0.000000   1.039927 (       nan)
implied:            0.824196   0.000000   0.824196 (       nan)
system:             0.821973   0.000000   0.821973 (       nan)

Not quite as good as Ruby, but comparable or better than JRuby (interpreted and no special switched). I'm intrigued that the implied version looks better than the ternary or explicit (and in line with the system) though.

Rubinius Sprint Interview

A There’s been some good coverage of the recent rubinius sprint in Denver (see Brian’s Blog, Wilson’s Blog, and Tim Bray’s Blog for some of the details). I wanted to get a bit more information though, so here’s a mini-interview I did with Evan Phoenix, Wilson Bilkovich, and Brian Ford. (Thanks guys, for taking some time out of your busy days to talk about the sprint with me.

---

What were your personal hopes/goals going into the sprint?

Evan: My goal was to see how we rubinius work would progress in this kind of environment. I was extremely pleased how it went. The 4 of us really tackled things well, and working in a collaborative atmosphere really sped things up. I was also happy to be right there to transfer knowledge of some of the interior of the VM to other developers. That knowledge is more difficult to grasp than almost anything else in rubinius, but probably the most important.

Brian: My primary goal was to have face-to-face time with Evan and Wilson to talk about project related stuff. It was a plus that Charles came over. There’s a fair amount to the project besides just the architecture and details of Rubinius. Although we’ve had a fairly large number of committers, we haven’t had to deal with too many project management or organizational issues. I think we may have to deal with more of these in the future. So, just spending time in person was good, regardless of what we were working on.

My technical goals centered around getting the specs for the core libraries more usable and the CI runner working better. I also wanted to get more into the architecture and potentially do some interviews with Evan about Rubinius architecture details.

Wilson: I happen to still believe that aiming for 100% passing specs is the ‘right’ way to develop Rubinius. However, external pressure (perceived or real) to get ‘real’ applications running has been rising. I was hoping to get irb and Mongrel running during the sprint. As a historical curiosity, here is the rough list we worked up prior to the sprint.

How did you (collectively) do at acheiving them?

Brian: I’m not sure I can speak with relevance to how we did collectively. As with most things, there’s only so much value to organization. Our process ended up being more organic. I didn’t get any interviews done with Evan but I think that’s fine. Evan has mentioned doing some screencasts, which may actually be a lot more useful. Something along the lines of approaches to debugging a segfault, for instance, or adding a core library method. Evan was able to spend some time with both Wilson and I showing us some gdb tricks. He also explained our profiler and debugger architecture more to me. This was very helpful as it gives me a start working on more things that will help the dev process. I guess that’s what I end up spending a lot of time on: specs, the spec runners, the website, etc. Doing things that should enable other people to write more code. It can be frustrating at times, though, because I’d like to just be writing code. Overall, I think the time we spent has enabled me to do more to help advance the project.

Wilson: Technically, we didn’t get irb or mongrel running. However, when we actually sat down and discussed the realities of implementing them, several more important goals came to the surface. Many of those centered around knowledge transfer from Evan to Brian and me. Also, irb turns out to be an incredible nightmare. If it weren’t so hard to type, ‘Eye of Terror’ would be a better name for it. Here’s a fun part of irb. Yes, that’s a method that uses module_eval to define another method that itself uses module_eval to remove methods.

Despite all that, I think we made more progress than I really expected.

Sun provided some sponsorship, do you think they got their money’s worth? Why?

Brian: Absolutely. I, personally, am very grateful for the sponsorship. All in all, it wasn’t much money, but every little bit helps. The fact that Charles is collaborating with us, and that, for instance, I’m working very hard to make the specs implementation agnostic, means that the work we do is helping every Ruby implementation. Based on Charle’s work on the JRuby compiler, I believe there is huge potential for Rubinius and JRuby to share a common Ruby core library. Were that the case, both projects would benefit from it. And I often plug JRuby both publicly and in my work with Rails. Sun’s goodwill won’t go unnoticed, even if viewed skeptically by some folks.

Evan: Judging from Tim Bray’s blog post about why Sun kicked in the cash, I’d say yes. Sun is looking to enrich ruby by not placing bets, but rather push the entire community forward by helping anywhere they can.

Because the sprint was successful for the project, it was successful for Sun.

Wilson: Sun says that anything that’s good for the internet is good for Sun. Rubinius is good for the internet. While I definitely did not expect this a year ago, JRuby and Rubinius turn out to be of great benefit to each other. I’m looking forward to greater collaboration between the two projects. Charles is also vastly less irritating in person than he is on IRC. :)

What are your favorite outcomes/events from the sprint?

Evan: Just the fact that the sprint worked out great is one of my favorite outcomes. This being my first foray into project management, I was a little worried how it would go.

Wilson digging in and almost getting eval working is awesome. That’s definitely non-trivial and he managed it almost entirely on his own.

Brian: I think all of it is terrific, but I’ll name two things and a cool runner up. Evan’s work with Syck shows that our subtend interface really does work well. Wilson’s significant advances getting the machinery of ‘eval’ wired up is hugely important for a ton of code, especially in IRB and Rails. The colored backtraces might not seem like much, but that was a ‘fun’ accomplishment that is actually quite useful. At a glance you can distinguish core code from user code and easily pick out that top item in the backtrace.

Wilson: Listening to Evan implement YAML over the course of two hours was pretty impressive. I’m glad I got to witness that in person. Brian picked up the FFI ball and ran with it. That is an intensely cool part of Rubinius.

My favorite part was probably implementing StringIO, however. Evan wrote the StringIO code while I wrote the specs. We would each check in code, and say “ha ha! take that!” as we either exposed flaws or fixed them. It took about three hours start to finish, uncovered a ruby 1.8 bug that has since been patched, and the resulting implementation is good enough that JRuby is planning to adopt it as their own StringIO library.

Are you planning/hoping to do more of these?

Evan Hopefully before 1.0. It’s already almost October, so hopefully we’ll do a few day sprint on the west coast (LA or SF) in the coming weeks.

Wilson Yes please, and soon.

Brian Absolutely, just a matter of details. I seriously hope I’ll be able to attend, but I can’t know that for sure now.

More About SoC and Ruby (Get Ready for the Proposal Window)

Google hasn't announced their final selection yet for mentoring organizations, but I'm operating under the assumption that we will be. Given that, this is the time for people to start putting together proposals for student projects. The window is only about a week long, and is opens up in just a couple of days.

We've got mentoring volunteers from the JRuby, RoR, rubinius, ruby, and Xruby communities, so don't feel constrained to any particular field. On the other hand, projects that are liable to benefit the largest possible group of users are certainly going to get some extra karma.

If you're not a student, but have a great idea, feel free to toss it out for discussion. Who knows, maybe someone will pick it up and run with it.

Rubinius Contest Winner

Well, I learned an important lesson from this contest — never try to run a contest when your judge is going to be in Hawaii, there's no way you can compete against the beach.

In better news for the rubinius community (and for our winner), I did eventually get enough of Evan's attention to pick a winner. After a lot of thought, Evan's decided on a new name for RNI. Zed's subtend is the winner, and I'll coordinate with him to get his choice of books off to him.

rubinius serial interview: Episode VII (and a half)

With the great work that the rubiniius hackers in Portland, Oregon have been doing I thought I'd better sit down with them and find out more. Given their plans, we may see a few installments of this side interview.

---

I think you might be the first .rbc (rubinius coders) group around. I'm jealous. How and why did you guys start this up?

Thomas: I'm not really sure who got the idea rolling, but Aaron happened to mention an interest in rubinius at our last PDX.rb meeting (I missed the beginning of the meeting, so this probably had come up earlier). I expressed similar interest and he suggested getting together to hack on it. I don't know if the discussion with Phil and Brian happened before or after our conversation, but I was sure that it was the right approach to get the ball rolling. Trying to tackle a new project like rubinius is a bit intimidating, but when you have someone else sitting there to bounce things off of, it makes it a little less so.

Phil: I have been interested in Rubinius for a couple of months now, but it seemed to be moving so fast that it was difficult to get a hold on what was going on. When Aaron and I found out that Brian was involved in rubinius development it seemed like a great opportunity to for him to be our 'guide' to rubinius. It's great to be able to ask questions about the history of the code or why something was done. There's not a huge amount of documentation in Rubinius yet (hopefully that's changing) so it's tough to jump in and start contributing without someone to help explain how things are organized and why they are that way.

Brian: From my view, it was rather impromptu. When I attended the 2/6 pdx.rb meeting, I wasn't prepared to or planning on saying anything about Rubinius. Aaron and Phil piped up and I thought I'd throw my 2 cents in. I didn't think I had that much to contribute. Later in stroll over to LuckyLab (a nearby bar) Phil suggested getting together. Aaron posted an event to the pdxruby.org site and we met. Of course, I was thrilled to see some local interest, so I came prepared with a whole list of things we could work on. :) Irb seemed like a good place to start. If I have 2 tabs open in iTerm, one is probably IRSSI and the other is surely irb.

Aaron: I asked at the monthly pdx.rb gathering if anyone was interested in working together to contribute to rubinius. Both Phil Tomson, Brian Ford and myself had already signed up for commit rights. It quickly became apparent that Brian was up to speed on the activity in the irc channel and commit logs.

I really enjoyed meeting the guys up in Seattle a few years ago and have always hoped to be able to contribute to their on going projects. I like building groups that help each other, instead of rivalries.

I also feel more comfortable meeting in person to ask questions. Old habit, I suppose.

You picked irb as your first project, and it looks like you've got a simple working version out already. Tell us about it. How much work did you need to do on rubinius to get it working?

Brian: Unfortunately, I was probably a roadblock to getting sirb going during our meetup. I failed to grasp that we would have a persistent machine that would contain the state ( e.g. the state from previously evaluated expressions). Later last weekend, after thinking that an irb transcript would just be a program, and remembering that in Prototype B (the MRI-based VM Evan had prototyped) there was a Machine class, I looked for the analogue in shotgun (Prototype S, the C VM). From there, it wasn't a whole lot of work. Again, unfortunately, this was after our meetup so no one was around to share the excitement, except on IRC.

Aaron: We located the Readline.readline stub in kernel/core/readline.rb and replaced

  ""

with

 print prompt
 STDIN.read(1024)

and voila! the loop would await input. That was a really neat thing to see. When we started apps/irb/sirb.rb was in infinite loop awaiting input that would never arrive. Now it was an infinite loop awaiting our input. Yipee!

When we added Compile.execute(str) to the loop in apps/irb/sirb.rb Phil pointed out that this had no context which is something I had always taken for granted. So we then started looking at stdlib/irb.rb with ./shotgun/rubinius stdlib/irb.rb and examining the backtrace.

This lead into a tour that covered rspec, mri, target host, and what was left to do before rspec could run natively on rubinius and the convolutedness to run it until then.

Thomas: Well, honestly, what we did when we met bears little resemblance to what is out there now. We used it as a gateway mostly to try and understand how the compiler functioned (irb, or sirb, in this case, is perfect for this -- it has to invoke the compiler on small chunks of code as user inputs them). What Brian later committed was quite a bit more complete than what we had put together, but I guess the kernel of that got started in our initial attempt.

zenspider and Eric up in the Seattle.rb are big believers in using forcing functions to make their code better. How is (or isn't) sirb a forcing function for rubinius? What other projects are you going to work on that might be forcing functions for rubinius?

Thomas: Mostly sirb just sounded like a good first start -- we're all heavy users of irb in our normal ruby development. In fact, when I first started looking at rubinius, I looked for its irb implementation.

I think that mostly we'll just be looking for good bite-sized chunks of missing functionality, documentation or whatever that we can tackle in a single afternoon. Of course, one would hope that over time this leads to each of us being able to contribute even more on our own.

Aaron: Forcing functions are new concept for me. My driving force is to find something that can be done within a few hours and committed. The feeling of accomplishment is the biggest piece. I need to find out more about identifying forcing functions.

Brian: Well, I had to head over to Wikipedia to look up forcing function. :) I remember the use from my Diff Eq math class. I see sirb as both an extremely useful tool to have while developing code for Rubinius, as well as great way to expose how Rubinius works, You can, for instance, pass command line arguments that cause sirb to print the s-expression or assembly, etc. for every expression it evaluates. This could help people get a handle on what's happening during the compilation phase. The direct access to this should enable people to make quicker progress when working on Rubinius.

rubinius isn't the only thing you guys are working on, I also hear you're learning OCaml. How is that meshing with the Ruby, Garnet, and C work you're doing for rubinius?

Aaron: Learning other languages has always taught me more about ones I already know.

Thomas: This was our first meeting, so that remains to be seen. I didn't even realize that Aaron, Brian and Phil had talked about OCaml, but oddly enough, it's the functional language I've been most interested in studying for some time now. It remains to be seen how this will fit with the rubinius work, but I think at the least it shows a common interest in learning something new.

Phil: I'd like to add that I've been wanting to learn a functional programming language for a while now. After finding a presentation on the web (something like "The one day compiler") where someone had posted slides about how they created a make-like tool using OCaml I was impressed with the capabilities of OCaml and decided that I wanted to learn it. I also started seeing some ads show up in gmail about OCaml jobs in the financial industry, so that told me that people are starting to get paid (and apparently well paid) to code in OCaml. The fact that OCaml also supports OO programming was also a draw (I don't think that Haskell does?)

Brian: I think the consensus was that we'd focus on Rubinius, since adding OCaml to the mix could be distracting with the limited time we have available. However, hopefully we'll still entertain the idea of getting together to learn OCaml. I plan on using it in my current game theory math class to implement the finite state automata we're using to model repeated games, and compare that to a Ruby implementation.

---

This bi-week's sponsor is Ruby for Rails. Go grab a copy, it's a great way to learn a lot more about Ruby (and maybe get some ideas about hacking on rubinius along the way).

If you enjoyed this, you might also enjoy Nick Sieger's Serial JRuby Interview:

• Episode 1, in which Charles, Thomas, and Ola talk about their plans for JRuby.
• Episode 2, in which Charles, Thomas, and Ola talk about cooperation with the rubinius team and YARV.
• Episode 3, in which Charles, Thomas, and Ola talk about cooperation with the rubinius team Rails and (more about) YARV.
• Episode 4, in which Charles, Thomas, Ola, and Tor Norbye talk about JRuby and NetBeans.
• Episode 5, in which Charles, Thomas, and Ola talk about groovy.

You might also enjoy my new Serial Parrot/Cardinal Interview with Kevin Tew.

serial rubinius interview: Episode VII

Here's the first episode of the serial rubinius interview since we've gone to our new bi-weekly format. There's some good stuff in here about a roadmap, the new fastmethodcontext work Evan's been doing, and user contributions. Before we get to that, there's some great news in the rubinius community that I'd like to pass along.

One thing that I'm incredibly happy to hear about is a Portland, OR group that's meeting regularily to hack on rubinius (and learn OCaml — an odd combination). They've already turned out a simple, but working, irb. I'm in the middle of an interview with them that should be posted in the next day or so.

Another idea that has come up on the irc channel is an aggregator for rubinius blog feeds. There are a number of bloggers there: Evan, Wilson, Brian, mae (Matt Elder), and rue among them.

---

There's been some discussion about a rubinius roadmap on the irc channel. What are the odds we're going to see something like that? What's going to be on it?

Brian: Evan is definitely the one to set the roadmap. And I think it's important that he does it fairly soon so that we can focus on getting the essential features done for 1.0. This has become something of an issue recently as different people see Rubinius as a playground for ideas. While all the contributions are (mostly?) heartily appreciated, too little shared vision means too many separate directions. That's just plain tough with any project.

While I'm certainly not setting any roadmap, I'm all in for helping document it and explain it. I'm also continually pestering Evan to co-author a book. No one has announced anything about it, but Evan, Wilson, and I have talked about doing this together. I'll leave it up to Evan to decide if he wants to publicly confirm that.

The reason I think a book at this stage would be great is because it would get written while Rubinius development is occurring and will hopefully get a lot of folks interested. I think the AWDWR was a huge help in getting people knee-deep in Rails quickly, and doing things mostly right from the beginning.

Wilson: Compatibility with other Ruby implementations is one important item that we need to publicize. For newcomers to the project, knowing which behaviors are bugs, and which are deliberate differences that need a 'compatibility mode' added can be a challenge. Obviously a roadmap isn't a spec, but I think even a little treatment of this could help people get started.

Brian: I think compatibility is extremely important. Until now, what did we have to worry about? Just whether MRI was available on the platform. Now, with all these Ruby implementations, we have to consider it. The issue it, what is our reference for evaluating compatibility? What does 'compatibility' really mean. So far, I've seen people grabbing ideas of compatibility from other language domains and some of those aren't appropriate. Consider the recent concern that Rubinius having Tuple as a core class will encourage, or at least result in, some programmer coding in a dependency on Tuple. If that program is run on MRI without a compatibility class, it will fail. For me, that is more similar to a logic error in a program than an compatibility issue. It is also important to note that with rare exception, we are not changing the behavior of any core MRI class. Anyway, my main point is that we have some defining to do regarding compatibility. In Ruby, classes, methods, etc. can come and go at any time and duck-typing is the name of the game. So I think our idea of compatibility has to be defined similar to how we deal with 'types' and duck-typing.

Evan: A roadmap is absolutely necessary, because it sets the tone for 1.0 release. As for timeframe, I'm trying to finish up the patch to add FastMethodContext and a bunch of other speed related fixes. Once that's done, I'm going to do the first parts of the roadmap. I'll be on vacation for a week starting the 13th, so my plan is to return from the trip having done parts of the roadmap.

As for the contents of the roadmap, I plan to layout features and new classes to be implemented for 1.0. The list will include threading (Scheduler, Thread, NativeThread), additional hooks, and much more.

Evan, rue has been talking about the impending release of the new fastmethodcontext too. What can you tell us about this? How much of a performance impact will it have?

Evan: FastMethodContext increases the performance of the VM by simplifying the creation of stack objects, used to store information about method calls. Something like 85% of all objects created in the system are just stack objects, so making them faster helps speed up everything else. Due to the amount of time the system spends just creating, maintaining, and recycling these objects, improvement them vastly changes performance.

Back at the beginning of this serial interview, I asked you what contributions had surprised you the most. Now that we're a couple of months (and 500 or so SVN commits) further along, it's time to rephrase the question. What have been the most impactful contributions so far.

Brian: Hmm, good question. I think one significant thing is how much of the core lib is now passing specs. We have nearly 1,000 specs covering the essential classes like NilClass, TrueClass, FalseClass, Fixnum, Bignum, Float, Array, String, Regexp. Just a couple of days ago, out of 132 String specs, over 80 were failing. We're down to 50 or less. Most of the Float, Fixnum, and Bignum, Regexp, and Array specs now pass. This has been due to great contributions from a bunch of folks, so I'd say, the most impactful lately has been the contributions of a whole group of people. :) Nothing like getting collaboration going. If I were to single anyone out for special mention, I'd probably say Alan Hurdle (hurdlea). He pretty much single-handedly whipped Regexp into shape. There were some essential methods before, but now it's nearly complete.

Evan:I agree. Alan Hurdle has really kicked ass on many fronts. He's really shown how much the project lets people dive right in and make a big difference. My hope is that with more documentation and roadmaps, the interpreter will be as accessible as the ruby-basedruntime has proven to be.

Wilson: Several weeks ago, I wasted some time complaining about the Numeric API in Ruby. 'coerced_from', 'prec_f', etc.. there are tons of methods that are never used directly in user code; at least, no code I've ever seen. People came along shortly after that and implemented what looks like the whole set of them. That greatly improved the Rubinius feature set, and helped me understand why Ruby does it that way in the first place. Awesome.

---

This bi-week's sponsor is Ruby for Rails. Go grab a copy, it's a great way to learn a lot more about Ruby (and maybe get some ideas about hacking on rubinius along the way).

If you enjoyed this, you might also enjoy Nick Sieger's Serial JRuby Interview:

• Episode 1, in which Charles, Thomas, and Ola talk about their plans for JRuby.
• Episode 2, in which Charles, Thomas, and Ola talk about cooperation with the rubinius team and YARV.
• Episode 3, in which Charles, Thomas, and Ola talk about cooperation with the rubinius team Rails and (more about) YARV.
• Episode 4, in which Charles, Thomas, Ola, and Tor Norbye talk about JRuby and NetBeans.
• Episode 5, in which Charles, Thomas, and Ola talk about groovy.

You might also enjoy my new Serial Parrot/Cardinal Interview with Kevin Tew.

rubinius Interview: rue and IRC Summaries

Recently, rue has been posting summaries of important discussions from the #rubinius irc channel to the rubinius mailing list. This is a great way to catch up the discussions you might have missed.

---

What made you decide to start writing these irc summaries?

rue: I got back into looking at rubinius a month or so ago after finally getting some free time and did the normal signing up for the ML and idling on IRC routine. After a while I noticed that there is very little public communication despite the yelps of interest from all over Rubyworld and beyond. On IRC, it is usually just the knowledgeable regulars talking.

A good part of it has to do with the subject matter; people are apprehensive about diving in to a compiler project. The catalyst for any thriving newsgroup or ML and thereby the community are questions which yield answers and reciprocal information about the project and with people afraid to ask, the information flow just is not getting established.

So I decided to try to both keep the casual public informed and to try to encourage people to participate whether in discourse or committing code. It is a lot easier to get into rubinius than one would think.

Plus, as you can tell, I like to write.

How do you decide what to keep and what to drop from the summaries?

rue: The summaries are largely the result of personal bias and assumptions I make. Any news about the overall progress and new features and so on are automatically in but aside from that I tend to pick anything that was new or unclear to me or someone else on the channel.

The IRC conversation flow actually makes it fairly easy to highlight the important bits (after some signal to noise reduction practise.)

And some of the stuff in the summaries has nothing to do with IRC except that something there sparked an interest in me to write about it.

Do you have any plans to start putting your summaries into a blog or web format?

rue: Yes, as soon as possible. It is unlikely that I would at this point create any sort of a dedicated structure for these but once some technical problems are resolved, I will add these to my modest journal.

Which threads have you summarized that you think have the most value?

rue: It is hard to ascribe value that way; I like the chats that taught me something and I believe others feel the same way.

Anything that yields follow-ups and gets people involved is the most valuable for the project but it is hard to say which ones do that ahead of time.

Which threads do you remember from before you started summarizing them that you wish you could go back and capture?

rue: Mainly the architectural issues. The project often seems daunting and it will certainly take some time to get one's head fully around it. Anything that sheds light to how and why things are done is excellent material.

Quick rubinius Post

It's stuff like this that keeps reminding me that I should run a tumbleblog. Evan Phoenix has just posted a rubinius style guide ... if you want to hack on rubinius like the rest of the cool kids, you should go read it.

Win a Book and Help rubinius

Want to help the rubinius team? Want another chance to win a book? Well then, this just might be the post for you!.

Every good open source project relies on good names and other cool stuff to keep it running, and rubinius is no exception. We've been trying to come up with a good name for our C API layer for a while now, but we're still stuck with 'RNI' and that's just not good enough.

Now, we're turning to you, intrepid reader — and we're offering a reward. Here's the deal, I'll take submissions for a better name for the C API until midnight (MST) on February 18th (Chinese New Year) then Evan will pick the best name from the batch. All you need to do to submit a book is to enter it in a comment below, you can submit as many names as you like (you're welcome to submit multiple names per comment). The person who's entry is chosen will win their choice of one of these three books:

• Code Craft
• Code Quality
• Code Reading

The (not so) Fine Print:

• In the event multiple people submit the same name, the first person to have submitted it will be considered the winner.
• I'm relying on Amazon's free super saver shipping to get the books to you — if it can't ship to where you live, I'm sorry.
• Pleas avoid names with previous committments, we really don't want to have to go through the hassle of renaming something after Microsoft sends us a Cease &l Desist letter.