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.
