That was where my comment about the Self community came from.  One of 
the people on that list took the Self language and made every method 
return a "future" object immediately.  This future object would only do 
the message send when asked for its value (by being the target of 
another message send or primitive).  Passing a future as an argument 
does NOT evaluate it.  This simple change in semantics allows each 
future to be on its own concurrency path.  The computation is done in 
the background between the time it is scheduled and when it is needed.  
The result was as much as 5 way concurrency with the existing code 
base.  For code designed to be concurrent it can be much higher.  For 
example, by allowing the result of a select: collect: or detect: to be 
evaluated on the same basis would greatly increase concurrency.

These are the type of things that Smalltalk can address that C or Java 
could never hope to deal with.  We can change the semantics of these 
control structures, because they are in the language, not in the VM.  
Of course in the Squeak case we can change anything!

Now if we take the bytecode speed up from the recent JIT project and 
the new message semantics, we are getting there.  Making ObjectMemory 
concurrent will be the biggest part of the effort.

Michael



On Jan 18, 2005, at 4:21 PM, Tim Rowledge wrote:

> In message <044ru0pgeretshra4g6cniq90bgiolgeas at 4ax.com>
>           Jon Hylands <jon at huv.com> wrote:
>
>> On Tue, 18 Jan 2005 14:32:11 -0800, Michael Latta <lattam at mac.com> 
>> wrote:
>>
>>> Does the current image format associate active threads with 
>>> processors?
>>
>> Generally, that is handled by the OS. If you're running a different 
>> thread
>> on a multi-cpu machine, the OS decides which CPU to run it on...
> You're all thinking much to small - or maybe too big, depending. I
> think for _massive_ parallelism we want to be able to schedule each
> method invocation to any available compute resource. Prims would
> potentially be parallelisable as well in some cases.
> Forget all this crap about "one cpu for garbage collection and another
> for running the interpreter" - I'm talking 100, a 1000 a million cpus.
> The current sort of VM would be utterly pointless in such a world.
> Quite possibly the current sort of Smalltalk would be useless.
>
>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Useful random insult:- All booster, no payload.
>