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