On Wed, Apr 29, 2009 at 5:13 PM, Joshua Gargus <schwa at fastmail.us> wrote:

>  Michael van der Gulik wrote:
>
> On 4/29/09, Igor Stasenko <siguctua at gmail.com> <siguctua at gmail.com> wrote:
>
>  As for moving to multi-cores.. yes, as Gulik suggests, its like adding
> a new dimension:
>  - local scheduler for each core
>  - single global scheduler for freezing everything
>
> This, of course, if we could afford running same object memory over
> multiple cores. Handling interpreter/object memory state(s) with
> multiple cores is not trivial thing.
>
>
>  Implementing it isn't hard. It's fixing all the bugs we'll find that's
> hard. There'll be bugs in the image and in the VM, and it'll be a good
> 30 years before we've found them all.
>
>
>
> LOL, did I miss a smiley?  Doesn't sound trivial to me.
>
> With great effort, I will avoid getting into another long thread about how
> a Hydra-like model is more suitable to the memory architectures of future
> multi-core processors (Nehalem is already splitting up the L2 between cores
> instead of making it uniformly accessible to all cores, and this trend will
> continue).
>

I love this thread :)

I don't think there's a smiley missing. Hydra is wonderful because it
provides concurrency in an elegant way, but the price of that elegance is
that it completely ignores the IPC issues.

Threading is easy. Sharing is hard. Hopefully I'm not speaking out of
school, but it seems that the semaphore discussions are independent of
Hydra. It's not an alternative, but maybe a precondition.

Cheers,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090429/33dd6708/attachment.htm