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 <[email protected]> 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. >
