Maybe a 'pack' of Seasides is the wrong collective. A 'shoreline' of Seasides? A 'coast'?
On 19 November 2015 at 15:22, EuanM <[email protected]> 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 <[email protected]> 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 <[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. >>> > >>> >>
