In SqueakElib, each object in the collection would need to be placed in a 
different Vat.  Then you just run your Collection>>#do: or 
Collection>>#collect: over the elements and then any msgs sent to each 
element in the block will evaluate in the various vats.  No special syntax 
is needed.  In the case of #collect:, the evaluation will initially return 
promises, which will later resolve to the result of the msg send, which may 
be the result of the block.   The blocks themselves are not remotely 
evaluated.

Another way to go is to convert the collection to an eventual reference and 
send msgs to it, while still allocating the elements to different vats:
    aColl eventual collect: aBlock.
These msgs would be evaluated in the current vat, except for those sent to 
the elements, but you would always get back an eventual ref to a collection 
holding promises for the results of the block evaluations.  It would be more 
consistent to use this approach.

Rob

----- Original Message ----- 
From: "Matthew Fulmer" <tapplek at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, January 23, 2008 10:34 PM
Subject: Vats, Islands, and Collections: Finding cheap parallelism


> I'm going to be working on making squeak multi-core as part of
> my grad work. I have a bit of work to do before I get to the
> stage where I actually have to implement a parallel code model,
> but I am thinking about it in the abstract as a mental exercise
> for now. I will most likely use the vats/islands system used by
> SqueakELib and Croquet, as it has been validated.
>
> But I have a pressing concern: How could this be used to do what
> seems (to me and my mentors) to be the cheapest, simplest, most
> obvious parallelism extraction ever: get Collection>>do:,
> collect:, etc. to run one element per native thread (= vat =
> island).
>
> However, I may be overlooking copying costs (code, objects, or
> both) that make this more a naive parallelization than I expect.
> Assuming the elements are read-only for the duration of the
> enumeration (the common case), they can be safely copied
> willy-nilly to whatever vat they need to be in to run (or use
> shared memory if it is available and fast).
>
> Can this be done using vats? Does copying kill it? I get asked
> about this problem every time I talk about vats. Everyone seems
> to think this (loop-level parallelism) is the simplest, most
> fool-proof way to make things faster on a multi-core system, and
> give me funny looks when I don't have a quick answer on how this
> works in the vats model.
>
> -- 
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
> Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
>
>