On 10/17/07, gruntfuttuck <gruntfuttuck at gmail.com> wrote:
>
>
> How is squeak going to handle multy-core CPUs, if at all? If we see cores
> of
> 100 plus in the future and squeak stay as it is, I would imagine other
> languages such as erlang, will look more attractive.
>

The answer seems pretty obvious: modify the VM to support them. I'll skim
over the details which I'm sure everybody already knows.

My question is: what are we going to do with multi-core CPUs? The code in
the image is almost all single threaded. Morphic freezes up when I run
something in the workspace (!!). Smalltalkers just don't seem to understand
multi-threaded code, even though the basic capabilities been available to
them since day one.

I use Futures now and then; I implemented them myself:

f := Future doing: [ some long computation ].
... insert more code here which runs in parallel with the long computation.
f printResult. "Will block until the long computation has returned the
result into f and then print the result. "

I imagine that a parallel collection package would be possible to make:

c := ParOrderedCollection new. "or ParSet, ParBag..."
c addAll: lots of stuff.
c do: [ :each | each doSomething ]. "Will fork a Process for each element in
c. "
c map: [ :each | each transform] andGather: [ :each :sum | sum combineWith:
each]. "Google's map and gather algorithm"

Object>>changed: can be modified to be parallel; this makes the
dependents/updating framework parallel. I did this and the image seemed to
work fine.

There's heaps of parallel stuff you can do in Squeak. One day I'd like to
have a crack at making the VM use pthreads more, but that will be the day
after people actually start writing parallel code.

Gulik.

-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071023/c1d59ee2/attachment.htm