[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: efficient function parameter copying?

From: Michael Pronath
Subject: Re: efficient function parameter copying?
Date: Fri, 08 Oct 1999 10:44:14 +0200

> 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 
     call. (already done)
  2. If this is the case for parameter c, decrease the reference count of c by 
     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 
     without copying.
  4. After function evaluation, assign the return values to the output 
     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 

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), 
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 
as input, this optimization could remove some matrix copy operations for those 
level things, too.

BTW, is there another mailing list better suited to octave internals than


Attachment: pgp5dPPrVNk3a.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]