> Maybe a 'pack' of Seasides is the wrong collective.
> A 'shoreline' of Seasides? A 'coast'?
An archipelago.
-C
--
Craig Latta
netjam.org
+31 6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)
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
Maybe a 'pack' of Seasides is the wrong collective.
A 'shoreline' of Seasides? A 'coast'?
On 19 November 2015 at 15:22, EuanM 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
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 pyt
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
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 con
If you are on Linux, there is a add-on package for OSProcess called
CommandShell which includes a class called RemoteTask. It lets you
fork a block of code to a separate OS thread and return the result to
the calling image via serialization (Fuel or other).
IIUC, it takes advantage of Linux memo
Searching with the right keywords should have directed you to HydraVM[1]
and RoarVM[2][3], which are two different approaches to this problem.
Both projects are stalled, and would require significant effort to merge
them with the current VM sources.
RoarVM also requires images changes, because it
(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 increase
