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. Uko
2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@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.
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...
Uko
On 4 August 2014 09:38, Clément Bera <bera.clement@gmail.com> wrote:
2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@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. 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...
Uko
On Mon, 4 Aug 2014, Frank Shearar wrote:
On 4 August 2014 09:38, Clément Bera <bera.clement@gmail.com> wrote:
2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@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. 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...
Uko
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 <leves@elte.hu> wrote:
On Mon, 4 Aug 2014, Frank Shearar wrote:
On 4 August 2014 09:38, Clément Bera <bera.clement@gmail.com> wrote:
2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@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.
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
yes thats correct. I am using python threads , (they are green threads too like pharo) to make my blocking socket not block the overall execution of code. Dont need fork on the pharo side because I send the message and I expect an immediate reply so the blocking is too short for the user to notice. I was giving OSProcess a try using the fork methods for thisProcess but it looks like it requires an XDisplayControlPlugin , which is weird that it does not just bass the block as argument to the new instance of pharo. of course it can be done already with command: method and passing any code you want to run to the new pharo instance together with a message to close image . it will return an object with the variable runState to #running while your code in the pharo instance runs and then #complete as soon as it finishes to take advantage of multiple cores and true concurency. On Mon, Aug 4, 2014 at 4:46 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
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 <leves@elte.hu> wrote:
On Mon, 4 Aug 2014, Frank Shearar wrote:
On 4 August 2014 09:38, Clément Bera <bera.clement@gmail.com> wrote:
2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@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.
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
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.clement@gmail.com> wrote:
2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@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
On 04 Aug 2014, at 10:38, Clément Bera <bera.clement@gmail.com> wrote:
2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@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.
Thanks, I know about this, The problem is exactly that Iâm wrapping whole hierarchies in my own objects because I need that. Anyway thank you! Uko
I don't think forking can speed up anything.
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...
Uko
Thanks, I know about this, The problem is exactly that Iâm wrapping whole hierarchies in my own objects because I need that. Anyway thank you!
explain us what you are doing because sometimes we know tricks :). I think that often people that forking can solve speed but you have to introduce sync points and there it can be gory. Stef
threads generally slow things down. Pharo uses green threads so it does not take advantage of multiple cores. You can take advantage of multiple cores by having multiple instances of the Pharo executable running and have them communicate via sockets, pipes , shared memory etc. Some calculations / processing can also benefit from GPU acceleration , if you feel really adventurous, GPUs dont only offer concurrent coding but also speed boost compared to cpu can be anything between 8x to 100x times. Of course far less straightforward than a simple fork and it wont benefit any case scenario. On Mon, Aug 4, 2014 at 11:17 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
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.
Uko
Hi Yuriy, My advice is to use OpenCL. OpenCL is a standard to use the graphical card to carry out massive computation. The good news is that Ronie has worked on a binding between OpenCL and Pharo. I am using it and it works pretty well. http://smalltalkhub.com/#!/~ronsaldo/OpenCL Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Aug 4, 2014, at 4:17 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
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.
Uko
On 4/8/14 19:46, Alexandre Bergel wrote:
Hi Yuriy,
My advice is to use OpenCL. OpenCL is a standard to use the graphical card to carry out massive computation. The good news is that Ronie has worked on a binding between OpenCL and Pharo. I am using it and it works pretty well. http://smalltalkhub.com/#!/~ronsaldo/OpenCL
Alex first a good algorithm with a controlled complexity is important. If you have a naive algorithm you can wait that the Universe die before getting a result. I remember doing stupid algorithm that we speed up with roel from a couple of hours to 20 s. Second OpenCL binds you to system having openCL support and this is important to understand it. Stef
Cheers, Alexandre
http://stackoverflow.com/questions/5919172/gpgpu-vs-multicore The answer is really nice.. over GPU/ multithreaded CPU et als. GPU is not a panacea for enterprise programming, but for specific parallel unbranched-no synchronization driven algorithms * The worst code for GPU is code with less parallelism or code with lots of branches or synchronization. * Easily vectorizable code: CPU is easier to code but low performance. GPU is slightly harder to code but provides big bang for the buck. For all others, CPU is easier and often better performance as well. * GPUs don't support interrupts and exception. On Tue, Aug 5, 2014 at 1:00 AM, stepharo <stepharo@free.fr> wrote:
On 4/8/14 19:46, Alexandre Bergel wrote:
Hi Yuriy,
My advice is to use OpenCL. OpenCL is a standard to use the graphical card to carry out massive computation. The good news is that Ronie has worked on a binding between OpenCL and Pharo. I am using it and it works pretty well. http://smalltalkhub.com/#!/~ronsaldo/OpenCL
Alex
first a good algorithm with a controlled complexity is important. If you have a naive algorithm you can wait that the Universe die before getting a result. I remember doing stupid algorithm that we speed up with roel from a couple of hours to 20 s.
Second OpenCL binds you to system having openCL support and this is important to understand it.
Stef
Cheers, Alexandre
Hi Do you try TaskIt framework? It has BlockClosure>>forkIt which transparently executes code in separate image. 2014-08-04 12:17 GMT+04:00 Yuriy Tymchuk <yuriy.tymchuk@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.
Uko
participants (11)
-
Alexandre Bergel -
Clément Bera -
David T. Lewis -
Denis Kudriashov -
Frank Shearar -
Guillermo Polito -
kilon alios -
Levente Uzonyi -
S Krish -
stepharo -
Yuriy Tymchuk