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