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