Re: benchmarks

[David Bateman]

According to Dmitri A. Sergatskov <address@hidden> (on 01/26/04):
> 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).

I'm using 3.6.0 on a PIII M 1.133GHz. The fact is these results are
very close. I was more concerned that the only tests we are now
loosing out on by a large factor are the programming one, especially
"for loops". So the point was we need to put some effort into fixing
up the parser (JIT, speculative compilation, bytecode, etc). This is
a big task, and has been mentioned a number of times in the past.

On this note, has anyone tried the code MAJIC for Matlab 6.1? It seems
very much like what they eventually included in Matlab 6.5 for JIT.
It might be possible to jump start the writing of this code by reusing
this, although the license at the moment is for research, academic and
internal commerical use. 

> 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...

Ok, this one shoudl be fixed up as well then.....

Cheers
David

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary