[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: benchmarks
From: |
Dmitri A. Sergatskov |
Subject: |
Re: benchmarks |
Date: |
Mon, 26 Jan 2004 14:27:38 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 |
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.
- Re: randn benchmarks, (continued)
- Re: randn benchmarks, Dmitri A. Sergatskov, 2004/01/23
- Re: randn benchmarks, Dirk Eddelbuettel, 2004/01/24
- Re: randn benchmarks, Paul Kienzle, 2004/01/24
- Re: randn benchmarks, Paul Kienzle, 2004/01/24
- Re: randn benchmarks, Dmitri A. Sergatskov, 2004/01/24
- Re: randn benchmarks, David Bateman, 2004/01/25
eigenvalues 3 times speedup patch [Was: benchmarks], David Bateman, 2004/01/23
Re: benchmarks, David Bateman, 2004/01/26
- Re: benchmarks,
Dmitri A. Sergatskov <=