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

**From**: |
John L Daschbach |

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

**Date**: |
Wed, 10 Apr 1996 09:49:18 -0700 |

First:
benchmark.m v1.5 fails for me.
[d3h486]:(1)>benchmark15
Octave benchmark version bm 1.5
Speed of octave 1.1.1 on rs6000-ibm-aix3.2.5 relative to Sun Sparc 10/40
Matrix inversion (LAPACK) 4.29 +/- 0.4% (56 runs)
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'
-- Performance index (bm 1.5): 1.3
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 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? We are going to be buying a couple more
general purpose boxes and if the RS6000 is truly slow for general
purpose integer computing I'd like to know.
-John

**benchmark 1.5**, *Francesco Potorti`*, `1996/04/10`
**Re: benchmark 1.5**,
*John L Daschbach* **<=**