On Mon, May 17, 2010 at 2:49 PM, Alois Schlögl <[email protected]> wrote: > Jaroslav Hajek wrote: >> >> 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. >> >> > > here are the benchmark results (using bench_biosig) on the same platform (a > quadcore amd64 processor). > > Version: 3.3.51+ > cputime toc[s] task > ================================ > 1.050 1.051 sload l1.gdf > 0.920 0.922 bandpower > 9.470 9.466 wackermann > 1.760 1.761 barlow > 1.800 1.799 hjorth > 0.680 0.681 TDP > 109.670 109.750 aar #1 > 109.180 109.218 aar #2 > 112.570 112.574 aar #3 > 43.160 49.353 findclassifier bp LD3 > 43.590 43.590 findclassifier barlow LD3 > 43.530 43.540 findclassifier hjorth LD3 > 43.350 43.350 findclassifier aar LD3 > 43.100 43.094 findclassifier Wackermann LD3 > 43.050 43.052 findclassifier TDP LD3 > ----------------------------------- > 606.880 613.199 total > > Version: 7.6.0.324 (R2008a) > cputime toc[s] task > ================================ > 0.770 1.272 sload l1.gdf > 1.120 1.077 bandpower > 13.190 13.156 wackermann > 1.540 1.637 barlow > 1.560 1.688 hjorth > 1.410 1.445 TDP > 42.210 42.419 aar #1 > 38.310 38.315 aar #2 > 38.650 38.577 aar #3 > 7.820 6.071 findclassifier bp LD3 > 9.000 5.990 findclassifier barlow LD3 > 8.890 5.892 findclassifier hjorth LD3 > 8.790 5.849 findclassifier aar LD3 > 8.990 5.909 findclassifier Wackermann LD3 > 8.620 5.808 findclassifier TDP LD3 > ----------------------------------- > 190.870 175.104 total > > aar is basically a Kalman filter algorithm which is a recursive algorithm; > findclassifier is contains a classifier in combination with a leave-k-out > cross-validation procedure. Both problems can not be vectorized with the > standard language elements of the M-language. >
Who says it can't be vectorized more? Are you 100% sure there are no missed vectorization opportunities? > An alternative solution would be the implementation in an other language > (like C/C++) but that's beyond the point here. The user sees that Octave is > performing more than 3 times slower. From a user point of view, this is > legitimate reason to use M. > Haha, legitimate, it depends, doesn't it? Sure, if you have a license, that alone is a legitimate reason to use it. But what if I step forward and offer you to optimize the code so that it will become, say, < 30% slower than Matlab on the current code, and do it for 10% of your licensing costs (supposing you need to run this on multiple computers, it could make a nice sum :) > Trying to shift all the blame to someone else (bad code, code optimized only > for matlab, etc.) is missing the point. I think *you* are missing the point with "blame". I, for instance, did not "blame" anyone for anything. I merely pointed out that perhaps the code may be made faster in Octave (by changing the code, not Octave). Lots of codes can. "Matlab is faster on my code" does not necessarily mean "Matlab is faster in general". I can give you a code where Matlab is 3x slower (and it even does something useful). Yes, if you pick a random code from the world, Matlab will crunch it faster on average. At least I think so. The trick is that I can write above average m-code, and I think it's not even hard to learn. > Lets look at another area: most OpenOffice users are using it on top of > windows. And it does not hurt linux that they do so. It's similar here, > toolboxes can be used with both. Why not using octave toolboxes on top of M > ? It does no harm to octave if anyone does so. > Right. But I don't recall anyone criticizing you or anyone else for using the packages with Matlab. So maybe I'm missing the point once again. -- 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
