On Fri, Mar 12, 2004 at 07:57:32PM -0800, Avi Bryant wrote:
> 
> On Mar 12, 2004, at 7:53 PM, David T. Lewis wrote:
> 
> > The remote image answers the result using a SmartReferenceStream
> > communicating through an OSPipe. Requires OSProcess and a Unix VM.
> >
> > Example:
> >  OSProcess rSq: [2 + 2] => 4
> 
> Very cool.  What's the overhead?  Like how long does that 2+2 take?  
> I'm not on Linux right now or I would just try it...

Wall clock time on my system:

((1 to: 100) collect:
  [:e | Time millisecondsToRun:
    [OSProcess rSq: [2 + 2]]]) average asFloat => 112.72

The load on the system is surprisingly small. A #forkSqueak does not
incur the normal cost of a Squeak image activation. The VM is already
loaded, and it does not need to allocate any new system memory for
object memory right away. The host OS virtual memory will just grab
pages when the child Squeak actually modifies them.  There does not
appear to be a whole lot of memory being modified to add 2 + 2, so
it's pretty fast.

When I ran the timing test above, I kept an xosview window open. I
could see some extra CPU load while the 100 #forkSqueaks were being
run, and no visible change to memory allocation. I got similar results
with a Gnome System Monitor graphical system monitor, but it's hard
to tell because the system monitor is putting more load on the system
than Squeak is. I think that most of the actual runtime is used in
waiting, either from OS process scheduling or the delay loop in
the #rSq method.

I expect that 100msec of the 112.72 wall clock time is from the delay
loop that waits for the child Squeak to exit. I'm sure this could
be done better, but guess it's OK for a CSOD, especially considering
I wrote it after I got home from the bar on Friday night ;)

Dave