def euler(x); cos(x) + i*sin(x); end - Home

A VM by any other name

2009-03-18T00:05:00Z

With the recent switch away from the spaghetti stack execution model, Rubinius has also acquired native threads. A big part of understanding something is syncing up our mental model with reality. If you’ve ever tried to explain what an OS is to your mom, you know that can be a challenge. So let’s peel back a few layers and see where these native thread critters fit into Rubinius.

Rubinius is an implementation of the Ruby programming language. One of the bigger components is the virtual machine. But what is that? Unfortunately, virtual machine is a label for a category of software (and maybe hardware) that, well, does a bunch of different things. Virtual machines are often thought of as virtual computers or virtual CPUs. The problem with trying to equate two things is that you look at the one you know about and try to understand the one you do not by looking for analogous structures. Therein lie the seeds of misunderstanding. Since Rubinius has this vm/ directory, we’ve got to try to nail some of this gelatin to the wall.

Thinking about threads running inside a physical computer, you might visualize the relationship something like the following Ruby-ish pseudo code. As the program starts up, it creates a virtual machine.


  1
2
3
4
5

  def main
  vm = VM.new
  # do some setup
  vm.run
end

Sometime later in the program, you add a new thread, which might be implemented something like this.


  1
2
3
4
5

  def Thread.new
  thr = VM.threads.create
  # ...
  return thr
end

You might imagine the VM instance having a Scheduler component that would supervise the threads and arrange for running them on one or more processors or cores. In this model, the VM is really like a virtual computer in which all execution is occurring. In other words, the VM is composed of multiple threads of execution.

The point of this mental exercise is to expose the tacit assumptions we might have about our mapping between a real computer and the virtual machine. Now let’s delve into Rubinius.

The main function is located in vm/drivers/cli.cpp. The first thing it does is create an instance of Environment, which is composed of an instance of VMManager, SharedState, and VM. In the Environment constructor, the command line is parsed for configuration options. Then the manager creates a new shared state. The shared state creates a vm. And finally the vm is initialized. During initialization, the ObjectMemory is created. The object memory in turn is composed of garbage collected heaps for the young and mature generations.

Back in main, a platform-specific configuration file is loaded, the “vm” is booted, the command line is loaded into ARGV, the kernel is loaded (i.e. the compiled versions of the files located in the kernel/ directory), the preemption and signal threads are started, and finally the compiled version of kernel/loader.rb is run, which will process the command line arguments, run scripts, start IRB, etc. When your script, IRB, -e command, etc. finish running, loader.rb finishes, main finishes, resources are cleaned up, and finally the process exits.

Whew. The point of this whirlwind tour is to illustrate that VM is a rather fuzzy concept, even though we have a class named VM. Now let’s take a look at how threads fit in.

Rubinius has a 1:1 native thread model. In other words, each time you do Thread.new in your Ruby code, the instance returned maps to a single native thread. In fact, let’s look at the code for Thread.new in kernel/common/thread.rb.


  1
2
3
4
5
6
7
8
9

  class Thread
  def self.new(*args, &block)
    thr = allocate
    thr.initialize *args, &block
    thr.fork

    return thr
  end
end

The calls to allocate and fork are implemented as primitives in C++ code. They are short, so we’ll take a look at them, too.


  1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

  Thread* Thread::allocate(STATE) {
  VM* vm = state->shared.new_vm();
  Thread* thread = Thread::create(state, vm);

  return thread;
}

Object* Thread::fork(STATE) {
  state->interrupts.enable_preempt = true;

  native_thread_ = new NativeThread(vm);

  // Let it run.
  native_thread_->run();
  return Qnil;
}

The call to allocate creates a new instance of VM as thread local data. The call to fork creates the new native thread. The call to native_thread_->run() will eventually call the __run__ method in kernel/common/thread.rb. Something to note about this snippet of C++ code is the nice consistency between the primitives and the Ruby code that calls them.

We’ve encountered the VM class in two contexts: 1) when starting up the Rubinius process, and 2) when creating a new Thread. We can consider the VM instance to be an abstraction of the state of a single thread of execution, and in fact, state is the name most often given to an instance of VM in the Rubinius source.

As we’ve seen, Rubinius as a running process is composed of various abstractions, including the Environment, SharedState, NativeThread, and VM to name a few. While it is accurate to call Rubinius a virtual machine, it is apparent that concept can cover a fair bit of complexity. But breaking it into parts makes it fairly easy to understand. Let us know what things you’d like to understand better. We have the doc/ directory in the source that we’re (slowly) building out. If you’re interested in contributing, docs would be a great way to help everyone.

Come to the Open Source Bridge conference

2009-03-06T22:24:00Z

If you live in or would like to visit beautiful Portland, OR, consider signing up for the Open Source Bridge conference. I will (probably) be giving a talk on RubySpec and Rubinius 1.0. There’s lots of interesting folks giving great talks. This is an opportunity to hear how people are developing the open-source community.

Hope to see you there!

What is RubySpec?

2009-03-03T19:41:00Z

