Re: indexing expression performance

[Jaroslav Hajek]

On Fri, Jan 16, 2009 at 9:30 AM, Thomas Weber
<address@hidden> wrote:
> Am Donnerstag, den 15.01.2009, 13:57 +0100 schrieb Jaroslav Hajek:
>> On Thu, Jan 15, 2009 at 1:48 PM, Francesco Potortì <address@hidden> wrote:
>> > I had written:
>> >>>Also, Francesco, I forgot to do the obvious thing and test your examples
>> >>>with 3.1.51. At least on my machine, it looks like the performance has 
>> >>>been
>> >>>reversed by the latest dense indexing improvements.
>> >>>
>> >>>octave:1> kk=rand(156,222,1,44,8);
>> >>>octave:2> t=cputime; for ii=1:44, for jj=1:8, mm=kk(:,:,:,ii,jj); endfor,
>> >>>endfor, cputime-t
>> >>>ans =  0.072004
>> >>>octave:3> cp=[1,cumprod(size(kk)(1:end-1))]; len=156*222; t=cputime; for
>> >>>ii=1:44, for jj=1:8,base=sum(([1,1,1,ii,jj]-1).*cp); 
>> >>>mm=kk(base+1:base+len);
>> >>>endfor, endfor, cputime-t
>> >>>ans =  0.12401
>> >>
>> >>Wonderful!  This will make my code more readable as soon as I upgrade :)
>> >
>> > Hm.  I installed Octave 3.1.51 from Debian's "experimental" (I never got
>> > round to finding the time to build Octave myself).  I use an amd64 box.
>> > Unfortunately, I see no big difference with 3.0.1 :(
>> >
>> > The timings of the first test versus the second on my box are:
>> > - 5.1s versus 0.30s with 3.0.1
>> > - 5.2s versus 0.27s with 3.1.51
>> >
>> > So apparently I am not benefitting from the 3.1.51 dense indexing 
>> > improvements.
>> >
>>
>> The dense indexing improvements started with
>> http://hg.savannah.gnu.org/hgweb/octave/rev/7cbe01c21986
>> dated 20th October and lots of bugfixes afterwards. I don't think this
>> was in the 3.1.51 snapshot which I think was done in late July. There
>> was no 3.1.52 so far. So, if you want these, development sources are
>> your only resort.
>
> I'd vote for a new snapshot. Or, if you can give me a mercurial id where
> sources are in a reasonable[1] shape, we can use that for a new snapshot
> package in Debian.
>
> [1]  Reasonable by whatever metric you choose.
>
>        Thomas
>

A very loose metric is as follows:
Checkout a current tip, and wait a whole day for possible patches
coined like "omission from last patch" etc.
If no such patch appears, you have a reasonable shape.

But, given that there were rumors about making 3.1.52 testing
snapshot, perhaps you'll want to wait for that?

My opinion for the best way to proceed is to fork 3-2-x branch at a
suitable time (maybe now) and then make testing and later stable
releases from it, but I think John has a different idea.

Btw., I see Debian has a pretty complete octave3.0 package.
How hard would be packaging the qrupdate library for Debian?
(https://sourceforge.net/projects/qrupdate).
This will be used in 3.2 to provide qrupdate, qrinsert, cholupdate
etc. and I'm not yet sure whether to keep
a snapshot in libcruft or make it a weak dependency (Octave will run
fine without the functions, but some
functions will lose performance).
I am fairly ignorant about packaging in GNU/Linux distros :(.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz