Preparing for the (already here) future world of multi-core PCs
(And yes, I know it's actually here already). Now that clock-speed rises have stalled, basically forever, desktop and laptop PCs are growing ever-increasing numbers of cores in their CPU chips, Is there design and conceptualisations work going on to see how Pharo will deal with providing increased access to the additional processing power? One thing I have been thinking about is a set of co-operating Pharo VMs. But given memory and storage are shared, this may not provide as large a benefit as we'd like. Or moving Pharo into being having multiple native-threads, and taking Pharo into a concurrency route. Or - whatever it is I am too ignorant to see. This all strikes me (like the way Smalltalk is extending its system boundary out onto the web with Monticello, Pharo is extending that via the Configuration Browser and Versionner) as a way Pharo could build on Smalltalk, while becoming its own thing. (as opposed to being a Smalltalk with a very big set of classes). Is there thought work going on in this area yet? DabbleDB had a system of running multiple VMs on a server, and hot-swapping them in and out depending on their CPU loading. Did that ever get developed intop a more generally-useful facility?
Searching with the right keywords should have directed you to HydraVM[1] and RoarVM[2][3], which are two different approaches to this problem. Both projects are stalled, and would require significant effort to merge them with the current VM sources. RoarVM also requires images changes, because it brings the concurrency problems up to the Smalltalk level. There are plans for Spur to have some kind of support for multi-core machines, though that'll be different than what you described, because Smalltalk code will still be executed by one core at a time. Levente [1] http://forum.world.st/ANN-Hydra-VM-A-multi-core-capable-Croquet-VM-td106298.... [2] http://stefan-marr.de/2010/11/roarvm-the-manycore-squeakvm/ [3] https://github.com/smarr/RoarVM On Wed, 18 Nov 2015, EuanM wrote:
(And yes, I know it's actually here already).
Now that clock-speed rises have stalled, basically forever, desktop and laptop PCs are growing ever-increasing numbers of cores in their CPU chips,
Is there design and conceptualisations work going on to see how Pharo will deal with providing increased access to the additional processing power?
One thing I have been thinking about is a set of co-operating Pharo VMs.
But given memory and storage are shared, this may not provide as large a benefit as we'd like.
Or moving Pharo into being having multiple native-threads, and taking Pharo into a concurrency route.
Or - whatever it is I am too ignorant to see.
This all strikes me (like the way Smalltalk is extending its system boundary out onto the web with Monticello, Pharo is extending that via the Configuration Browser and Versionner) as a way Pharo could build on Smalltalk, while becoming its own thing. (as opposed to being a Smalltalk with a very big set of classes).
Is there thought work going on in this area yet?
DabbleDB had a system of running multiple VMs on a server, and hot-swapping them in and out depending on their CPU loading.
Did that ever get developed intop a more generally-useful facility?
If you are on Linux, there is a add-on package for OSProcess called CommandShell which includes a class called RemoteTask. It lets you fork a block of code to a separate OS thread and return the result to the calling image via serialization (Fuel or other). IIUC, it takes advantage of Linux memory copy-on-write sharing, so the forking overhead should be proportional to the amount of work done (e.g., memory changes). On Wed, Nov 18, 2015 at 3:56 PM, EuanM <euanmee@gmail.com> wrote:
(And yes, I know it's actually here already).
Now that clock-speed rises have stalled, basically forever, desktop and laptop PCs are growing ever-increasing numbers of cores in their CPU chips,
Is there design and conceptualisations work going on to see how Pharo will deal with providing increased access to the additional processing power?
One thing I have been thinking about is a set of co-operating Pharo VMs.
But given memory and storage are shared, this may not provide as large a benefit as we'd like.
Or moving Pharo into being having multiple native-threads, and taking Pharo into a concurrency route.
Or - whatever it is I am too ignorant to see.
This all strikes me (like the way Smalltalk is extending its system boundary out onto the web with Monticello, Pharo is extending that via the Configuration Browser and Versionner) as a way Pharo could build on Smalltalk, while becoming its own thing. (as opposed to being a Smalltalk with a very big set of classes).
Is there thought work going on in this area yet?
DabbleDB had a system of running multiple VMs on a server, and hot-swapping them in and out depending on their CPU loading.
Did that ever get developed intop a more generally-useful facility?
This is no small issue, nor a single one. Be careful to distinguish concurrency from parallelism. See Rob Pike's talk/slides on this. Note that many systems can benefit from a concurrent design--even on a single core, where no parallel execution is possible--because the problem is inherently concurrent; note how effectively shared-nothing approaches with Erlang, Go, or Scala/Akka have been used in such domains. In other domains, parallelism--especially nested data parallelism--is more important than concurrency (see http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html). The Haskell and other communities have been exploring this with shared memory approaches like STM. So, to better use the slowing but increasing number of cores in today's hardware, we need to understand the many very different use cases and approaches. The lowest-hanging fruit in the Pharo/Squeak world might be to rework the vm and process scheduler to support massive numbers of lighter weight processes similar to Erlang. Check out Andrew Blacks "Erlang in Pharo", http://www.squeaksource.com/Erlang.html. Best, Mike -- View this message in context: http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-c... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I agree that parallelism and concurrency are different things. For easy parallelism : - a multi-VM version of something like PharoLauncher. - tools for tailor each VM + Image - tools to manage and track each running VM + Image. - tolls to try to mak sure that different running VMs and images have their own core, and that VMs can be closed down so that VMs never are sharing (unless you want them to) All we need to do is make sure that the VM and image don't have baked-in assumptions about being the only VM on the physical machine baked in to each VM and the Smalltalk above it.) The task for the end-user app developers then becomes seeing what bundles of functionality are sufficiently decoupled from the others that they can be set adrift in their own VM. (I'm even starting to think of reinventing the multi-user server. A single 16 core PC, with 16 4-core Raspberry Pis connected, and each RPi's user taking control of a single app on a single VM single core on the PC). (Then you could have a quite a decent network for $140 per workstation (PiCEED + keyboard + mouse) , and one fast laptop as the central server Cheap, and easy to transport to remote locations. (But I digress) Concurrency is a deeper and harder problem for a Smalltalk, I agree. On 18 November 2015 at 23:36, Michael J. Forster <mike@sharedlogic.ca> wrote:
This is no small issue, nor a single one.
Be careful to distinguish concurrency from parallelism. See Rob Pike's talk/slides on this.
Note that many systems can benefit from a concurrent design--even on a single core, where no parallel execution is possible--because the problem is inherently concurrent; note how effectively shared-nothing approaches with Erlang, Go, or Scala/Akka have been used in such domains.
In other domains, parallelism--especially nested data parallelism--is more important than concurrency (see http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html). The Haskell and other communities have been exploring this with shared memory approaches like STM.
So, to better use the slowing but increasing number of cores in today's hardware, we need to understand the many very different use cases and approaches. The lowest-hanging fruit in the Pharo/Squeak world might be to rework the vm and process scheduler to support massive numbers of lighter weight processes similar to Erlang. Check out Andrew Blacks "Erlang in Pharo", http://www.squeaksource.com/Erlang.html.
Best,
Mike
-- View this message in context: http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-c... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Now days the real CPU is the GPU. Most of the acceleration and parrarel computing happens in there. Eventhough my fellow pharo collogues are mostly purists that prefer everything implemented in Pharo I am a parasitist preffering to leach off any technology I can find, my favourite choice being python. Its possible to use my socket bridge to bridge pharo with python in a few dozen lines of code to access to 2 python libraries, multiprocessing and foremost PyCuda so you can both take advantage the multiple cores of a CPU and an GPU though GPU should be your prime focus if you want considerably speed ups to your code. So none stops a pharoers making code that runs on multiple CPU and GPUs , all it takes is a bit of imagination and an open mind. Sometimes the quickest way to reach a goal is not a straight line . The truth however is even I that works with 3d graphics I find myself barely needing 1 CPU core, so you need to first make sure that you need such a feature before implementing it. On Thu, Nov 19, 2015 at 4:19 AM EuanM <euanmee@gmail.com> wrote:
I agree that parallelism and concurrency are different things.
For easy parallelism : - a multi-VM version of something like PharoLauncher. - tools for tailor each VM + Image - tools to manage and track each running VM + Image. - tolls to try to mak sure that different running VMs and images have their own core, and that VMs can be closed down so that VMs never are sharing (unless you want them to)
All we need to do is make sure that the VM and image don't have baked-in assumptions about being the only VM on the physical machine baked in to each VM and the Smalltalk above it.)
The task for the end-user app developers then becomes seeing what bundles of functionality are sufficiently decoupled from the others that they can be set adrift in their own VM.
(I'm even starting to think of reinventing the multi-user server. A single 16 core PC, with 16 4-core Raspberry Pis connected, and each RPi's user taking control of a single app on a single VM single core on the PC).
(Then you could have a quite a decent network for $140 per workstation (PiCEED + keyboard + mouse) , and one fast laptop as the central server Cheap, and easy to transport to remote locations. (But I digress)
Concurrency is a deeper and harder problem for a Smalltalk, I agree.
On 18 November 2015 at 23:36, Michael J. Forster <mike@sharedlogic.ca> wrote:
This is no small issue, nor a single one.
Be careful to distinguish concurrency from parallelism. See Rob Pike's talk/slides on this.
Note that many systems can benefit from a concurrent design--even on a single core, where no parallel execution is possible--because the problem is inherently concurrent; note how effectively shared-nothing approaches with Erlang, Go, or Scala/Akka have been used in such domains.
In other domains, parallelism--especially nested data parallelism--is more important than concurrency (see
http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html ).
The Haskell and other communities have been exploring this with shared memory approaches like STM.
So, to better use the slowing but increasing number of cores in today's hardware, we need to understand the many very different use cases and approaches. The lowest-hanging fruit in the Pharo/Squeak world might be to rework the vm and process scheduler to support massive numbers of lighter weight processes similar to Erlang. Check out Andrew Blacks "Erlang in Pharo", http://www.squeaksource.com/Erlang.html.
Best,
Mike
-- View this message in context: http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-c... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
There are also uses that don't involve the GPU - any headless server use, e.g. running a pack of headless Seasides. Ways to deal with the machine becoming IO bound is definitely one of the key issues. I'm not saying anything is preventing it - I'm saying that one of the key enablers are tools to support it. On 19 November 2015 at 12:58, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Now days the real CPU is the GPU. Most of the acceleration and parrarel computing happens in there.
Eventhough my fellow pharo collogues are mostly purists that prefer everything implemented in Pharo I am a parasitist preffering to leach off any technology I can find, my favourite choice being python. Its possible to use my socket bridge to bridge pharo with python in a few dozen lines of code to access to 2 python libraries, multiprocessing and foremost PyCuda so you can both take advantage the multiple cores of a CPU and an GPU though GPU should be your prime focus if you want considerably speed ups to your code.
So none stops a pharoers making code that runs on multiple CPU and GPUs , all it takes is a bit of imagination and an open mind. Sometimes the quickest way to reach a goal is not a straight line .
The truth however is even I that works with 3d graphics I find myself barely needing 1 CPU core, so you need to first make sure that you need such a feature before implementing it.
On Thu, Nov 19, 2015 at 4:19 AM EuanM <euanmee@gmail.com> wrote:
I agree that parallelism and concurrency are different things.
For easy parallelism : - a multi-VM version of something like PharoLauncher. - tools for tailor each VM + Image - tools to manage and track each running VM + Image. - tolls to try to mak sure that different running VMs and images have their own core, and that VMs can be closed down so that VMs never are sharing (unless you want them to)
All we need to do is make sure that the VM and image don't have baked-in assumptions about being the only VM on the physical machine baked in to each VM and the Smalltalk above it.)
The task for the end-user app developers then becomes seeing what bundles of functionality are sufficiently decoupled from the others that they can be set adrift in their own VM.
(I'm even starting to think of reinventing the multi-user server. A single 16 core PC, with 16 4-core Raspberry Pis connected, and each RPi's user taking control of a single app on a single VM single core on the PC).
(Then you could have a quite a decent network for $140 per workstation (PiCEED + keyboard + mouse) , and one fast laptop as the central server Cheap, and easy to transport to remote locations. (But I digress)
Concurrency is a deeper and harder problem for a Smalltalk, I agree.
On 18 November 2015 at 23:36, Michael J. Forster <mike@sharedlogic.ca> wrote:
This is no small issue, nor a single one.
Be careful to distinguish concurrency from parallelism. See Rob Pike's talk/slides on this.
Note that many systems can benefit from a concurrent design--even on a single core, where no parallel execution is possible--because the problem is inherently concurrent; note how effectively shared-nothing approaches with Erlang, Go, or Scala/Akka have been used in such domains.
In other domains, parallelism--especially nested data parallelism--is more important than concurrency (see
http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html). The Haskell and other communities have been exploring this with shared memory approaches like STM.
So, to better use the slowing but increasing number of cores in today's hardware, we need to understand the many very different use cases and approaches. The lowest-hanging fruit in the Pharo/Squeak world might be to rework the vm and process scheduler to support massive numbers of lighter weight processes similar to Erlang. Check out Andrew Blacks "Erlang in Pharo", http://www.squeaksource.com/Erlang.html.
Best,
Mike
-- View this message in context: http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-c... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Maybe a 'pack' of Seasides is the wrong collective. A 'shoreline' of Seasides? A 'coast'? On 19 November 2015 at 15:22, EuanM <euanmee@gmail.com> wrote:
There are also uses that don't involve the GPU - any headless server use, e.g. running a pack of headless Seasides.
Ways to deal with the machine becoming IO bound is definitely one of the key issues.
I'm not saying anything is preventing it - I'm saying that one of the key enablers are tools to support it.
On 19 November 2015 at 12:58, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Now days the real CPU is the GPU. Most of the acceleration and parrarel computing happens in there.
Eventhough my fellow pharo collogues are mostly purists that prefer everything implemented in Pharo I am a parasitist preffering to leach off any technology I can find, my favourite choice being python. Its possible to use my socket bridge to bridge pharo with python in a few dozen lines of code to access to 2 python libraries, multiprocessing and foremost PyCuda so you can both take advantage the multiple cores of a CPU and an GPU though GPU should be your prime focus if you want considerably speed ups to your code.
So none stops a pharoers making code that runs on multiple CPU and GPUs , all it takes is a bit of imagination and an open mind. Sometimes the quickest way to reach a goal is not a straight line .
The truth however is even I that works with 3d graphics I find myself barely needing 1 CPU core, so you need to first make sure that you need such a feature before implementing it.
On Thu, Nov 19, 2015 at 4:19 AM EuanM <euanmee@gmail.com> wrote:
I agree that parallelism and concurrency are different things.
For easy parallelism : - a multi-VM version of something like PharoLauncher. - tools for tailor each VM + Image - tools to manage and track each running VM + Image. - tolls to try to mak sure that different running VMs and images have their own core, and that VMs can be closed down so that VMs never are sharing (unless you want them to)
All we need to do is make sure that the VM and image don't have baked-in assumptions about being the only VM on the physical machine baked in to each VM and the Smalltalk above it.)
The task for the end-user app developers then becomes seeing what bundles of functionality are sufficiently decoupled from the others that they can be set adrift in their own VM.
(I'm even starting to think of reinventing the multi-user server. A single 16 core PC, with 16 4-core Raspberry Pis connected, and each RPi's user taking control of a single app on a single VM single core on the PC).
(Then you could have a quite a decent network for $140 per workstation (PiCEED + keyboard + mouse) , and one fast laptop as the central server Cheap, and easy to transport to remote locations. (But I digress)
Concurrency is a deeper and harder problem for a Smalltalk, I agree.
On 18 November 2015 at 23:36, Michael J. Forster <mike@sharedlogic.ca> wrote:
This is no small issue, nor a single one.
Be careful to distinguish concurrency from parallelism. See Rob Pike's talk/slides on this.
Note that many systems can benefit from a concurrent design--even on a single core, where no parallel execution is possible--because the problem is inherently concurrent; note how effectively shared-nothing approaches with Erlang, Go, or Scala/Akka have been used in such domains.
In other domains, parallelism--especially nested data parallelism--is more important than concurrency (see
http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html). The Haskell and other communities have been exploring this with shared memory approaches like STM.
So, to better use the slowing but increasing number of cores in today's hardware, we need to understand the many very different use cases and approaches. The lowest-hanging fruit in the Pharo/Squeak world might be to rework the vm and process scheduler to support massive numbers of lighter weight processes similar to Erlang. Check out Andrew Blacks "Erlang in Pharo", http://www.squeaksource.com/Erlang.html.
Best,
Mike
-- View this message in context: http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-c... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (6)
-
Chris Muller -
Craig Latta -
Dimitris Chloupis -
EuanM -
Levente Uzonyi -
Michael J. Forster