<br><br><div class="gmail_quote">On Mon, Jul 7, 2008 at 5:45 AM, Jason Johnson <<a href="mailto:jason.johnson.081@gmail.com">jason.johnson.081@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 7/5/08, Peter William Lount <<a href="mailto:peter@smalltalk.org">peter@smalltalk.org</a>> wrote:<br>
<br>
> To take advantage of multi-core what is needed is real native<br>
> multi-threading per virtual machine + image not simply one native thread per<br>
> image. Both are good for various application scenarios. Remember that a real<br>
> multi-native threaded image can always just run one native thread if you<br>
> want it too while a single native thread virtual machine + image will not<br>
> run multiple native threads in the same image space. Sure multiple images in<br>
> one program memory space is nice for some scenarios. I like that too and<br>
> desire the option to deploy that way with multiple native threads per image<br>
> space in one program memory space.<br>
<br>
<br>
If you mean what I think you mean (fine grained shared state<br>
multi-threading) then I find this a pretty ironic message: "the<br>
multi-cores on upon us, we need to hurry up and adapt the method of<br>
concurrent program that absolutely wont work on 1k+ cores".<br>
<br>
The whole reason the "mega-cores" are interesting is that we have to<br>
*change how we program them*. Interesting how you are pointing out<br>
later in this thread about others "not getting it" while managing to<br>
miss this sky scraper size billboard.<br>
<br>
</blockquote></div><br><br>Smalltalk has the best concurrent programming potential I've seen in a programming language. The concurrent features are all there - blocks are easy to fork, semaphores are easy to use, and very nice concurrent abstractions can be built up using this powerful language. I can't see any reason that a Smalltalk VM won't run well on 1k+ cores with good concurrent algorithms.<br>
<br>I agree completely with Peter.<br><br>I'm not going to contribute to this flame war though as I'm not going to start work on a shared-state concurrent VM any time soon.<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>