<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 21, 2008, at 5:35 PM, Stephen Pair wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I must say, this is a really impressive development. I really think this is the right way to approach multi-core systems.<div><br class="webkit-block-placeholder"></div><div>At work, we have a highly distributed system (some customers are running as many as 50 nodes with a mix of VW and C++ processes on each). Occassionally some of our people in the field or customers complain that any one process isn't taking advantage of the multi-core architectures they run on. After reminding them that in fact we are using those CPUs because we are running many processes on those nodes, we also highlight the fact that our C++ component, which utilizes many threads (in a retrospectively naive way), actually degrades in performance when you drop it onto a multi-core machine (and it degrades badly). All those highly active threads contending for the same shared memory isn't quite so good. ;)</div></blockquote><div><br class="webkit-block-placeholder"></div>Could you elaborate on the shared-memory contention? Last year we were having the preliminary discussions that led to Hydra VM, and I argued (on theoretical grounds) that fine-grained multithreading within a single object memory could cause serious memory contention problems. I'd be interested to hear more about your real-world experiences.</div><div><br class="webkit-block-placeholder"></div><div>Thanks,</div><div>Josh</div><div><br class="webkit-block-placeholder"></div><div><br><blockquote type="cite"> <div><br class="webkit-block-placeholder"></div><div>- Stephen<br><br><div class="gmail_quote">On Thu, Feb 21, 2008 at 8:22 PM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class="Wj3C7c">On 22/02/2008, Andreas Raab <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:<br> > Stephen Pair wrote:<br> > > How does one start a second image (or does it do this automatically<br> > > based on the number of cores)?<br> ><br> ><br> > Load the HydraVM package and execute:<br> ><br> > HydraVM saveAsHeadlessImage: 'core.image'<br> ><br> > This will save the current image in a form ready for loading it in the<br> > background. When you've saved it, start it via:<br> ><br> > HydraVM loadAndRunNewImage: 'core.image'<br> ><br> ><br> > > On my machine, it seems to run ok for about a minute or so and then<br> > > freeze up (this is on a Windows XP core duo machine).<br> ><br> ><br> > Interesting. Others have mentioned the same effect. I'm using a slightly<br> > older version of the VM which seems a little more stable (but I know<br> > Igor is looking into the problem).<br> ><br> <br> </div></div>This was introduced due to my latest changes. Sorry guys i didn't meant that. :)<br> I had freezing problems on my own PC, and did some fixes to eliminate<br> that before releasing an update. As it turned out, something in<br> environment (Windows?) causing VM to freeze, because i tested same<br> images and with same VM binaries and it worked just fine on my PC.<br> <br> <br> > Cheers,<br> ><br> > - Andreas<br> ><br> ><br> <font color="#888888"><br> <br> --<br> </font><div><div></div><div class="Wj3C7c">Best regards,<br> Igor Stasenko AKA sig.<br> <br> </div></div></blockquote></div><br></div> <br></blockquote></div><br></body></html>