Re: benchmark 1.5

[Francesco Potorti`]

You wrote:   
   
   First: benchmark.m v1.5 fails for me.  
   [...]
   Schur decomposition (LAPACK)     error: mean:  x must not be empty
   error: evaluating index expression near line 25, column 5
   error: evaluating if command near line 24, column 3
   error: called from `mean' in file 
`/msrc/home/d3h486/Lib/Octave/Contrib/statistics/mean.m'

Looks like you have a nonstandard mean.m installed that is used
instead of the standard one.  If you use the standard one it should
work.  However, I am curious to know why it does not work with the
mean.m you're using.  Could you try to debug it?
   
   Second:
        Your weightings have the Alpha on top, yet for the tests which
   really test what matlab/octave was designed for (matrix math) the
   RS6000 is clearly faster.  Averaging the matrix math and fft tests we
   have RS6000 = 4.24 and Alpha = 3.54.  If we wanted to go to the
   trouble of using the IBM optimized libraries for Octave we should see
   probably a doubling of the fft2 speed.

The most notable error of the latest ratings I have posted is for the
Sun Ultra, which is as fast or faster than Aplha.  I will post a new
table in a few days.

        The other side of this is why is the RS600 so slow for the
   native Octave code (for and lsode).  the 'for' test is pure octave and
   the 'lsode' involves using a call from lsode to octave code to
   evaluate the derivatives every time.  It seems clear this is the
   bottleneck on the RS6000.  Is this a function of the design of the
   RS6000, octave, or gcc?  

The only thing I know is that the new version of octave, currently in
beta test, seems to be about twice as fast for octave code.  However,
the difference for RS6000 could be caused by any of the three factors
you mention.  I don't know which are involved.