Re: Realtime cost of call by value

[pkienzle]

[Moved to maintainers list to keep down the volume on help-octave]

On 2 Nov 2003 at 20:42, Per Persson wrote:

> 
> On Saturday, November 1, 2003, at 02:53 AM, John W. Eaton wrote:
> >
> > I would be interested in a way to pass arguments by reference, but it
> > must not be the default.  Here is a (half-baked) proposal to think
> > about.
> 
> I for one would really appreciate an option to pass arguments by 
> reference.
> (Actually, the idea gives me the same feeling I had on a christmas 
> morning as a child;-)

To have the biggest effect, the underlying liboctave
array functions (including the interface to LAPACK)
will need to operate in place, or (in the case of C=A*B) 
with preallocated memory, to avoid thrashing the heap.

> 
> >
> > Similar to C++, I think the notion of a reference argument should be a
> > property of the function definition, not the code that calls the
> > function.
> 
> Yes, definitely.

This adds complexity to the function interface.  Personally
I prefer to mark references in both the caller and the callee
so that the maintainer doesn't have to know the intimate
details of the API when debugging problems.

Ideally you could get the advantages of references (no 
thrashing of the heap) without the disadvantages (not 
knowing if a particular variable can be changed out from
under you) if you could tell that a variable is no longer 
needed after an expression is complete.  

A simple example:

        A = 3*sin(A)+5;

I believe octave generates a new matrix for sin(A), another
for 3*sin(A) and a third for 3*sin(A)+5, then it frees the
ones for A, sin(A) and 3*sin(A).  This operation could
be done without any heap manipulation if all the steps
were done in place.

The situation is no different if you have a function 
 
   f(A) = 3*sin(A)+5

and you set A=f(A).  

Other cases are more complicated:

        B = 3*sin(A) + 5;
        A = rand(34);

In general, doing the static analysis to determine whether
a variable will be needed again is impossible (maybe a
different branch of an if will be taken; maybe it is used in
an eval), but for simple cases where A appears as a LHS
value we can be guaranteed it will no longer be needed
after the RHS is calculated.  The more complicated cases
can be handled by artificially using e.g. A=[] after the
last RHS that refers to A, so we know we only need to
check one statement ahead.

The situation is even more complicated if instead of A
you are referring to an element of a structiure or list
such as A.x or A{i,j}.

Even handling the simple cases will require a lot of work,
never mind the complicated ones. Perhaps it could be 
made easier with some pragmas to tell the interpreter 
what it could otherwise discover by itself, but I have no
suggestions for what those might be.

Paul Kienzle
address@hidden