[squeak-dev] The "correct" approach to multi-core systems.

Joshua Gargus schwa at fastmail.us
Sat Feb 23 06:00:06 UTC 2008


On Feb 22, 2008, at 7:01 PM, Michael van der Gulik wrote:

>
>
> On 2/22/08, Stephen Pair <stephen at pairhome.net> wrote:
> I must say, this is a really impressive development.  I really think  
> this is the right way to approach multi-core systems.
>
>
>
> I disagree about it being the right approach in the long term.
>
> In the short term, the Hydra VM allows the use of multiple cores  
> without large changes to the core of Squeak, which is good and IMHO  
> the right decision for a quick and reliable solution (for whoever  
> Igor is doing his work for... Qwaq?). The disadvantage with the  
> Hydra VM is that all inter-process communication needs to go through  
> a pipe;

This is incorrect.  There is no inter-process communication because  
there is only one process with multiple thread, each running a  
separate VM.

> 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.

Josh


>
>
> I can't imagine that hacking the VM with multiple processes, per- 
> process state and a global VM lock for garbage collection and new  
> object creation would be too difficult. The global VM lock would  
> kill scalability and could make object creation slow, but it should  
> still get some speedup on multi-cored CPUs. More advanced VMs with  
> per-thread eden space would take a bit longer to write.
>
> 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/20080222/07db6473/attachment.htm


More information about the Squeak-dev mailing list