On Mon, Aug 04, 2014 at 02:53:07PM +0200, Levente Uzonyi wrote: > On Mon, 4 Aug 2014, Frank Shearar wrote: > > >On 4 August 2014 09:38, Cl??ment Bera <bera.clem...@gmail.com> wrote: > >> > >> > >> > >>2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymc...@me.com>: > >>> > >>>Hi guys, > >>> > >>>I have a script that runs very slow and does a lot of non dependent > >>>operation of a collection. I wander if I can speed it up by making it > >>>run in > >>>another process, because as far as I understand everything runs on a > >>>single > >>>thread, so I guess this won???t save me. > >>> > >>I don't think forking can speed up anything. > > > >But that's only because we're single-threaded, hence single-cored. If > >we had a VM that handle multiple threads (like if we resuscitated > >Andreas' and Igor's Hydra work), then forking _would_ speed things up. > >But that would raise another huge issue, namely the shared state > >nature of the image. > > Hydra works differently. It's basically running multiple images from a > single VM, and provides channels between images for communication (like in > Erlang). There's no shared state at all between images, and one image can > only use one core just like now. > It's also possible to use multiple cores by spawning new VMs. IIRC > OSProcess has some support for this. >
OSProcess + CommandShell does this in class RemoteTask. A RemoteTask spawns a VM with forked image, and uses Fuel to serialize the results back to the parent image/VM. But Pharo may be missing the necessary VM and plugin support, so I'm not sure if it works in Pharo now. But I have to say that this is unlikely to useful as a performance enhancement except in very specialized cases where large chunks of work can be run in completely independent parallel tasks. Dave
