From: Hugh Sasse <hgs@...>
Date: 2006-09-16T02:15:08+09:00
Subject: Re: Benchmark for Ruby

On Sat, 16 Sep 2006, M. Edward (Ed) Borasky wrote:

> Hugh Sasse wrote:
> 
> > <OT>I've tried, but FORTH still hasn't clicked with me yet...</OT>
> 
> <not-quite-OT>
        [...]
> </not-quite-OT>

Thanks, I'll reply off list about that.  
> 
> > There exists at least this effort to use Genetic Algorithms for 
> > tuning compiler options.  I've not explored it yet.
> > 
> > http://www.coyotegulch.com/products/acovea/index.html
> > 
> > One may need a cluster of machines (of many platforms?) to do this
> > usefully, but still.  Maybe Rinda can help us all contribute...
> 
> I think I installed acovea once -- it's part of Gentoo -- but I don't
> remember doing anything with it. But the concept is certainly
> intriguing, and might be more so to the folks on this list who are
> always talking about how machine cycles are cheaper than programmer
> cycles. Of course, if the programmer has to spend his or her cycles
> waiting for a genetic algorithm to converge ...
> 
> :)

GA's aren't that quick, and would not be for a ruby build.  But it's
something to explore, just because it might teach us something.
> 
> I've had bad experiences in the past with this sort of optimization.
> "Real" compiler optimization is a hard problem in the complexity sense,
> plus there's all the time you have to spend correctness-testing the

Well, at least we have a set of tests for ruby, and we can use that
as part of the fitness function.

> optimized versions. My experience has been it's far better to pluck the
> low-hanging fruit, which is what gcc does by itself, and which is what
> the designers of virtual machines do.

People have stated that implementation method despatch in ruby are naive.

http://smallthought.com/avi/?p=16

that creating Procs, and continuations are slow:

http://lambda-the-ultimate.org/node/1470

and other people have mentioned the garbage collection system.

I'm certainly not in a position to suggest what might be done about
these things, or to denigrate the implementations as they stand, but
these are about the only specific things I can find people pointing
to, (other than the general remarks about ruby being slow, which add
more heat than light).  So I think we have some juicy pieces of fruit
to bite into here, but I don't think they are low hanging, not for
me anyway. :-)

        Hugh