From octave-maintainers-request at bevo dot che dot wisc dot edu Mon Jan 26 15:28:43 2004
Subject: Re: benchmarks
From: "Dmitri A. Sergatskov" <dmitri at unm dot edu>
To: David Bateman <David dot Bateman at motorola dot com>
Cc: Paul Kienzle <pkienzle at users dot sourceforge dot net>,    octave-maintainers@bevo.che.wisc.edu,    "John W. Eaton" <jwe@bevo.che.wisc.edu>
Date: Mon, 26 Jan 2004 14:27:38 -0700

David Bateman wrote:

Matlab
> Cholesky decomposition of a 900x900 matrix__________ (sec): 0.4
> Inverse of a 400x400 random matrix__________________ (sec): 0.23

Octave
> Cholesky decomposition of a 900x900 matrix__________ (sec): 0.45
> Inverse of a 400x400 random matrix__________________ (sec): 0.27

Which Atlas do you use? I usually get better times on Octave for
those benchmarks (using 3.5.3 or 3.6.0 ATLAS on athlon-xp).

Also with regard to FFT. There is some stranginess with fft
on octave:

octave:15> s=randn(3000);
octave:16> z=randn(3000)+i*randn(3000);
octave:17> tic ; ifft(fft(s)); toc
ans = 3.5515
octave:18> tic ; ifft(fft(s)); toc
ans = 3.4647
octave:19> tic ; ifft(fft(z)); toc
ans = 2.6399
octave:20> tic ; ifft(fft(z)); toc
ans = 2.6424
octave:21>

(So it works _faster_ for complex numbers)

On Matlab for comparison:


 >> s=randn(3000);
 >> z=randn(3000)+i*randn(3000);
 >> tic ; ifft(fft(s)); toc

elapsed_time =

     2.8108

 >> tic ; ifft(fft(z)); toc

elapsed_time =

     3.1225

So Octave faster than Matlab for complex numbers, but slower
than Matlab for real numbers.
It may be that Matlab is using rfftw for real input, and
octave always assumes complex input.
I have a vague recollection that this issue was discussed on
octave list eons ago, but could not find this thread in
archive...

Sincerely,

Dmitri.