Re: efficient function parameter copying?

[Michael Pronath]

> On 10-Sep-1999, Michael Pronath <address@hidden> wrote:
> 
> | yes, that's what I thought, too.  But in your example definitions, it's
> | function y=f(x), while I meant function x=f(x).  And you call it with
> | w=f(z), while I meant z=f(z).  This is an important difference, as in
> | my case, the formal input and output parameters are the same plus the
> | actual input and output parameters are the same.  Of course, my function
> | performs changes on x, else it would be without any effect.
> 
> OK, I understand what you are trying to accomplish now.
> 
> | This optimization could be simply done by taking the names of the
> | actual parameters and the formal parameters of a function call and
> | searching for "matching pairs".  This could make a true "call by
> | reference" possible.
> 
> If it is that simple, then perhaps you'd like to submit a patch!  :-)
> 
> jwe
> 

I tried a little on this and now can detect the case for a single parameter
function call in tree_simple_assignment::rvalue.  But I don't know much about
the design internals of octave, so I'm not sure how to implement the rest of
it.  As it seems to me, all boils down to this:

  1. detect, if there is an input argument - output argument equivalence, like
     "[d,c] = f(c,x);" in an assignment, where the right hand side is a 
function
     call. (already done)
  2. If this is the case for parameter c, decrease the reference count of c by 
1,
     but do not delete c if the ref.count becomes 0.
  3. As soon as local parameters get bound to c, they increase the reference
     count.  If it doesn't get higher than one, they modify c's content 
directly
     without copying.
  4. After function evaluation, assign the return values to the output 
parameters.
     Delete all values with reference count 0.     

Is this the right way to do it?

In comparison to the normal way of function calling, the only difference is 
point 1
and 2. What keeps me from implementing it is the complexity of
octave_user_function::do_index_op, I simply don't understand octave internals
enough to find the correct place between all the unwind_protects and symbol 
table
things.

I was wrong when I thought the function's definition must have an input-output
parameter equivalence, too.  If the function is defined as function y=f(x), 
this
method will work just as well, when calling the function by M=f(M).  f could be
more efficient inside though, if it was defined as function x=f(x).

As many LAPACK routines operate directly on the same matrix that is given to 
them
as input, this optimization could remove some matrix copy operations for those 
low-
level things, too.

BTW, is there another mailing list better suited to octave internals than
"help-octave"?

  Michael

pgp5dPPrVNk3a.pgp
Description: PGP signature