Re: Benchmark for Ruby
- From: Hugh Sasse <hgs@xxxxxxxxx>
- Date: Fri, 15 Sep 2006 18:42:11 +0900
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...
Hugh
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.
.
- Follow-Ups:
- Re: Benchmark for Ruby
- From: M. Edward (Ed) Borasky
- Re: Benchmark for Ruby
- References:
- Re: Benchmark for Ruby
- From: M. Edward (Ed) Borasky
- Re: Benchmark for Ruby
- Prev by Date: Re: arbitrary indexes
- Next by Date: Re: Keep only one part of a string
- Previous by thread: Re: Benchmark for Ruby
- Next by thread: Re: Benchmark for Ruby
- Index(es):
Relevant Pages
|