According to the folks over at http://rubyspec.org, “RubySpec is a project to write a complete, executable specification for the Ruby programming language.” As with any sufficiently concise summary, there’s some opportunity for misunderstanding here, so let’s explore a few aspects of this definition.

Since this post is a bit long, here’s a summary:

There is one standard definition of Ruby.
RubySpec benefits the whole Ruby ecosystem.
RubySpec does not guarantee that program A will run on implementation B.
RubySpec includes only specs for the correct behavior when bugs are discovered in MRI.
Help your favorite Ruby implementation by contributing to RubySpec.

First, what does it mean to be “the Ruby programming language”? The answer to this question used to be a little simpler before Ruby 1.9. Originally, there was the single Ruby implementation that Matz and friends built, referred to as MRI (Matz’s Ruby Interpreter). Now there is also RubyVM or KRI (Koichi’s Ruby Implementation) or simply Ruby 1.9. Either way, MRI 1.8.x and [KM]RI 1.9.x are the standard or reference implementations for Ruby. Everyone else is making an alternative implementation that either complies with the standard or deviates from it.

This is the way RubySpec is written. I realize that it’s possible to consider “the Ruby programming language” to be an abstract thing and all the Ruby projects as merely more or less equal attempts to implement the language. I won’t try to convince you that either way of viewing this is more or less correct. I just want to be clear about the way RubySpec views it.

At the time I began writing what eventually became RubySpec, the only Ruby implementation in wide-spread use was MRI. My biggest concern when getting involved with Rubinius was that the project would be consistent with Ruby the way Matz defines it and not cause fragmentation of the language. My reason was quite selfish. I loved programming in Ruby and I wanted to see the language thrive.

So, RubySpec’s over-arching value proposition is a single, comprehensive definition of the Ruby programming language. To see if the value proposition is actually universal, let’s examine the three categories of people involved with Ruby: consumers, programmers, and implementers.

I define consumers as anyone who depends on a product or service written in Ruby. Consumers may use these products and services directly, or they may own or work for companies that provide them, or they may use products and services that are themselves supported by software written in Ruby. Consumers are the biggest part of the Ruby ecosystem.

Interacting closely with the consumers are programmers, the men and women who write software or frameworks in Ruby. In fact, the same folks may be both consumers and programmers.

The implementers are the people writing Ruby implementations for the programmers and consumers. They want to experiment with ways to better support programmers without worrying that they are breaking their programs in unknown ways. Again, the implementers may be programmers or consumers themselves.

If you’ve ever used a proprietary implementation of a programming language or know what vendor lock-in means, then I am preaching to the choir. If not, then consider that system requirements change, hardware changes, services change, customers change, development teams change, everything changes.

Consumers want assurance that the products and services on which they depend will remain available and will grow with their needs. Programmers want assurance that they will be able to meet their customers’ needs. Implementers want to provide programmers the ability to do so. A single, consistent Ruby language really is a win-win-win situation.

With everything seeming so sunny, one may be tempted to think: “If implementation A and B perform the same on RubySpec, then a program running on A now should run just fine on B.” Unfortunately, it is not quite that simple. Just as a program may not run on both OS X and Linux simply because MRI runs on both. Once in a while, RubySpec finds bugs in MRI, though not that often considering the tens of thousands of expectations. Since a lot of the code in MRI has been around for years, this illustrates that even running thousands of programs (RubySpec is just another program) is no guarantee that there are not bugs lurking around the corner.

What can tell you whether a program will (likely) run on both A and B is the program’s own test suite. In this regard, the program’s test suite and RubySpec are complementary. If the tests discover something that RubySpec did not, it is an opportunity to enhance RubySpec. If running on another implementation expose issues not uncovered by the program’s tests, it is an opportunity to enhance the tests.

Ruby versioning is complex affair and another area where possible misunderstandings exist about RubySpec. It seems pretty simple that Ruby 1.8 and Ruby 1.9 are different. But then there is 1.8.7, which is like 1.8.6 and 1.9. And there may be 1.8.8, which will likely be different than 1.8.6 and 1.8.7 and 1.9. It is dizzying. RubySpec handles the different versions by using the ruby_version_is guard. (Read the guard documentation for full details.)

Generally, the version guards work fine. Each implementation provides the RUBY_VERSION constant and based on its value, the guards permit the correct specs to run. Some have assumed this means RubySpec will tell you that alternate implementation A is just like MRI version X.Y.Z “bugs and all” because A says it is version X.Y.Z.

The principles RubySpec strives for are correctness, clarity, and consistency. There is no way to provide clear and consistent results if RubySpec included specs for the wrong behavior as well as specs for the correct behavior. Either clarity or consistency suffer, badly. Matz is the one who ultimately determines whether a behavior is a bug or not. RubySpec simply includes specs for only correct behaviors.

These are some of the factors that complicate this issue:

