[Vm-dev] Ideas on cheap multi-threading for Squeak / Pharo ? (from Tim's article)

[Ben Coman]

On Tue, Jan 31, 2017 at 4:19 AM, Clément Bera <bera.clement at gmail.com>
wrote:

>
> Hi all,
>
> Tim's just shared this lovely article with a 10,000+ core ARM machine.
> With this kind of machines, it's a bit stupid to use only 1 core when you
> have 10,000+. I believe we have to find a way to introduce multi-threading
> in Squeak / Pharo. For co-processors like the Xeon Phi or the graphic
> cards, I guess it's ok not to use them because their not general purpose
> processors while the VM is general purpose, but all those 10,000 cores...
>
> For parallel programming, we could consider doing something cheap like the
> parallel C# loops (Parallel.for and co). The Smalltalk programmer would
> then explicitly write "collection parallelDo: aBlock" instead of
> "collection do: aBlock", and if the block is long enough to execute, the
> cost of parallelisation becomes negligible compared to the performance
> boost of parallelisation. The block has to perform independent tasks, and
> if multiple blocks executed in parallel read/write the same memory
> location, as in C#, the behavior is undefined leading to freezes / crashes.
> It's the responsibility of the programmer to find out if loop iterations
> are independent or not (and it's not obvious).
>
> For concurrent programming, there's this design from E where we could have
> an actor model in Smalltalk where each actor is completely independent from
> each other, one native thread per actor, and all the common objects
> (including what's necessary for look-up such as method dictionaries) could
> be shared as long as they're read-only or immutable. Mutating a shared
> object such as installing a method in a method dictionary would be detected
> because such objects are read-only and we can stop all the threads sharing
> such object to mutate it. The programmer has to keep uncommon the mutation
> of shared objects to have good performance.
>
> Both design have different goals using multiple cores (parallel and
> concurrent programming), but in both cases we don't need to rewrite any
> library to make Squeak / Pharo multi-threaded like they did in Java.
>
> What do you think ?
>
> Is there anybody on the mailing list having ideas on how to introduce
> threads in Squeak / Pharo in a cheap way that does not require rewriting
> all core/collection libraries ?
>
> I'm not really into multi-threading myself but I believe the Cog VM will
> die in 10 years from now if we don't add something to support
> multi-threading, so I would like to hear suggestions.
>
>
Just came across [1] about PyParallel which advocates,
at the point that a parallel computation is invoked...
1. Suspend the main thread
2. Just prior to suspension, write-protect all pages of main thread
3. After the parallel contexts/threads have finished, return the protection
to normal and resume main thread

Those slide also mention somewhere that each computational thread gets its
own heap,
and rather than garbage collect those heaps they just thrown them away.  I
guess one way that could work
is for each computation thread to return a single object, and copy anything
reached from that to the main heap
and throw the rest away.

[1]
https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=139


cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170315/02df073b/attachment.html>