"Bill Kelly" wrote:
> 
> From: "markus liedl" <markus.lado / gmx.de>
> > 
> > ahmm: you shouldn't think about optimisations, just code in Ruby.
> 
> Sounds like a fun task, but, I'm trying to guess as to what practical
> use this implementation would be expected to be put?

It will be faster than an optimized one!

>
> I try to shy away from premature optimization myself, but . . . =)
>

Code tends to get more complex if one optimizes.
Speaking of future: The RubyVM will have different performance
characteristics than matz' Ruby.

If somebody has already 'tried' to optimize a bit, it hides _what_ should be
done. But everybody who tries to optimize afterwards will have a harder
live.

You can only optimize for _one_ platform, and RubyInRuby makes limitied
sense on top of matz' Ruby.

Don't optimize: Keep the devils out of your head!


An example:

A 'case' statement with lot's of 'when' and every one with a little number.
In C the compiler would generate a jump table.
If you simulate this behaviour with a Hash and lot's of proc's or method's
it will probably be faster in matz' Ruby interpreter.
But an optimizer in a VM can't apply a simple optimization (consisting of a
check and a transformation) to approach the optimal performance (probably a
jump table)
The basic elements the VM-optimizer is playing with are smaller than the
elements you are playing with in Ruby, so the VM-optimizer can do the job
better.

Keep 'em out of your head!
 

> I'd have imagined such a thing would need to be written in "sRuby"
> (cf. http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/rubyvm.pdf )
> to have a chance of being able to be useful for performance reasons.
> Is there some anticipated use for a regexp-engine-in-Ruby where
> performance is not a primary concern? 

There is no good reason to prefer sRuby, since it is as far from realisation
than other approaches.

Performance is a primary concern, but NOT at this level.



When Jan Arne Petersen gets the Bytecode compiler for JRuby working it is
well possible that it is the same there. (that 'unoptimized' code runs faster
than optimized)

markus

-- 
-------------------------------------------------