Re: execution speed in *oct files

[A+A Adler]

On Mon, 7 Jun 1999, John W. Eaton wrote:
> | On  3-Jun-1999, A+A Adler <address@hidden> wrote:
> | | I just submitted an oct file for 2-D convolutions
> | | to octave-sources.
> | | 
> | | While I was writing it, I noticed that the standard octave
> | | syntax seems to be very inefficient.
> 
> I've done a few quick tests using the following code.  It simply adds
> two real matrices and returns the result.  The first two arguments are
> the matrices to add.  The third argument controls the code block used
> to perform the additions, and the last argument says how many times to
> perform the addition (to ensure that it takes long enough to get
> meaningful results).
> 
> [ foo.cc snipped ]
>
>   octave:1> foo
>   usage: foo (a, b [, case [, max_try]])
>   octave:1> a = rand (1000); b = rand(1000);
>   octave:2> for i = -1:4 t = cputime(); foo (a, b, i, 10); cputime() - t 
> endfor
>   ans = 0
>   ans = 2.3700   # operator +
>   ans = 3.0800   # non-const operator () on RHS and LHS
>   ans = 2.4500   # const operator () on RHS, non-const on LHS
>   ans = 2.3000   # const operator () on RHS, pointer on LHS
>   ans = 2.2600   # pointers all around
> 

I get roughly the following results:

On a Pentium II 350 MHz Linux 2.2

ans = 0
ans = 1.2700
ans = 1.9700
ans = 1.5100
ans = 1.3000
ans = 1.1700

> So, if you use const where appropriate, then I think the performance
> should be about the same whether you use the indexing operators or
> pointers.  Even without const (which causes the operators to have to
> do a bit more work to decide whether the data needs to be copied
> prior to returning a reference), I don't think you should see a speed
> up of 3 times just by switching to using pointers.

Trying my conv2.cc code with this suggestion

Pointers             ans =  4.8300
Const Matrices       ans =  8.6300
non-const Matrices   ans = 14.400

So:  1) Using const matrices is a good idea!
     2) I can't figure out why it makes a 3x difference 
          in the case of my conv2 code and only 1.6x in
          the case of your addition code/

> Perhaps the problem is some missed optimization.  What compiler and
> options are you using?

gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

>  Unless we resort to
> writing low-level code that is very difficult to maintain (not my
> first choice), we are going to have to have good optimizing compilers,
> or at least use the optimzations that are available to us.

The whole speed issue for octave is not at all clear cut.
My experience is that Matlab is often, but not always, faster.
(for Matlab 5. Octave is more or less on par for Matlab 4).

However, Matlab is not super optimized either. My conv2 code
runs quite a bit faster than the Matlab version, especially
for separable convolutions.

Another area is the BLAS. Octave seems to use the generic
fortran BLAS rather than one optimized for any architecture.
(I remember taking a look at BLAS functionality when I was
putting together the sparse functions for octave ) There seems
to be no open source optimized BLAS available, and this
difference must be responsible for much of the Matlab/octave
speed difference.

This leads me to 2 opinions:

1) octave speed is not a big issue. As long as I know how to 
   write efficient *oct files, I'm fine.

2) *oct file documentation is lacking. I probably know more
   than most about how to program them, but there are obviously
   many tricks (like const Matrices) that I'm unaware of.

   I would volunteer to write *oct documentation, but I'm 
   already behind in the things I've promised to write
   for octave.

______________________________________________________________
Andy Adler,                               address@hidden



---------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.  To ensure
that development continues, see www.che.wisc.edu/octave/giftform.html
Instructions for unsubscribing: www.che.wisc.edu/octave/archive.html
---------------------------------------------------------------------