[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## Re: benchmark 1.5

**From**: |
Francesco Potorti` |

**Subject**: |
Re: benchmark 1.5 |

**Date**: |
Thu, 11 Apr 96 14:40 MET |

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.