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

[Chris Cunningham]

Another option mentioned occassionally:
http://stefan-marr.de/renaissance/#get-started
(roarvm - mutli-core (research) vm for squeak, tested on 'up to 59 cores').

-cbc

On Mon, Jan 30, 2017 at 12:19 PM, 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.
>
> Best,
>
> Clement
>
> Phd Student
> Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170130/db17c6c9/attachment.html>