Re: [OctDev] Help making padarray.m quicker

[Josep i T. <jm...@pu...>]

On dc, 2004-08-11 at 13:37, Paul Kienzle wrote:
> On Aug 11, 2004, at 4:43 AM, Per Persson wrote:
>=20
> >
> > On Aug 11, 2004, at 04:12, Paul Kienzle wrote:
> >
> >>
> >> On Aug 10, 2004, at 6:18 PM, Josep Mon=E9s i Teixidor wrote:
> >>
> >>> I've left padding with scalar values as it was in the second version
> >>> because, although in my intel box that was slower, as Paul sent
> >>> yesterday, that probably makes a real difference on MacOs X.
> >>
> >> Note the difference in version number: 2.1.55 for OS X,
> >> 2.1.57 for linux!  Octave may have changed to make the
> >> two more similar.  Does somebody have both versions
> >> available on the same system that they can compare?
> >
> > FWIW, on a 1.25MHz G4 w 512MB RAM iMac with octave 2.1.57 I get (+/- =20
> > 20% accuracy)
> >
> > octave:1> n=3D800; A=3Dones(n,n);
> > octave:2> tic; B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=3DA; toc
> > ans =3D 0.16152
> > octave:3> tic; =20
> > B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,=
50=20
> > )); toc
> > ans =3D 0.19956
> >
> > I don't have any pre-2.1.57 installs, but I'm pretty sure there =20
> > weren't any changes between 2.1.55 and 2.1.57 that could justify the =20
> > 10x diff in speed. Did you run the test on a memory starved (which for =
=20
> > OS X means <=3D256 MB) system?
>=20
> octave:12> n=3D200; A=3Dones(n,n);
> octave:13> tic; B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=3DA; toc
> ans =3D 0.045741
> octave:14> tic; =20
> B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50=
)=20
> ); toc
> ans =3D 0.43754
>=20
> octave:31> n=3D20; A=3Dones(n,n);
> octave:32> tic; for i=3D1:10, B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=
=3DA; =20
> end; toc
> ans =3D 0.047229
> octave:33> tic; for i=3D1:10, =20
> B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50=
)=20
> ); end; toc
> ans =3D 0.45311
>=20
> So I would say the 10x is real.  It's nice to hear that it its gone =20
> now.  I just hope that's because cat got faster rather than assignment =20
> getting slower ;-)
>=20
> Josep, don't worry about choosing an algorithm suitable for older =20
> versions of octave.
>=20
> - Paul



I this case I'll leave it as it is, which is the faster version. The
only problem now is cat not working for ND arrays in some cases.... but
this will work soon anyway... It's a pity that this last approach isn't
faster... it was sooo simple and beautiful! :)

In the future I may try to speed scripts that need it by coding them in
C++, to acquire experience with liboctave.=20

BTW, I've realised that I made a mistake with emacs, and some files have
DOS-style line endings (those mad keystrokes!), but if I correct it
locally, diff doesn't detect any difference. I don't know how to change
that remotely... affected files are padarray.m, roicolor.m and uintlut.m

This is not important, but I discovered when using shared feature of
tests. It doesn't work if line endings are DOS style. Perhaps there's a
little bug there waiting for Windows users.

Regards,

--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4