On Mon, Jul 7, 2008 at 5:45 AM, Jason Johnson <jason.johnson.081 at gmail.com>
wrote:

> On 7/5/08, Peter William Lount <peter at smalltalk.org> wrote:
>
> > To take advantage of multi-core what is needed is real native
> > multi-threading per virtual machine + image not simply one native thread
> per
> > image. Both are good for various application scenarios. Remember that a
> real
> > multi-native threaded image can always just run one native thread if you
> > want it too while a single native thread virtual machine + image will not
> > run multiple native threads in the same image space. Sure multiple images
> in
> > one program memory space is nice for some scenarios. I like that too and
> > desire the option to deploy that way with multiple native threads per
> image
> > space in one program memory space.
>
>
> If you mean what I think you mean (fine grained shared state
> multi-threading) then I find this a pretty ironic message: "the
> multi-cores on upon us, we need to hurry up and adapt the method of
> concurrent program that absolutely wont work on 1k+ cores".
>
> The whole reason the "mega-cores" are interesting is that we have to
> *change how we program them*.  Interesting how you are pointing out
> later in this thread about others "not getting it" while managing to
> miss this sky scraper size billboard.
>
>

Smalltalk has the best concurrent programming potential I've seen in a
programming language. The concurrent features are all there - blocks are
easy to fork, semaphores are easy to use, and very nice concurrent
abstractions can be built up using this powerful language. I can't see any
reason that a Smalltalk VM won't run well on 1k+ cores with good concurrent
algorithms.

I agree completely with Peter.

I'm not going to contribute to this flame war though as I'm not going to
start work on a shared-state concurrent VM any time soon.

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/20080707/71c58bf1/attachment.htm