On Aug 17, 2006, at 7:37 AM, Michael Latta wrote:
>
>
> You mention that you will be running multiple simulations.  Running  
> each
> simulation in a separate image is far more likely to produce good
> scalability.  You can easily use various methods to move control  
> objects
> from one image to another to coordinate the simulations and migrate  
> data
> from one image to another at the beginning of a simulation.  I  
> would pursue
> that approach much more than trying to get 2 cores to run faster.

This is really the approach I was looking at. I'd have a master  
controller that maintained a pool of available simulations. Slave  
processes would request a simulation, process it, then asynchronously  
return the results. The master would be idle most of the time, so the  
slaves should be able to grab most of the available CPU power  
(especially if I can place them on separate machines or across a  
cluster).

I'm not sure how to do distributed processing in squeak though. I'd  
rather not deal with it at the socket level (though that would be  
possible). rST looks promising, but I'm a little concerned about its  
stability (the wiki page says "Testers are needed!" which makes me  
pause).

The difficulty in finding a good way to do distributed processing  
surprises me. I thought distributed processing was supposed to be one  
of Smalltalk's fortes. Which probably means I'm just missing  
something obvious again.

-Rich-