There is no definition of what is a bug. It may be a segfault, an incorrect value computed, a frozen state not set or respected, the wrong exception class raised. The list is endless and impossible to consistently categorize.
All implementations, including MRI, have their own release processes and schedules.
RubySpec is a social as well as technical project. An aspect of the value-added proposition for any given implementation is the quality that they provide. There is no way the alternative implementations will consistently agree to defer fixing bugs until MRI releases a fix. Rather than supporting cherry-picking which bugs to fix, RubySpec only includes correct specs.
Bugs discovered by RubySpec in MRI are quite rare.

Finally, contributing to RubySpec is one of the lowest barriers-to-entry means of supporting your favorite Ruby implementation and the Ruby ecosystem as a whole.

Consider what the view looks like from the outside: Ruby has a vibrant community of implementations meeting consumers’ and programmers’ needs on virtually every significant platform, including on Java, .NET, Mac (Obj-C), and semi-platform-agnostic implementations like MRI and Rubinius. Internally, it means that Ruby programmers can focus more on writing their programs using the best tools for the job, confident that if requirements change they can move to a different platform with ease and confidence.

Check out the RubySpec docs if you are interested in helping out.

When describe'ing it ain't enough

2009-03-03T07:01:00Z

One of the things I like about the RSpec syntax is that it packs a lot of information into a few concise, consistent constructs. It’s relatively easy to read through a spec file and pick out what I am looking for. The use of blocks both enable flexible execution strategies and provide simple containment boundaries.

Perhaps the most valuable aspect, though, is the ability to extend the RSpec syntax constructs easily and consistently. No need to grow a third arm here. In Rubinius, we recently encountered a situation needing some extra sauce when fixing our compiler specs.

A compiler can be thought of as something that chews up data in one form and spits it out in another, equivalent, form. Typically, these transformations from one form to another happen in a particular order. And there may be several of them from the very beginning to the very end of the compilation process.

To write specs for such a process, it would be nice to focus just on the forms of the data (that’s what we care about) with as little noise as possible about how they got there. Here’s what we have in Rubinius:


  1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

  describe "An And node" do
  relates "(a and b)" do
    parse do
      [:and, [:call, nil, :a, [:arglist]], [:call, nil, :b, [:arglist]]]
    end

    compile do |g|
      g.push :self
      g.send :a, 0, true
      g.dup

      lhs_true = g.new_label
      g.gif lhs_true

      g.pop
      g.push :self
      g.send :b, 0, true

      lhs_true.set!
    end
  end
end

The relates block introduces the Ruby source code and contains the blocks that show various intermediate forms. A single word like parse and compile encapsulates the process of generating that particular form, as well as concisely documenting the specs.

The format is sufficiently flexible to allow for other forms. For instance, ast for generating an AST directly from the parse tree rather than using the sexp as an intermediate form. Or llvm to emit LLVM IR directly from our compiler.

Another interesting aspect of this, it was possible with only a few custom extensions to MSpec. Recently, I had added custom options to the MSpec runner scripts to enable such things as our --gc-stats. I didn’t know how easy it would be to add something more extensive. Turns out it was pretty easy. You can check out the source in our spec/custom directory.

Boxers or Briefs? -- Neither?!

2009-03-03T06:17:00Z

The emperor is wearing clothes and everything looks hunky-dory and sane on the outside. Usually, that’s a good thing. For instance, when running RubySpec on a released version of MRI, it’s good to know that things are behaving as expected and all known issues are accounted for. In other words, you won’t see any failures unless a spec is broken or a new spec has uncovered a bug.

$ mspec library/stringio/reopen_spec.rb 
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
........................

Finished in 0.021797 seconds

1 file, 24 examples, 59 expectations, 0 failures, 0 errors

While the above can be reassuring, it may not tell the whole story. RubySpec uses guards to control which specs are run. This enables the specs to accommodate differences in behavior due to varying platforms, versions, implementations, and bugs.

I’ve added a couple features to MSpec to enable discrete and not-so-discrete peeks under the robes, as it were. The first of these is akin to just yanking down the trousers. By passing the --no-ruby_bug option, all ruby_bug guards are disabled and the guarded specs are run.

$ mspec --no-ruby_bug library/stringio/reopen_spec.rb 
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
............FF.....FF.....FF......

1)
StringIO#reopen when passed [Object, Object] resets self's position to 0 FAILED
Expected 5
 to have same value and type as 0

