On Sun, May 16, 2010 at 8:08 PM, Alois Schlögl <[email protected]> wrote: > Jaroslav Hajek wrote: >> >> On Fri, May 14, 2010 at 9:15 AM, Carlo de Falco <[email protected]> >> wrote: >>> >>> On 13 May 2010, at 23:00, Lukas Reichlin wrote: >>> >>>>> Certainly. But at this event, only Windows machines were available >>>>> and >>>>> Matlab was already pre-installed. I had little options >>>>> about the setup. (and i do not want to say it loud, but M is still >>>>> faster, [1]. Admittingly, Octave has improved since 2006, and I see >>>>> only >>>>> difference by a factor of 2-3 instead of 4-5). >>>>> >>>>> [1] http://arxiv.org/abs/cs/0603001v1 >>> >>> Do you still have the code to run those benchmarks at hand? >>> It would be very interesting to compare how the speed of Octave >>> changed between version 2.9.4 and 3.3, >>> for a fair comparison you would need to run the tests on the same >>> hardware though.. >>> c. >>> >> >> >> Checking the BioSig code, I even found snippets such as: >> >> % Instantaneous heart period hp >> for k=2:length(t) >> hp(k)=(t(k)-t(k-1)); >> end >> hp(1)=NaN; >> hp_mean=mean(hp) >> >> and hp is not even preallocated. Of course, code like this has no >> chance to be efficient in Octave. >> Another example snippet of extremely poorly vectorized code is >> >> j=1; >> n_all=ones(1,length(ke_all)); %number of consecutive ectopic beats >> while j<length(ke_all) >> while ((j<=length(ke_all)-1)&((ke_all(j+1)-ke_all(j))==1)) >> ke_all(j)=[]; %deletion of consecutive indices >> n_all(j)=n_all(j)+1; >> end; >> j=j+1; >> end; >> n_all(length(ke_all)+1:end)=[]; >> >> not only there is a double loop, there is also a vector operation >> (element deletion) in the inner loop. >> I would expect, however, that this is sluggish in Matlab as well, no >> JIT can probably handle this. >> > > > What is your point here ? Some people are not as good in coding as > others, the function this student wrote is still useful. What does it > say about the performance of Octave vs. M ? Zero, Nil, Nothing. >
That was exactly the point - that code like this says nothing about the relative performance, because it is a slow code on both systems. > BTW, this function is not part of the biosig benchmark. > OK, it was a source picked randomly. If the benchmark contains code like this, the point still holds. There is no question that Octave is slower with loops than Matlab. But even if Octave performs much slower on a given code, often the code can be optimized so that Octave's speed becomes comparable to Matlab's (sometimes it even outperforms it). It just requires more skill than with Matlab, so especially people used to Matlab as their primary platform often miss good optimization opportunities. -- RNDr. Jaroslav Hajek, PhD computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
