Re: using functions found in oct files from c++

[Paul Kienzle]

On Sep 25, 2006, at 12:57 PM, John W. Eaton wrote:
> If you think that it is too slow to use feval, then please demonstrate
> that it really is too expensive (does anyone have any real numbers, or
> is this just folklore?).  If it is too expensive, then I suspect the
> only reason is because it must look for newer versions of the
> function.  If that is enough to cause feval to be too slow, then any
> .oct file function would be too slow to call from Octave, since I
> think the mechanism used by feval is essentially the same as Octave
> uses internally for any function call.

If you are doing small ops many times over then the cost of feval
will be high.  If you are doing large ops or few iterations then
the cost of feval will be low.

If you are doing, e.g., 70000 generations of a genetic
algorithm with 50 individuals in your population, the
3.5 million fevals to the objective function can add up.
Similarly, it would be nice to link directly to the random
number generator.

I'm attaching code for heapsort, which performs an nlogn
operation on each column of a matrix.  If called with
'feval' then it recursively calls itself on each column
without 'feval'.

Compile using:

  mkoctfile2.9 nlogn.cc heapsort.c

Many small operations shows a big speed improvement:

 X=rand(40,30000);
 tic; nlogn(X,'feval'); toc
 tic; nlogn(X); toc

 Elapsed time is 7.708801 seconds.
 Elapsed time is 2.339371 seconds.

Few large operations doesn't show much improvement:

 X=rand(30000,40);
 tic; nlogn(X,'feval'); toc
 tic; nlogn(X); toc

 Elapsed time is 8.600800 seconds.
 Elapsed time is 7.414604 seconds.

The extra 1.2 seconds in 'feval' is probably due to copying
the array, something that was not necessary with direct calls.

- Paul

nlogn.cc
Description: Binary data

heapsort.c
Description: Text document