help-octave
[Top][All Lists]
Advanced

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

Re: Realtime cost of call by value


From: Przemek Klosowski
Subject: Re: Realtime cost of call by value
Date: Wed, 5 Nov 2003 13:18:41 -0500 (EST)

There has been a discussion recently about efficient passing of arrays,
and the discussion quickly moved past the issue at hand ('how to avoid
needless copying') into syntactical flavors of passing by reference.

My initial reaction to this discussion was that since we have 'by
value' and 'by reference' parameters in the usual high level languages
(C/C++, etc) and it looks like it may help Octave, it's worth
implementing. However, after discussing it some more w/Paul Kienzle, I
became convinced that it's the wrong way to go about it. The parameter
passing is a fairly low level issue (c.f. the discussion of scoping in
Lisp that was pretty esoteric). I think that Very High Level Languages
(VHLLs) like Octave should attempt to solve problems on the highest
possible levels of abstraction. In this particular case, the issue is
the live range of variables, and how it affects data moves; so the
solution should be based on analysis of variable's lifetime.

Paul's example (b=3*a; a=[]) was perhaps unfortunate because nobody
writes code like that; this, to me, obscured his real point, namely
that the a=[] is really a 'compiler pragma',i.e. a message to Octave
interpreter that data move optimizations on 'a' are allowed
(specifically, that we can multiply in place every element of 'a' by
3, and rename 'a' to 'b'). This is more powerful than the 'ref' approach
because it benefits the existing code w/o the need to explicitly change
procedure definitions (not to mention all the changes to the interpreter
to keep track of references in presence of possibly aliased pointers)

If one believes that, then one may discuss design and implementation
issues, like how should the interpreter determine the live range:
 
 - fully automatically in the global context: I think it's impossible
   in general if we consider multi-module programs and 'eval'

 - automatically, within current module: perhaps possible, under
   some restrictions, like no 'eval' use within current module

 - automatically, within one or more statements: most generally useful
   but possibly hard to implement: modification in-place, triggered by
   overwriting of the variable within few statements
   
 - using triggering constructs: either comment-like pragmas like
   OpenMP or C preprocessor constructs, or idioms like a=f(a) or
   [a,result]=sin(a), or s=sin(discard(a)) or Paul's 'f(a);a=[]':
   simplest to implement but probably requiring most changes in 
   the existing .m files

                p



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------



reply via email to

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