From: "David G. Andersen" <dga@...>
Date: 2004-11-07T08:10:38+09:00
Subject: Re: Ruby is a slow performer

On Sun, Nov 07, 2004 at 07:48:38AM +0900, Christian Szegedy scribed:
> David G. Andersen wrote:
> >
> >If we had a superfast matrix class, it would give (a) along
> >with decreasing the runtime by a factor of ten or so.  Sounds
> >reasonable.  The same test in matlab would be about 1/4 the lines of
> >code and 20x faster if implemented the way it should be.
> 
> Great! Then put all C-solutions from the shootout into
> an extension and call them from Ruby. This way, Ruby
> would have the second place in runtime after C and
> the 1st in LOC count.

  This doesn't follow.  Ruby _already_ has a matrix convenience
class - my point is simply that by adding 61 additional lines of
code (73 lines of C - the 12 lines of ruby it replaces), we turn
the internal matrix class from something that's twice as slow
as what you would get if you implemented the whole thing in 
optimized ruby to something that's 5x faster.  Being able to use
an already well-implemented matrix class is a very nice bonus;
who wants to roll their own just to speed things up a bit?

  Matrix manipulation is _not_ a "just for the benchmarks"
optimization.  There are a lot of cases in which having a pleasantly
fast, easy to use matrix multiply is beneficial, but you don't want
to quite go all the way and force an external dependency on NArray.

By way of explanation:  I use Ruby for a lot of data analysis;  most
of what I do is string manipulation and counting things in hash
tables, but every now and then I have to throw in a little math.
It's not speed-utterly-critical, but it's speed-pleasant.  My updated
matrix multiply code fills that space...)

The main point I was exploring in this thread was the ease
of optimizing a few bits of performance-intensive ruby code with
a very small, managable bit of C.  I find it much more pleasant
to have the bulk of the code I implement be in ruby, where it
looks like:

  class Window_Repository
    attr_reader :winsize

    def initialize(winsize, gc_thresh = 100)
      @winsize, @gc_thresh = winsize, gc_thresh
      ...
    end
  end

instead of

  myClass = rb_define_class("Window_Repository", rb_cObject);
  ...
  static VALUE
  window_repository_init(...) {
    ...
  }

but still be able to make a couple of small tweaks to get
an order of magnitude performance improvement.

> >The shootout _is_ useful for understanding some general
> >aspects of the languages, and for looking for things that
> >you might want to really work on speeding up (say, for
> >instance, the fact that Ruby's hash accesses seem to be
> >about 1/2 the speed of Perl's. ;-)
> 
> It is not even clear that this is really the hash-access.
> It could be the GC, the loop or who knows what...

  Disabling the GC doesn't help most of the hash-bound benchmarks
much if they're written properly.  The basic loop iteration is
quite fast if you remove the hash access.  You can draw your own
conclusions from this.

  I admit that I may be an atypical ruby user. :)  But if we 
can manage it, things that speed up ruby without harming
maintainability of flexibility are good for everyone.  This
is why it's occasionally useful to look at benchmarks, flawed
as they may be.  The shootout certainly has its flaws, but it
can also point out areas where improvement would help.

  -Dave

-- 
work: dga@lcs.mit.edu                          me:  dga@pobox.com
      MIT Laboratory for Computer Science           http://www.angio.net/