David T. Lewis wrote:
> On Sun, Dec 17, 2006 at 12:50:09PM -0500, David T. Lewis wrote:
>> On Sun, Dec 17, 2006 at 04:56:45PM +0000, daniel poon wrote:
>>> David T. Lewis <lewis <at> mail.msen.com> writes:
>>>> Bert is referring to an OS process (unix, win32), not a Smalltalk
>>>> process. So the plugin could fork an OS process and communicate with
>>>> it through any of several mechanisms.  But his suggestion of a toolkit
>>>> that does not require callbacks is really the first thing that you
>>>> should consider.
>>> Thanks for your clarification and your code snippets. 
>>> I was using the GUI callback as an illustration of a callback, but what I am
>>> really interested in is calling back from foreign mathematical libraries, and
>>> how to do that in Squeak. We have had some success in doing such things in
>>> another Smalltalk dialect, and I want to know if I can port that work on to 
>>> Squeak. 
>>>
>>> Will using separate processes perform well enough? To simulate a few seconds
>>> using a physics simulation, a maths library would have to make about a million
>>> callbacks into Smalltalk. You would want the simulation to take seconds or
>>> minutes rather than hours. 
>> My guess is that separate processes would *not* perform well enough, but my
>> guessing does not count for much. If you have a fairly good idea of how many
>> callbacks are happening, it might be worth putting together a no-op test
>> to find out how fast it runs. You could for example run a million transactions
>> with Squeak sending "hello there" (and flushing the stream), and a C program
>> echoing the message back but otherwise doing nothing. The results will
>> probably be disappointing, but you never know.
> 
> Daniel,
> 
> To follow up on my comment above, I put together a test that has Squeak
> forking another Squeak image, then sending 'hello' back and forth a million
> times between the two images, each of which is running in a separate OS
> process. The one million transactions run in about 150 seconds on my 166MHz
> Pentium. I guess that on faster hardware it would do better.
> 
> So somewhat to my surprise, it does seem reasonable to consider using simple
> communications through a pipe for the kind of work you are describing, and
> expect performance in the "minutes not hours" range.
> 
> Here is the test that I ran:
> 
>     | sendPipe receivePipe s remote count |
>     count := 1000000. "One million transactions"
>     sendPipe := OSPipe blockingPipe.
>     receivePipe := OSPipe blockingPipe.
>     remote := UnixProcess forkHeadlessSqueakAndDoThenQuit:
>         ["This block is evaluated in the remote headless Squeak image"
>         (count + 1) timesRepeat:
>             ["Read message and echo it back to sender"
>             s := sendPipe next: 5.
>             receivePipe nextPutAll: s; flush]].
>     remote inspect. "Inspect the process proxy for the remote Squeak"
>     sendPipe nextPutAll: 'hello'; flush.
>     receivePipe next: 5. "do one complete transaction before starting the timer"
>     (Time millisecondsToRun:
>         [count timesRepeat:
>             [sendPipe nextPutAll: 'hello'; flush.
>             receivePipe next: 5]]) inspect. "Inspect run time in milliseconds"
>     sendPipe close.
>     receivePipe close.
> 
> 
> Dave

Hi Dave

That makes it an overhead 0.15ms per callback, which is acceptable. I 
will need to pass back an forth a packed array of floating point numbers 
with a few hundred elements in it (representing the state of the system 
and its calculated derivative). How could that be achieved without 
denting that 0.15ms overhead too much?

Cheers

Daniel