On May 7, 2011, at 2:49 AM, Stefan Marr wrote: > > On 07 May 2011, at 02:06, Igor Stasenko wrote: > >> On 6 May 2011 23:45, Stefan Marr <[email protected]> wrote: >>> There is nothing fundamental in the RoarVM that is changing the language >>> semantics of Smalltalk. >>> >>> It is just that for: `[do something] fork` you will have to assume that it >>> is executed in parallel to other code. >>> >> only that? >> Heh.. then we're 99% done. Except that this last 1% is still could >> take years to complete :) > > But why? We show with the Squeak 3.x MVC image that it is perfectly possible. > (the change set is absolutely minimal, and the only thing we needed to fix > was some Delay related issues)
when and where did you announce that? Where is the code? > > And, on top of that it is perfectly possible, there is a smooth transition > path. > You can tell all your Process objects to just run on the main core in the > beginning, and then just use the other cores for code you wrote specifically. > > Thus, there is a nice step-wise path. And I think I outlined that in my 20min > presentation at the school after Stef asked. > BTW: are those videos somewhere accessible? > > From my perspective all it takes is someone who actually cares, and has the > time to experiment a bit with parallel programming. > > The kernel, and the tools can be migrated step by step. > > However, that is just on top of the current RoarVM, which is certainly not as > attractive as a CogVM with real thread support. > >> I can tell you more: there is no business cases for VM(s) which can do >> manycore :) > No manycore perhaps, but luckily the low-power end is pushing to multicore > solutions. > So, your next iPhone and Android app will need to leverage at least two cores > for optimal performance, and even quad-core phones are just around the corner. > > >> Implementing VM which enabling massive parallelism is just a >> beginning. Then obviously you need do to a lot at language side >> to leverage that, in order to really say "yes, our system(s) are aware >> of multicore and can scale almost linearly in future". > No, don't think so. If people got deadlines and a need, they will do it with > the tools at hand. > And what I am doing here is absolutely not rocket science. Actually it is > pretty hard to sell the engineering we do as science at all. Because the > multicore VM problem has been solved a decade ago. They just forgot to tell > us how... > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >
