On 2/23/08, Joshua Gargus <schwa at fastmail.us> wrote:
>
> On Feb 22, 2008, at 7:01 PM, Michael van der Gulik wrote:
>
>
>
>
> this makes sharing objects and synchronising access while still getting
> good performance more difficult. I can't back up my claims yet; we'll see
> how Hydra VM works out.
>
> In the long term, a VM that can run its green threads (aka Process) on
> multiple OS threads (aka pthreads) should be the long-term goal.
>
>
> This is debatable.  Why are you convinced that fine-grained concurrency
> will not involve a large performance hit due to CPU cache invalidations?  I
> haven't heard a compelling argument that this won't be a problem (and
> increasingly so, as the number of cores grows).  We can't pretend that it
> takes zero time to make an object available for processing on a different
> core.  As I've said before, I'm willing to be convinced otherwise.
>
>
>

Equally so, why then would any other concurrent implementation, such as the
HydraVM, not also have exactly the same problem. Or why would any other
concurrent application not have this problem?

Real operating systems implement some form of
processor affinity[1] to keep cache on a single processor. The same could be
done for the Squeak scheduler. I'm sure that the scheduling algorithm could
be tuned to minimize cache invalidations.

[1] http://en.wikipedia.org/wiki/Processor_affinity

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/20080223/2cb13cd5/attachment.htm