<br><br><div class="gmail_quote">On Wed, Apr 29, 2009 at 5:13 PM, Joshua Gargus <span dir="ltr"><<a href="mailto:schwa@fastmail.us">schwa@fastmail.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="im">
Michael van der Gulik wrote:
<blockquote type="cite">
<pre>On 4/29/09, Igor Stasenko <a href="mailto:siguctua@gmail.com" target="_blank"><siguctua@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>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.
</pre>
</blockquote>
<br></div>
LOL, did I miss a smiley? Doesn't sound trivial to me.<br>
<br>
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).</div></blockquote><div><br>I love this thread :) <br><br>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.<br>
<br>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.<br><br>Cheers,<br>
Steve <br></div></div><br>