From: Hugh Sasse <hgs@...>
Date: 2006-09-15T18:42:11+09:00
Subject: Re: Benchmark for Ruby

On Fri, 15 Sep 2006, M. Edward (Ed) Borasky wrote:

> Analysis Phase (Trick 1):
> 
> 1. Collect the whole matrix of benchmarks. The rows will be benchmark
> names and the columns will be languages, and the cells in the matrix
> will be benchmark run times. Pick a language to be the "standard". C is
> probably the obvious choice, since it's likely to be the most "practical
> low-level language" (meaning not as many folks know Forth.) :)

<OT>I've tried, but FORTH still hasn't clicked with me yet...</OT>
        [...] 
> Some other tricks:
> 
> Once you know where Ruby is spending its time, play with compiler flags.
> gcc has oodles of possible optimizations, and gcc itself was tuned by
> processes like this. It's worth spending a lot of time compiling the
> Ruby interpreter, since it's going to be run often.

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...
> 
> Those are simple "low-hanging fruit" tricks ... stuff you can do without
> actually knowing what's going on inside the Ruby interpreter. It will be
> painfully obvious from the profiles, I think, where the opportunities are.
> 
> 
        Hugh