Hugh Sasse wrote:

> <OT>I've tried, but FORTH still hasn't clicked with me yet...</OT>

<not-quite-OT>
Check out the gForth and vmgen manuals at

http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/index.html
http://www.ugcs.caltech.edu/manuals/devtool/vmgen-0.6.2/index.html

There was a project to build a Ruby virtual machine using vmgen.
</not-quite-OT>

> 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 ...

:)

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
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.

>> 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
> 
> 

Yeah ...