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
