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
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.
No comments:
Post a Comment