From help-octave-request at bevo dot che dot wisc dot edu Tue Oct 28 13:36:37 2003
Subject: Re: Realtime cost of call by value 
From: Glenn Golden <gdg at zplane dot com>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
Cc: help-octave at bevo dot che dot wisc dot edu
Date: Tue, 28 Oct 2003 12:36:24 -0700

John, Tomer --

Thanks for your responses. Comments below.

"John W. Eaton" writes:
> 
> Then the const version of the indexing function (which does
> not force a copy) should be called.
> 

Aha.  Thanks, I should have realized that.  My lack of familiarity with C++.


> Yes, there are some C++ tricks that could maybe be used to make it so
> that no copy would happen unless the indexing operation appears on the
> LHS of an assignment expression.
>

Nah, I think you're being too hard on yourself.  Now that I understand
my mistake, it seems entirely reasonable to just keep it in mind, and
use the const.  It's not unreasonable that DLD writers should have to
be more aware of details like this, or find out the hard way like I just
did. You can't prevent everyone from shooting themselves in the foot in
every conceivable way.


Tomer Altman writes:
>
> For your large, main Abstract Data Structures ( not Octave
> 'structures', necessarily ), declare them as global variables from the
> main function / interpreter. Then, just pass *indices* via
> call-by-value. This should give you a 'hack' that simulates
> call-by-reference.
>

Thanks for your suggestion, it's interesting, I'm not sure it
will help me with the realtime issue though, although perhaps
I'm just not understanding it.  I'm relatively new to Octave,
and not particularly experienced in C++ either (as you can tell
from the above) so I may just be missing your point entirely.
Let me briefly explain, and perhaps you can tell me in a little
more newbie detail how I could exploit your idea.

What I'm trying to do is determine whether it is feasible to write
a DLD which can efficiently operate on a large data structure (in
this case, it does happen to be a native Octave object, a Matrix,
but as you point out, that's not really relevant).

Clearly, performing the operation on a DLD function argument is
out of the question, efficiency wise; the implicit copy-down and
copy-up which occurs behind the scenes when modifying the value
of an argument (and then returning the modified value) eats up
as much realtime as the operation itself.  If I could perform the
operation on a global Matrix, rather than on a function argument,
that would be just fine. Not as clean of course, but still, I would
be happy to live with the namespace pollution if I could get the
efficiency. And I have tried this, but when dealing with globals,
I can't see how to avoid doing things like


    octave_value tmp = get_global_value("big_matrix");
    Matrix A = tmp.matrix_value();
    < operate on A >
    tmp = A;
    set_global_value("big_matrix", tmp);


which incurs the same realtime cost as operating on a function
argument, except that the copy-down and copy-up are explicit rather
than implicit.  And it also incurs the additional cost of the symbol
table lookup.

So my feasibility question boils down to this: Is there a way to
operate in-place on big_matrix without incurring these data movement
costs? Perhaps what you've suggested solves exactly this problem,
but I need a more elementary answer in order to understand it.

Thanks again.

Glenn



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