Turtles need Speed

In a comment on my last post, Steven Swerling (a fellow Smalltalker) questions my repeated nagging about the speed of the current Ruby implementations (both C and Java):

Zed Shaw said that “scalability” is most constructively defined not by raw speed but by how predictably overall throughput can be increased by plugging in additional hardware. (see here. From that perspective, JRuby doesn’t have to be fast to meet its goals, it just needs to be fast enough.

I completely agree. The question is, fast enough for what. To me, one thing that’s wonderful about both Smalltalk and Java is that all of their libraries, including basic data structures like lists and hashtables, are implemented in, respectively, Smalltalk and Java. That’s possible because the underlying execution machinery is fast enough that, although it would certainly still be faster to have highly tuned Collection implementations in C, the pure Smalltalk and pure Java libraries are “fast enough”. That’s a crucial threshold, and it’s one that many languages, including Ruby, have not passed. I would argue, in fact, that’s it’s one of the key things people (perhaps subconsciously) use to distinguish between “real” languages and “scripting” languages. I generally hate that distinction, but in this case I think it’s warranted. You extend Java by writing Java, you extend C++ by writing C++, you extend C# by writing C#, but you extend TCL and Perl and Ruby, as often as not, by writing C. As I replied to Steve:

As long as people feel a need to implement classes like Array or Hash in C (or Java) rather than in Ruby, then the quantitative performance difference is having a qualitative effect, and in my opinion a serious one. Once that changes, I’ll be happy to back off.

If you want to know some of the ill-effects of implementing basic classes in C rather than in Ruby, (apart from how painful and error-prone it is to write the C in the first place) here’s a simple contrived illustration. Try creating a subclass of Array that, when you ask for an element, returns twice the value of what you stored there:

class MyArray < Array def [](i) super * 2 end end x = MyArray.new x << 10 puts x[0] x.each{|el| puts el} 

The result of the first print statement (using either ruby 1.8.2 or JRuby 0.9.8) is “20″, as it should be. The result of the second print statement is “10″. Why? Because the C/Java implementations of Array#each totally ignore our Ruby-level definition of [], and simply access the internal elements directly. This kind of inconsistency is pervasive and puzzling. But even if the C implementation behaved identically to a hypothetical Ruby implementation, it would still bother me, because having your standard library implemented in Ruby makes it so much easier to understand, explore, learn from, debug, and modify. It would also, incidentally, make projects like JRuby so much easier, because you would only have to implement the basic language rather than redo all of the work that had been done at the C level. Dan Ingalls did a lovely binary compatible re-implementation of the Squeak VM in Java as an exercise to learn the language, in a tiny fraction of the time that JRuby has taken, because everything important, down to the parser, compiler, process scheduler, windowing system, and IDE, were implemented in Smalltalk anyway and so could be reused. That’s the kind of trick I’d like to see Ruby able to pull off.

Comments

[rohan nicholls]

Thanks for this, you managed to put into words something that has been bugging me for a couple of years now, but I could not put my finger on it.

[Daniel Lucraft]

You should check out the Rubinius project (http://rubini.us) if you haven't already.