Quoting Robert Dober <robert.dober@gmail.com>:
>
> For those who are interested, I already measured the effect of GCC
> optimization flags on Ruby speed using the MatrixBenchmark, which was the
> only one I had at the time. Results here:
> http://www.jhaampe.org/software/ruby-gcc
> --
> Sylvain Joyeux
>
> I find all that very interesting, completely OT, but interesting.
Well I do not believe in the right of OP to have the thread following the
topic in a ML, the irony is that I just got off another thread because some
other people do not share that idea and I thaught it might be a good idea to
respect their believes.However what I really wanted to say:
Very interesting but is there nothing which can be said about Ruby,
everybody is talking about implementations and tweaks.
I thaught it might be a good idea to talk about crimes and blunders,
performance wise.
I am not sure any more that this might be possible, maybe we wait for YARV
and Ruby2 to have a sound base for discussion.Thanks for *all* contributions (included the future ones
1. In his specific case, the choice of a built-in matrix multiply and inverse
was deliberate for two reasons. First, the natural expression of the problems
I'm ultimately trying to solve in Ruby is in terms of matrices. I don't
consider that a performance blunder. Second, I wanted something to benchmark
that exercised a lot of the Ruby internals.
2. The overall objective of the project from which this benchmark came is to
build a performance modeling tool set in *pure* Ruby. Given that, one can only
improve performance by tweaking the way the Ruby interpreter is compiled. I
don't know when YARV and Ruby 2 will be as stable as Ruby 1.8.5 is now. YARV is
indeed four times as fast on this benchmark, and I like that. I don't see why
the same speed improvements can't be made in the base Ruby 1.8 interpreter.
3. I *am* exploring other options, such as interfacing with existing C/C++ math
libraries, rewriting Matrix, Rational, Complex and Mathn in C, etc. But I
personally don't see why a built-in function to process vectors and matrices
can't run at the same speed as C code. Of course, to do so would require
rational and complex numbers, matrices and vectors to be built-in data types
just like Fixnums, Floats, Bignums and Strings, and that means convincing the
Ruby community that it's a good idea and waiting for the version of Ruby where
such semantic changes are part of the language definition.
In short, there are many ways to do it. Implementing efficient matrix and vector
operations in the language is what I would consider the "best way", assuming we
could get the Ruby community to agree on whether or not the elements of a
vector or matrix can be changed once the object has been created. 
My opinion
is unaltered on that subject -- it should be possible, with an optional warning.
···
On 9/15/06, Sylvain Joyeux <sylvain.joyeux@polytechnique.org> wrote: