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