Wait, if your computations make use of I/O, wouldn't *forking* allow to take advantage when a green thread is blocked for example, writing a socket? :)
On Mon, Aug 4, 2014 at 2:53 PM, Levente Uzonyi <[email protected]> wrote: > On Mon, 4 Aug 2014, Frank Shearar wrote: > > On 4 August 2014 09:38, Clément Bera <[email protected]> wrote: >> >>> >>> >>> >>> 2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <[email protected]>: >>> >>>> >>>> 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. > > > Levente > > > >> So perhaps forking _would_ help if your computations were big enough >> to justify the cost of spinning up a clone image, like David Lewis' >> recent work. >> >> frank >> >> Usually the best solution is to profile your operation with the Profiler, >>> then implement differently costly operations, either by removing >>> object/block creations in smalltalk if this is possible, else by >>> implementing costly operations in C and bind them like that: >>> http://clementbera.wordpress.com/2013/06/19/optimizing- >>> pharo-to-c-speed-with-nativeboost-ffi/ >>> >>> >>> >>> >>> >>>> Uko >>>> >>> >>> >>> >>
