From octave-maintainers-request at bevo dot che dot wisc dot edu Tue Jan 27 03:16:34 2004 Subject: Re: benchmarks From: David Bateman To: "Dmitri A. Sergatskov" Cc: octave-maintainers at bevo dot che dot wisc dot edu Date: Tue, 27 Jan 2004 10:12:18 +0100 According to Dmitri A. Sergatskov (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 David dot Bateman at motorola dot com 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