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?
>
>

> (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-core-PCs-tp4861824p4861852.html
> 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 <[hidden email]> 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 <[hidden email]>
>> 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-core-PCs-tp4861824p4861852.html
>> > 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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-core-PCs-tp4861824p4861852.html
>>> > Sent from the Pharo Smalltalk Developers mailing list archive at
>>> > Nabble.com.
>>> >
>>>
>>