Re: Realtime cost of call by value

[taltman]

Hey Glenn,

I'm glad that my 'existence proof' was useful, even if only accurate
within an order of magnitude. ;-)

Okay, now YOUR turn for an existence proof! Here's the question:

If you define a global variable in an M-file and/or from the
interpreter, and you then call a *.oct file that you crafted yourself,
is there a way to access that global variable? If so, you might be
able to get away with a 'hybrid' approach, where all of your
computationally-expensive functions are *.oct files, and you're just
orchestrating them from a M-file.

BTW, jwe? Could you commend on the scoping properties of Octave?
Between M-files, the interpreter, and *.oct files?

Thanks,

~Tomer


On Oct 29, 2003 at 10:16am, Glenn Golden wrote:

gdg >Date: Wed, 29 Oct 2003 10:16:21 -0700
gdg >From: Glenn Golden <address@hidden>
gdg >To: address@hidden
gdg >Cc: address@hidden
gdg >Subject: Re: Realtime cost of call by value
gdg >Resent-Date: Wed, 29 Oct 2003 11:16:24 -0600
gdg >Resent-From: address@hidden
gdg >
gdg >Hi Tomer,
gdg >
gdg >address@hidden writes:
gdg >> 
gdg >> I just did a set of timing tests, and I believe that there might be
gdg >> some fundamental difference.
gdg >>
gdg >
gdg >I agree.  In fact, plotting the call by value and "call by global" timing
gdg >separately, rather than the difference between the two, shows it very
gdg >clearly.  The call by value time increases roughly linearly in the size
gdg >of the array, which is consistent with copy down, while the global times
gdg >remain nearly flat. (There is some small growth in the "call by global",
gdg >but the absolute value is small [if you correct factor of 10 error in
gdg >your program :)] and is not important for my application.)
gdg >
gdg >Thanks very much for demonstrating this! It's good news because it's an
gdg >existence proof that it is possible to operate on globals efficiently,
gdg >i.e. without copy down. 
gdg >
gdg >This still leaves open my original question though: How does one go
gdg >about realizing this behavior in a DLD? (Unfortunately, I can't use
gdg >the interpter for what I'm doing for speed reasons, so I have to
gdg >do it in a DLD.) 
gdg >
gdg >When I operate on globals along the lines of what was suggested in the
gdg >mailing list from several months back (at least as I understood it), i.e.
gdg >
gdg >    OV t = get_global_value("foo");
gdg >    A = t.matrix_value();
gdg >    A(0,0) = scalar;
gdg >    t = A;
gdg >    set_global_value("foo", t)
gdg >
gdg >then the timing growth is roughly linear in the size of foo, indicating
gdg >that copy down is occurring. (The overhead of the symbol table lookup
gdg >washes out for reasonably large foos.)
gdg >
gdg >So what's the correct approach?  How does the interpreter deal with
gdg >globals in such a way that copy-down is defeated?  Is it via the
gdg >link_to_global_variable() function? If so, how is it used? I have tried
gdg >to do my homework here and figure it out myself from the sources, but
gdg >unsuccessfully so far.  Anyone?
gdg >
gdg >(My timing DLD attached, showing several approaches, none of which work.)
gdg >
gdg >- Glenn
gdg >
gdg >

hmmmwrap.cc
Description: hmmmwrap.cc