Callbacks from C into Squeak

On Wed, 20 Dec 2006 11:06:31 -0500, "David T. Lewis" <[hidden email]>
wrote:

> - With 4000 byte uninterpreted data messages, overall transaction
>   time is under 0.5 msec per end-to-end transaction..

David,

For my latest robotics project (see signature link below for details), I'm
planning on running two images on my Core Duo laptop -- one for running the
"brain", and one for doing visual processing. The visual processing image
will be passing a decent amount of data to the "brain" image, using sockets
on localhost (is that what you did?)

What OS were you using for your test?

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Raptor (Small Biped Velociraptor Robot)
           http://www.huv.com/blog

On Wed, Dec 20, 2006 at 11:13:35AM -0500, Jon Hylands wrote:
Jon,

This is on Linux (version 2.4) on a 166MHz Pentium. I'm using pipes
(as in pipe()) through the OSProcessPlugin that comes with the Squeak
Unix VM. I don't know what the results would look like using a socket
connection, but it might be quite similar. You could probably adapt
one of the tests in the change set that I sent, and see what happens.

Let me know if you get good results. Using sockets might be an easier
way to do this sort of thing on Windows (I never did figure out a good
way to do non-blocking OS pipes on Win32).

Dave

David T. Lewis wrote:

> - With 4000 byte uninterpreted data messages, overall transaction
>   time is under 0.5 msec per end-to-end transaction..

Hi David

Im running on a pentium 4 @ 3GHz. Naively, given that your computer runs
at 0.166GHz, dividing 3GHz/ 0.166GHz means that my computer is 17X
faster, so your 0.5ms end-to-end transaction would take 0.03ms on my
computer.

I ran some benchmarks on our existing code in VSE running on a real
simulation situation. Executing the actual maths calculation in the
Smalltalk callback took 0.16 ms.

Total solve time divided by the number of callback gives 0.36 ms per
callback. Time included in the 0.36 ms covers time spend integrating the
ODE in Fortran, the mechanics of the callback, and actually doing the
maths in the callback.

So the overhead of 0.03ms to perform the callback mechanism is indeed
acceptable.

Interestingly, only half the total time is spent in the Smalltalk maths
calculation. I would like to work out how the time is split in our
existing code further, i.e. how much time is spend in the VSE callback
mechanism, and how much time is spent in Fortran doing the ODE
integration. That would tell me whether the main overhead is doing an
ODE integration, or whether providing sample points via a Smalltalk
callback is the main speed issue. Im not sure how to do that though...

Cheers

Daniel

dan wrote:
> Interestingly, only half the total time is spent in the Smalltalk maths
> calculation. I would like to work out how the time is split in our
> existing code further, i.e. how much time is spend in the VSE callback
> mechanism, and how much time is spent in Fortran doing the ODE
> integration. That would tell me whether the main overhead is doing an
> ODE integration, or whether providing sample points via a Smalltalk
> callback is the main speed issue. Im not sure how to do that though...

Ive just done a benchmark, and the time taken to do a VSE callbak is
0.05ms, which is not much faster than the process 2 process solution you
suggested. Revising the figures using a non-debug DLL..

The total time spent in Smalltalk is 0.2ms, split into 1/3 performing
the callback, and 2/3 doing the calculation.

The total time spent in Fortran is 0.1ms.

We spend twice as much time in Smalltalk as we do in Fortran. Moving
everything into Fortran would at maximum tripple the runtime speed,
which is not a great return on investment.

Moving the ODE solver from Fortran into a high level language like
Matlab or Smalltalk would kill performance. So, the current solution
sounds like the right architecture.

Daniel

On Thu, Dec 21, 2006 at 11:33:31AM +0000, dan wrote:
Is your Smalltalk VSE code portable enough that you can get it running
in Squeak? If so, it would not be hard to run a test to see how fast
it actually goes. We could just hack it into one of the tests that
I sent you earlier and have one of the Squeak images play the role
of the Fortran program, sending some dummied-up data to the other
Squeak doing the "callback."

Dave

David T. Lewis wrote:

> Is your Smalltalk VSE code portable enough that you can get it running
> in Squeak? If so, it would not be hard to run a test to see how fast
> it actually goes. We could just hack it into one of the tests that
> I sent you earlier and have one of the Squeak images play the role
> of the Fortran program, sending some dummied-up data to the other
> Squeak doing the "callback."

The code itself is not very portable, since it is part of a very large
application program (http://www.romaxtech.com/software.php).

Have a look at my posts in the context of this thread for an idea of the
issues we face:

http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/109981/focus=109981

Most of the callback consists of matrix operations dones as primitives.
The non-matrix operations are done in Smalltalk. As soon as they get too
slow, which will happen as the complexity of the model increases, they
will be moved into Fortran.

Daniel