./library/stringio/reopen_spec.rb:117
./library/stringio/reopen_spec.rb:110:in `all?'
./library/stringio/reopen_spec.rb:61

---- snip ----

Finished in 0.022210 seconds

1 file, 34 examples, 76 expectations, 6 failures, 0 errors

If you cringe a little when blasted by a bunch of failures, don’t worry, So do I. For a more subtle examination, there is also the ability to run the specs and note which specs would have run but did not due to guards.

$ mspec --report library/stringio/reopen_spec.rb 
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
........................

Finished in 0.009809 seconds

1 file, 24 examples, 59 expectations, 0 failures, 0 errors, 10 guards

4 specs omitted by guard: ruby_bug #, 1.8.6.114:

StringIO#reopen reopens a stream when given a String argument
StringIO#reopen reopens a stream in append mode when flagged as such
StringIO#reopen reopens and truncate when reopened in write mode
StringIO#reopen truncates the given string, not a copy

6 specs omitted by guard: ruby_bug #, 1.8.7:

StringIO#reopen when passed [Object, Object] resets self's position to 0
StringIO#reopen when passed [Object, Object] resets self's line number to 0
StringIO#reopen when passed [String] resets self's position to 0
StringIO#reopen when passed [String] resets self's line number to 0
StringIO#reopen when passed no arguments resets self's position to 0
StringIO#reopen when passed no arguments resets self's line number to 0

The guards are reported only if they have altered how the specs were run. Since the ruby_bug guard can only prevent specs from running on the standard implementation, MRI, those guards are not reported when running under JRuby, for instance.

$ mspec -t jruby --report library/stringio/reopen_spec.rb 
jruby 1.2.0RC1 (ruby 1.8.6 patchlevel 287) (2009-02-26 rev 9326) [i386-java]
..................................

Finished in 0.257000 seconds

1 file, 34 examples, 76 expectations, 0 failures, 0 errors, 0 guards

So, if you are wondering what is going on with some specs for a particular library, you can get a quick peek using the --report option before digging into the spec files. There is also a --report-on GUARD option that allows you to narrow the focus of your peeking.

Warning: Includes Known Bugs

2009-02-26T01:15:00Z

UPDATE: In further discussions with Jim Deville of IronRuby it appears that there may be a legal issue preventing IronRuby devs from patching Ruby code themselves. However it may be possible for IronRuby to use a commonly maintained and patched version of the standard library.

Reviewing the logs and considering this was Shri’s first major discussion in the IRC channel, I unfortunately grouped him in with Charles’ intolerable behavior and personal attacks which have occurred on a number of occasions in #rubyspec and #rubinius. My apologies to Shri. The struck out text below remains merely for historical accuracy.

UPDATE: Charles response to this post wasn’t exactly positive, but I think it’s fair to have this discussion in public: http://pastie.org/400493 Also, please note that I’ve struck out Shri’s name below as I may have misunderstood him in the earlier discussion.

You, the trusting consumer, would probably like to receive such cautionary advertisement were you to use a product that did, in fact, ship to you code that includes known bugs. And not just known bugs, but known bugs that have fixes for them.

You would like to know this, right? I mean, I’m not just some hard-headed asshole that thinks there’s something a bit whack here, am I? Please, do tell me.

Well, as luck would have it, you can also tell this to Charles Oliver Nutter of JRuby ~~and Shri Borde of IronRuby~~.

Here’s the drama: There’s this project RubySpec. You may have heard of it. It attempts to describe the behavior of the Ruby programming language. All the alternative Ruby implementations use the RubySpec project to attempt to show that they are “Ruby”.

All the alternative implementations also choose to ship some version or other of the Ruby standard library. At least the parts written in Ruby. Makes sense, since they all implement the Ruby programming language.

As is the case with all software, from time to time bugs are discovered in Ruby. Usually, these are fixed soon after they are discovered and the fix is committed to the trunk version of MRI (Matz’s Ruby Implementation). Eventually, trunk becomes another stable release with a particular patchlevel.

The RubySpecs deal with this situation with a ruby_bug guard. You can read the details of RubySpec guards. This particular guard has two functions:

It prevents the guarded spec from executing on any version of MRI less than or equal to the version specified in the guard. This is because MRI cannot re-release a particular patchlevel after it has been released. And the bugs are discovered after a release.
It documents the spec, which shows what the correct behavior should be.

A key feature of the ruby_bug guard is that it does not prevent the spec from running on any alternative implementation. That is because every alternative implementation is expected to have the correct behavior. Additionally, these guards are only added after Matz or ruby-core has stated that the behavior at issue is a bug and the behavior of the spec is the correct behavior.

Now here is the rub, Charles does not want to manage patching the Ruby standard library that he ships with JRuby with the patches that already exist for known bugs. He wants to ship whatever version MRI has most recently released. Further, when you run the RubySpecs with JRuby, he wants to MASK those bugs because he doesn’t think it’s fair that JRuby fails a spec which shows a known bug in the Ruby standard library for which patches are available.

That’s Charles choice of strategies for managing JRuby packaging. I’m strongly of the opinion that you, the user, would like to know that. Charles apparently disagrees.

In fact, he disagrees so vehemently that he takes to calling me names in the #rubyspec IRC channel because I refuse to change the fact that the ruby_bug guard will not silently mask spec failures on JRuby or any other alternative implementation. Aside from being immature, I think there is a real problem with this. Don’t you?

Charlie will argue that it is simply impossible to ship the trunk version of Ruby standard library because it is an unknown quantity? However, the best defense against bugs in the Ruby standard library is better specs. And we’re talking about specs here that show the bugs and for which patches exist. Furthermore, there are actually relatively few bugs noted in the specs and most of those are in older versions of Ruby, not the current stable release.

So, here’s my question to you: Would you like to know that JRuby ~~and possibly IronRuby~~ ship you code that contains know bugs for which patches exist? Would you also like to know that Charles wants you to run RubySpec on JRuby and not know there is a bug?

Caveat Lector

2009-02-20T23:36:00Z

I really did double-check this time and I won’t be making any wild claims here. Sorry to disappoint.

We’re going to be running Antonio’s Ruby Benchmark Suite daily to track our progress on performance in Rubinius. The current RBS is a bit of a beast so I imported the files into the Rubinius repository and did some refactoring. You can read the details and up-vote that if you’d like to see this merged back.

Now, for some baseline RBS results. If you want to follow along at home, here’s what I did. I generated these by running the rake bench task using the VM option (see the benchmark/utils/README in the Rubinius repository) for Rubinius on the stackfull and master branch and for MRI using the version installed on Debian lenny, 1.8.7p22. The system is a dual Intel® Xeon™ CPU 2.40GHz. Then I ran the rake bench:to_csv task, imported the CSV file into Google Docs, added the comparison columns and colors, and exported to PDF.

Here’s what I got. The green is faster, the red is slower. The reported time is the minimum time recorded in five “iterations” of each benchmark per input. The maximum time allowed to run five iterations is 300 seconds, or an average of 60 seconds per iteration.

A few notes about these numbers:

We’re still fixing the breakage on the stackfull branch, so it is not surprising, for instance, that all the thread benchmarks errored out. The new native thread support is not 100% done.
There are a couple speed regressions on the stackfull branch, most minor. We’ll fix those.
Most of the benches do run on the stackfull branch.
On most of the benches that run slower in stackfull than MRI, we’re 2x or less slower than MRI.
We are a lot faster than MRI on quite a few benchmarks.
Rubinius on either branch does quite well relative to MRI on benches that MRI times-out on for certain inputs.

Perhaps the biggest point about the stackfull branch is that we haven’t done much optimization at all. Evan’s been coding in the basic new interpreter architecture, fixing the GC interaction, adding the native threading. We’re fixing breakage now so we can get this merged into the master branch. The JIT is not hooked up. The new GC work is not done. There is no inlining. In other words, there is lots of head room. And that is the key point. You can’t just “make it faster”. Architecture is crucial. Since RailsConf 2008, we’ve been working hard to lay the architectural foundations. With those (and the switch away from stackless), we can start focusing on the real dynamic language optimizations.

While the benchmarks tell part of the story, there’s another part that is even more interesting IMO. And this is the part that got me so excited I, um, well I just got excited...

The two biggest pieces of Ruby software that we most often run are the Rubinius compiler and the RubySpecs. The RubySpecs are much more “real-world” than these benchmarks. Here are the results of two complete CI runs on master and stackfull. Note that we are not quite running all the basic CI specs on stackfull, but we’ll figure in that difference in our calculations below.

First, on master:

  $ bin/mspec ci --gc-stats
  rubinius 0.10.0 (ruby 1.8.6) (f4c5576c4 12/31/2009) [i686-apple-darwin9.6.0]

  Finished in 131.248169 seconds

  1430 files, 6927 examples, 23006 expectations, 0 failures, 0 errors

  Time spent in GC: 51.6s (39.3%)

And then on stackfull:

  $ bin/mspec ci --gc-stats
  rubinius 0.11.0-dev (ruby 1.8.6) (e7b6a2d56 12/31/2009) [i686-apple-darwin9.6.0]

  Finished in 66.357996 seconds

  1349 files, 6298 examples, 21344 expectations, 0 failures, 0 errors

  Time spent in GC: 12.7s (19.1%)

Let’s calculate how we do in expectations per second:

  $ irb
  >> master = 23006 / 131.248169
  => 175.286254850534
  >> stackfull = 21344 / 66.357996
  => 321.649255351232
  >> stackfull / master
  => 1.83499416782851

So, compiling and running the specs is about 1.8 times faster on stackfull. This is upside down from the normal results. Normally, we do better on the micro benchmarks and see that invert on “macro” benchmarks. On the RBS benches, stackfull is not 1.8 times faster than master. If I average the “x Master” column, I get 1.39.

There was something else in those spec run numbers I wanted to talk about… oh yeah, GC stats. We have a very simple GC timer stat right now. I’m going to be adding a few more stats. But what we see here is that the overall percentage of time spent in GC drops by half in stackfull. Even so, 19% is too much time to spend in GC. We expect to drop that by half again. Basically, leaning more on structures alloca'd on the C stack reduces a lot of pressure on the GC.

Some would toss out that it’s not hard to be faster than MRI. Perhaps. But it is an accomplishment to write a reasonably good VM, garbage collector, compiler, and Ruby standard library without importing anyone else’s code. And, lest we forget, that is two VM’s in about 27 months of a public project.

Some would also question the sanity of writing a VM and garbage collector when crazy smart people do things like that. Well, crazy smart people write papers that reasonably smart people can read and understand. From the benchmark result above, that is working pretty well.

Here’s the point: Don’t ever let anyone tell you that something is a bad idea. Make your own decisions. We probably wouldn’t have Ruby itself if Matz fretted over whether Larry Wall or Adele Goldberg were smarter than he. My most recent favorites in this space: Factor, Clojure, and yes, tinyrb.

We’re working frantically to get the stackfull branch breakages fixed and the branch merged back into master. Feel free to poke around and ask questions.

This is NOT cold fusion

2009-02-12T19:39:00Z

Um, whoops. It was really late last night. Have I mentioned you’re wearing a great outfit today. Ok, already.

There’s this slight matter of DEV=1 rake build in Rubinius. Yes, I was debugging something. Started running some stuff under the stackfull branch, was intrigued by what I was seeing, decided to make some comparisons, could swear I ran rake clean; rake in the master branch, had a lot of green tea yesterday…

All right already. It’s not 4x faster. Here’s some new numbers:

Master branch:

$ bin/mspec ci core/string
rubinius 0.10.0 (ruby 1.8.6) (781eb14d3 12/31/2009) [i686-apple-darwin9.6.0]
.....................................................................

Finished in 10.576468 seconds

69 files, 763 examples, 5632 expectations, 0 failures, 0 errors

Stackfull:

rubinius 0.10.0 (ruby 1.8.6) (325174a8e 12/31/2009) [i686-apple-darwin9.6.0]
..................E.....E...E...F............E..E.EE..E........F..F..

Finished in 6.124444 seconds

69 files, 763 examples, 5545 expectations, 6 failures, 19 errors

That’s about 58% as long, or 42% faster, or creeping up on 2x.

If you rushed out and bought Evan a Valentine’s bear, I do apologize. But send it anyway. All the rest in my previous post about this being the beginning of a very good thing still holds. We’ll be getting more results soon and fixing the spec breakage on the stackfull branch. Stay tuned!

All shiny and new

2009-02-12T17:22:00Z

UPDATE 2.0: You really did see the update below, right? You’re getting Charlie all worried with your enthusiasm for Rubinius.

UPDATE: Ahem, you should probably also read: This is NOT cold fusion. No, it’s not April 1st. Sorry about that. Are you still excited? Read on!

It’s a pattern I’m fairly familiar with now. Evan will be pondering an issue with Rubinius. I’ll catch wind of it when he starts asking some questions of smart people, reading academic CS papers, other implementation’s code, and tossing out some “what if…” questions. Next thing you know, he’s frenetically churning out code. Suddenly, Rubinius is much better, and in this case, faster.

Well, it’s happened again and the preliminary results are outstanding. A couple weeks ago, Evan began coding some changes to the way the Rubinius bytecode interperter works. He changed the stackless execution architecture that implemented an optimized kind of spaghetti stack to use the C stack more directly and naturally. This better enables the CPU optimizations of the past dozen years to work. It also significantly simplifies the code for our FFI, C-API for C extensions, JIT, and for potentially leveraging LLVM much more effectively. This change also brings native threads, and a much better GC for the mature generation is also in the works.

Now, for some details. Again, these results are preliminary. There is still a lot of breakage on the stackfull branch but MSpec is already running and many of the CI specs run. I’ll be getting a new CI set in place today and we’ll get the remaining breakage fixed quickly (don’t ya just love those specs).

Here’s some numbers for compiling and running the String specs.

First, on the Rubinius master branch:

    Finished in 25.829773 seconds

    69 files, 763 examples, 5632 expectations, 0 failures, 0 errors

Now, on the Rubinius stackfull branch:

    Finished in 5.834874 seconds

    69 files, 754 examples, 5563 expectations, 6 failures, 19 errors

Here’s the numbers for running after the specs have been compiled.

Again, on the master branch:

    Finished in 5.101799 seconds

    69 files, 763 examples, 5632 expectations, 0 failures, 0 errors

And now the stackfull branch:

    Finished in 1.564942 seconds

    69 files, 754 examples, 5563 expectations, 6 failures, 19 errors

I’ll let that sink in a bit…

The numbers for Hash with compilation are similar.

Master:

    Finished in 5.379050 seconds

    48 files, 195 examples, 425 expectations, 0 failures, 0 errors

Stackfull:

    Finished in 1.295544 seconds

    48 files, 193 examples, 421 expectations, 0 failures, 0 errors

That’s right, ~~between 4.1 and 4.4~~ approaching 2 times faster (see the UPDATE above). And we are just getting started. The significant GC changes are not in yet. We are not yet doing any significant optimizations in the compiler, no profile-directed optimizations at runtime, and our nascent JIT is not hooked up by default. As I said at the outset, these optimizations are made easier by this architecture change.

While I’m breaking the news, Evan deserves the credit for the architecture decisions and generally being courageous enough to try and learn (some would say fail) and try again. Some have doubted that the lofty goals Rubinius has set are realistic. Doubters have a seat.

If you want to try this at home, clone the Rubinius Github repository and do the following:

    $ git branch --track stackfull origin/stackfull
    $ rake build
    $ bin/mspec ci core/string

Thanks to Engine Yard for trusting in Evan’s excellent judgment and system architecture talents and in all our hard work even if it doesn’t look immediately relevant. The path is clear. The goods are in the truck and they will be delivered.

Call of the lemming

2008-11-23T06:30:00Z

It’s sometimes hard to gauge troll, tirade, or spirited challenge online. The Opposite of Momentum strikes me as a mix, though in what percentages, I haven’t decided. KirinDave is a little late to the bag-on-Ruby party, and if it’s Javascript he wants, Yegge was there well over a year ago. Browse some of the mind-expanding comments by the bottom feeders at Reddit chewing on KirinDave’s post. It’s a reassuring, if disappointing, commentary on the consistency of human behavior: it is always easier to complain than to fix.

But, anyway.

True, the reference implementation of Ruby has some problems. But, Rubinius has a precise, generational garbage collector. It is definitely not “technically stagnant”, nor is it “in implementation limbo”. It was only in May of this year, before RailsConf, that we first got Rails running on Rubinius. We are close to getting it running again on the new VM. If we do that by year’s end, we will surely have some kind of record. For all the thousands of lines of Ruby code he’s written, KirinDave hasn’t contributed any code to Rubinius. That’s too bad.

Ruby isn’t that extraordinary as a language. But it is a very good language. What is more, Ruby is a humane language, in the spirit of Jef Raskin’s The Humane Interface. Furthermore, now like never before is the age of the dynamic programming language. The technical hurdles are being explored all around us. In fact, before the year is over, you should spend a few quality hours with one or more of the following languages.

Factor. This fascinating concatenative language will definitely get you thinking outside of the box. Rubinius is a stack-based VM. Writing some Factor code is a little like peeling back the syntax layer of Ruby and watching the muscles and tendons work. Check out the quotations and combinators and think about how you write functional code with Ruby. Don’t miss the Google tech talk by Factor’s creator, Slava Pestov.

Clojure. This is another fascinating language by another wicked smart guy, Rich Hickey (check out the video). In fact, this is currently my favorite language to study. It’s the Ruby of Lisps, in my opinion. And it contains a wealth of ideas that could be useful for implementing Rubinius, not to mention, thinking about writing concurrent programs.

Io. Like Javascript? You owe it to yourself to play with this language a bit. I’d be interested to see about an implementation of Io on SquirrelFish Extreme

Haskell. Amaze your friends and improve your sex life. Jump stateful, side-effect tangled heaps of code with a single Monad. There is a cool new online book that will soon be released in print as well.

Seriously, if you are a Ruby programmer, you could hardly do poorly by adopting any one of these languages. If Javascript makes your curly braces tingle, who am I to ridicule you. But if Ruby continues to maintain its captivating hold on your attention, don’t be disappointed. There is some awesome sauce in there, and we’re working on the recipe that really makes the flavor pop. Just a little request, instead of bitchin’, pitch in.

Rubinius is a community project

2008-11-18T22:03:00Z

Yesterday was a tough day. You can read the details and Evan’s thoughts about it.

It was especially hard for me because Wilson was a mentor of sorts and the first person I talked to when I dropped into the #rubinius channel nearly two years ago. He allayed any fear I had that Rubinius would fragment the Ruby community and helped me get started contributing.

And Eero, among many other things, jumped on board right away and toiled for many hours on the early specs, putting up with my dead ends when the project that is now RubySpec was merely an expedient to fast-track Rubinius development.

So, I want to express my thanks to my teammates and wish them the best in their next endeavors. And I want to emphasize something that is well known to those of us who have worked hard on Rubinius from long before Engine Yard began to support the project: Rubinius is a community project.

Evan’s free-flowing commit bit, the early adoption of Git, and the emphasis on writing specs while developing are just a few aspects that have helped propel Rubinius very quickly in its couple year history. And there is still plenty of exciting and interesting work to be done. We are all very grateful for Engine Yard’s support of the project, and that support remains strong and dedicated.

But the key to Rubinius’ success is the community. In the past year, I feel we have to some extent let you, the community, down. We need to make Rubinius even easier to try out, understand, and contribute to. And we need your feedback on ways we can do this. The recent VM rewrite has been a huge step forward in this regard. But have you opened up the code, poked around, asked us about stuff that doesn’t make sense? If you haven’t, let us know why not. Have you taken a look at a failing spec for the core library? There’s tons of beautiful Ruby code just begging for some love. Let us know what barriers prevent you from spending some free time in there.

If you’re worried that development on Rubinius will slow down, I would challenge you to not let that happen. Evan produces prodigious amounts of code and has a terrific mix of genius and pragmatism. I will certainly not be working any less hard than I have for the past two years. So if you, like me, believe that Rubinius can be a terrific platform for Ruby, jump in. No contribution is too small. And we’re building on a solid foundation of past success.

Hash is all ponies

2008-09-03T22:07:00Z

We’ve been hard at work replacing the C virtual machine in Rubinius with one written in C++. Along the way, we decided to use a simpler data structure internally where we had been using a Hash before. This allowed us to rewrite Hash in pure Ruby. Since our goal is to write as much Ruby in Ruby, I was happy to work on this rewrite.

You can check out the resulting code here and here. It hasn’t been polished much yet, but the idea was to use expressive and natural Ruby. I didn’t take any performance-conscious tacks. Hash should provide a great case study for looking at optimizations in our compiler and VM. For example, Hash#keys can be succinctly written as:

def keys
  inject([]) { |ary, entry| ary << entry.first }
end

Since #inject comes from the Enumerable module, we know it’s using #each internally. And for Hash, I implemented an external iterator of sorts to help hide the implementation details. That iterator is making a method call for each item. So we’ve piled on two block calls and a method call for each item. The point is, we want that expressive Ruby code in our applications and let the implementation optimize it. So far, we really haven’t had any Ruby implementation to give us that.

Another thing to check out is the structure of our kernel directory. Talking to the folks working on MagLev, we’ve restructured our runtime kernel (aka Ruby standard library) to better allow sharing with other implementations. The bootstrap and delta directories are implementation specific, while the common directory is intended to be shared. The bootstrap directory provides just enough functionality to load the common directory. The delta directory provides a location for implementation specialization where specific methods can be replaced with more performant or otherwise specialized versions.

As always, we love to hear from folks about what’s bugging them with Ruby. Drop by #rubinius on freenode.net or check out the Rubinius project on Github. Even though we’re in the middle of this VM rewrite, there’s plenty still to be done on the Ruby standard library.

Update: Evan points out that this is a better implementation of #keys:

def keys
  map { |key, value| key }
end

As del.icio.us as a giant, steaming turd

2008-08-01T18:51:00Z

I often dislike the interfaces that I’m forced to use. Banking sites are about the highest on my list of horrid. The pain these things inflict.

However, today I got a new jolt. Clicked on my handy del.icio.us shortcut in Firefox and was greeted by a bizarre interface. Not to worry, I powered on, since of course, the reason I use del.icio.us in the first place is because it was super quick and easy to add a bookmark. Quick is no longer in the vocabulary for del.icio.us. Instead of simply typing a few characters, hitting <tab> and being done with it, I now have to arrow in this stupid drop-down? Amazed, I started taking a closer look at the unwelcome intruder in my nice browse + bookmark flow.

The lame new auto-complete behavior is a breaker for me. However, it’s hard to say if that’s the worst of the UI redesign. The 3-option choice for the main list display goes from bad to worse to horrid. Is the date, in washed out grey, really the most important piece of info that I need to see in my normal scan from left-to-right? I can barely scan any of the options quickly for the information I need to help me select a link. And where did my nice big entry field go for typing in a tag? Oh, there it is, camouflaged in that bar at the top of the list. Don’t really want me to use that, huh?

I could go on, but what’s the use. The amazing thing to me is that someone, somewhere thought this was a good idea. Have these idiots never heard of Alan Cooper, IxD, the rich body of books describing why you don’t design interfaces like this? Harsh? Damn, right. Horrid.

OSCON 2008

2008-07-21T22:49:00Z

If you’re headed to OSCON 2008, I hope I’ll have a chance to meet you. I’ll be speaking on Thursday afternoon, something about Ruby performance. Come and heckle me if you wish. Here’s the talk details:

Who Wants a Faster Ruby?
07/24/2008
2:35pm – 3:20pm PDT
Room: F151

Also, please do come check out FOSCON. This is the 4th year for FOSCON. w00t.

UPDATE: Thanks to all who attended my talk. I’ve uploaded the slides. If you attended, please take a moment to send feedback.

Implementers Unite!

2008-05-16T19:02:00Z

There’s a lot of things that Rubinius, MatzRuby (including YARV), JRuby, IronRuby, MacRuby, Ruby.NET, MagLev don’t agree on. But that’s ok, because above all, they seem to agree that Ruby is one awesome language. And lately, that apparent agreement has gotten a boost of sorts.

Earlier this week, Rubinius (an Engine Yard project) announced the RubySpec project at rubyspec.org. The effort to write an executable specification using RSpec-style specs started with the Rubinius project in late December 2006. Since then, many people all over the world have contributed to the effort, including core folks from JRuby. Engine Yard has been financially supporting significant development of the RubySpecs since hiring Evan in June 2007 and other full-time developers (myself included) in Jan 2008. All this effort has been to ensure that the Ruby programming language continues to evolve and receive the recognition it deserves.

Another recent development has been a regular meeting of folks working on various Ruby implementations. These Ruby design meetings are bringing together folks to discuss tough issues with Matz and everyone else.

Well, after last night’s meeting, Tanaka Akira (sorry, I don’t have a link to his website; if you do, please let me know) checked in some changes to the ruby-core Makefile to fetch and run the RubySpecs. This is a very proud moment for me.

If you love Ruby, it doesn’t matter what color shirt you wear, what language you play with, or what country you live in. You can play a valuable role in helping make Ruby a wonderful language for everyone. Please help us with the RubySpecs.

Update: I changed the link to the changeset for the Makefile. Thanks Michael.