Callbacks from C into Squeak
mr.d.poon at gmail.com
Mon Dec 18 10:11:46 UTC 2006
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
>>> 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.
> 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.
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?
More information about the Squeak-dev