Re: Realtime cost of call by value

[taltman]

Hi Glenn,

I'm a newbie when it comes to Octave C++ hacking, so I can only give
you insights from a M-file point-of-view. 

There's some interesting information here on global variables in
Octave:
http://www.octave.org/doc/octave_8.html#SEC60

"Passing a global variable in a function parameter list will make a
local copy and not modify the global value."

This means that if you merely follow that page's syntax, and declare a
top-level variable using the 'global' "type", and declare that same
variable with that same "type" in the functions that need to access
it, then you've achieved the ability to reference the matrix without
copying it to the "local scope" of the function.

This question actually raises some interesting questions regarding
scope in GNU Octave / MATLAB. If I didn't know any better, I'd say
that aside from the "global" variable 'type', that Octave is a
functional (in terms of side-effects across various scopes) language!
This a very interesting revelation to me, from a Scheme/Lisp
background. John, could you comment more precisely on what kind of
scoping is used in Octave, especially in terms of M-files
vs. Oct-files, and when one calls the other, etc.? It's not precisely
clear to me...

Cheers,

~Tomer

P.S.- There's a typographical error on the Global Variables section of
the Manual, both in the Info page & on the web. In the section talking
about 'default_global_variable_value', there's a version of the
built-in variable name that was typed as,
"default_glbaol_variable_value".




On Oct 28, 2003 at 12:36pm, Glenn Golden wrote:

gdg >Date: Tue, 28 Oct 2003 12:36:24 -0700
gdg >From: Glenn Golden <address@hidden>
gdg >To: John W. Eaton <address@hidden>
gdg >Cc: address@hidden
gdg >Subject: Re: Realtime cost of call by value
gdg >Resent-Date: Tue, 28 Oct 2003 13:36:27 -0600
gdg >Resent-From: address@hidden
gdg >
gdg >John, Tomer --
gdg >
gdg >Thanks for your responses. Comments below.
gdg >
gdg >"John W. Eaton" writes:
gdg >> 
gdg >> Then the const version of the indexing function (which does
gdg >> not force a copy) should be called.
gdg >> 
gdg >
gdg >Aha.  Thanks, I should have realized that.  My lack of familiarity with 
C++.
gdg >
gdg >
gdg >> Yes, there are some C++ tricks that could maybe be used to make it so
gdg >> that no copy would happen unless the indexing operation appears on the
gdg >> LHS of an assignment expression.
gdg >>
gdg >
gdg >Nah, I think you're being too hard on yourself.  Now that I understand
gdg >my mistake, it seems entirely reasonable to just keep it in mind, and
gdg >use the const.  It's not unreasonable that DLD writers should have to
gdg >be more aware of details like this, or find out the hard way like I just
gdg >did. You can't prevent everyone from shooting themselves in the foot in
gdg >every conceivable way.
gdg >
gdg >
gdg >Tomer Altman writes:
gdg >>
gdg >> For your large, main Abstract Data Structures ( not Octave
gdg >> 'structures', necessarily ), declare them as global variables from the
gdg >> main function / interpreter. Then, just pass *indices* via
gdg >> call-by-value. This should give you a 'hack' that simulates
gdg >> call-by-reference.
gdg >>
gdg >
gdg >Thanks for your suggestion, it's interesting, I'm not sure it
gdg >will help me with the realtime issue though, although perhaps
gdg >I'm just not understanding it.  I'm relatively new to Octave,
gdg >and not particularly experienced in C++ either (as you can tell
gdg >from the above) so I may just be missing your point entirely.
gdg >Let me briefly explain, and perhaps you can tell me in a little
gdg >more newbie detail how I could exploit your idea.
gdg >
gdg >What I'm trying to do is determine whether it is feasible to write
gdg >a DLD which can efficiently operate on a large data structure (in
gdg >this case, it does happen to be a native Octave object, a Matrix,
gdg >but as you point out, that's not really relevant).
gdg >
gdg >Clearly, performing the operation on a DLD function argument is
gdg >out of the question, efficiency wise; the implicit copy-down and
gdg >copy-up which occurs behind the scenes when modifying the value
gdg >of an argument (and then returning the modified value) eats up
gdg >as much realtime as the operation itself.  If I could perform the
gdg >operation on a global Matrix, rather than on a function argument,
gdg >that would be just fine. Not as clean of course, but still, I would
gdg >be happy to live with the namespace pollution if I could get the
gdg >efficiency. And I have tried this, but when dealing with globals,
gdg >I can't see how to avoid doing things like
gdg >
gdg >
gdg >    octave_value tmp = get_global_value("big_matrix");
gdg >    Matrix A = tmp.matrix_value();
gdg >    < operate on A >
gdg >    tmp = A;
gdg >    set_global_value("big_matrix", tmp);
gdg >
gdg >
gdg >which incurs the same realtime cost as operating on a function
gdg >argument, except that the copy-down and copy-up are explicit rather
gdg >than implicit.  And it also incurs the additional cost of the symbol
gdg >table lookup.
gdg >
gdg >So my feasibility question boils down to this: Is there a way to
gdg >operate in-place on big_matrix without incurring these data movement
gdg >costs? Perhaps what you've suggested solves exactly this problem,
gdg >but I need a more elementary answer in order to understand it.
gdg >
gdg >Thanks again.
gdg >
gdg >Glenn
gdg >
gdg >
gdg >
gdg >-------------------------------------------------------------
gdg >Octave is freely available under the terms of the GNU GPL.
gdg >
gdg >Octave's home on the web:  http://www.octave.org
gdg >How to fund new projects:  http://www.octave.org/funding.html
gdg >Subscription information:  http://www.octave.org/archive.html
gdg >-------------------------------------------------------------
gdg >
gdg >



-------------------------------------------------------------
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
-------------------------------------------------------------