On 2/23/08, Joshua Gargus <schwa at fastmail.us> wrote:
>
>
> On Feb 22, 2008, at 11:51 PM, Michael van der Gulik wrote:
>
>
>
> 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.
>
>
> Because within HydraVM, each VM has it's own ObjectMemory in a single,
> contiguous chunk of memory.
>
> Below, you mention processor-affinity.  This is certainly necessary, but
> is orthogonal to the issue.  Let's simplify the discussion by assuming that
> the number of VMs is <= the number of cores, and that each VM is pinned to a
> different core.
>
> 32-bit CPU caches typically work on 4KB pages of memory.  You can fit
> quite a few objects in 4KB.  The problem is that is processor A and
> processor B are operating in the same ObjectMemory, they don't have to even
> touch the same object to cause cache contention... they merely have to touch
> objects on the same memory page.  Can you provide a formal characterization
> of worst-case and average-case performance under a variety of application
> profiles?  I wouldn't know where to start.
>


Well... we'll revisit this when we actually have a VM capable of running a
single image on multiple threads.


I haven't had a chance to take more than a glance at it, but Ulrich Draper
> from Red Hat has written a paper named "What Every Programmer Should Know
> About Memory".  It's dauntingly comprehensive.  (What Every Programmer
> Should Know About Memory) <http://people.redhat.com/drepper/cpumemory.pdf>
>
>
>

Thanks for the link; I'll read it tomorrow.

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/af339a1d/attachment.htm