<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Feb 22, 2008, at 7:01 PM, Michael van der Gulik wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div><span class="gmail_quote">On 2/22/08, <b class="gmail_sendername">Stephen Pair</b> <<a href="mailto:stephen@pairhome.net">stephen@pairhome.net</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex"> I must say, this is a really impressive development. I really think this is the right way to approach multi-core systems.<div><br></div></blockquote></div><br><br>I disagree about it being the right approach in the long term.<br> <br>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; </blockquote><div><br></div>This is incorrect. There is no inter-process communication because there is only one process with multiple thread, each running a separate VM. </div><div><br><blockquote type="cite">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.<br> <br>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. </blockquote><div><br class="webkit-block-placeholder"></div>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.</div><div><br></div><div>Josh</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite"><br><br>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.<br> <br>Gulik.<br><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a> <br></blockquote></div><br></body></html>