Re: Realtime cost of call by value

[Glenn Golden]

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

Oh, I was just tweaking you about that. :)  What you did was *extremely*
helpful, the order of magnitude error was not even important.  It was
trivial to find and fix.

> 
> Okay, now YOUR turn for an existence proof!
>

(I already did it; I just need to figure out how to make it efficient! :)
That's the key.  See below.)

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

Certainly. That's what the attached DLD does (attached to previous
email, not this one).

It is intended to be executed from the Octave command line after
the global "foo" has already been brought into existence from
the interpreter. (In fact, it checks for the exsitence of foo first,
and if you attempt to execute it prior to bringing foo into global
existence, it will whine and return.)

You can play with it yourself if you want. The build scripts that
come with Octave make it trivial (kudos to John and/or Paul for
this, it really makes it easy.) Just place the hmmmwrap.cc file
into a directory and do

        $ mkoctfile hmmmwrap.cc

This will create the .oct file "hmmmwrap.oct" which you can then
execute from the octave command line. (Assuming you have dynamic
linking enabled in your Octave.)

Try something like this:

    octave:1> ignore_function_time_stamp = "all";
    octave:2> global foo
    octave:3> foo = rand(10); foo(1,1)
    ans = 0.63451

    octave:4> hmmmwrap; foo(1,1)
    et = 46.0 usec                      
    ans = -99999

    octave:5> hmmmwrap; foo(1,1)
    et = 11.0 usec
    ans = -99999

(Ignore the first run, as above, because the elapsed time on the
first one is dominated by the lookup for the .oct file.)

Now increase the size of foo and see how the et increases also:
(Do a few runs of each, to average over the OS-induced variations
due to interrupts, etc.)

    octave:6> foo = rand(100); foo(1,1)
    ans = 0.94466
    octave:7> hmmmwrap; foo(1,1)
    et = 195.0 usec
    ans = -99999

    octave:8> hmmmwrap; foo(1,1)
    et = 122.0 usec
    ans = -99999

    octave:9> hmmmwrap; foo(1,1)
    et = 121.0 usec
    ans = -99999

    octave:10> hmmmwrap; foo(1,1)
    et = 120.0 usec
    ans = -99999



    octave:11> foo = rand(1000); foo(1,1)
    ans = 0.77899

    octave:12> hmmmwrap; foo(1,1)
    et = 21268.0 usec                   <---- Ow.
    ans = -99999

    octave:13> hmmmwrap; foo(1,1)
    et = 21150.0 usec
    ans = -99999


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

That's exactly what I'm planning to do; there's no reason to flog
oneself by doing non-realtime-intensive things in DLDs. That's the
beauty of the way that DLDs work, you can just dedicate them to the
tasks that have a need for speed, do everything else in the interpreter
where it's faster and easier to write and debug.

The problem is that I cant' get the DLD to duplicate what the
interpreter is clearly able to do, thanks to your example. Hopefully,
someone knows the magic incantation that will allow the DLD operations
on globals to mimic whatever it is that the interpreter is doing.
That's what I've been looking for...

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