Opportunities for D

[Sean Kelly via Digitalmars-d]

On Thursday, 10 July 2014 at 06:32:32 UTC, logicchains wrote:
> On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu 
> wrote:
>> We already have actor-style via std.concurrency. We also have 
>> fork-join parallelism via std.parallel. What we need is a 
>> library for CSP.
>
> The actor-style via std.concurrency is only between 
> 'heavyweight' threads though, no? Even if lightweight threads 
> may be overhyped, part of the appeal of Go and Erlang is that 
> one can spawn tens of thousands of threads and it 'just works'. 
> It allows the server model of 'one green thread/actor per 
> client', which has a certain appeal in its simplicity. Akka 
> similarly uses its own lightweight threads, not heavyweight JVM 
> threads.

No.  I've had an outstanding pull request to fix this for quite a 
while now.  I think there's a decent chance it will be in the 
next release.  To be fair, that pull request mostly provides the 
infrastructure for changing how concurrency is handled.  A 
fiber-based scheduler backed by a thread pool doesn't exist yet, 
though it shouldn't be hard to write (the big missing piece is 
having a dynamic thread pool).  I was going to try and knock one 
out while on the airplane in a few days.


> Message passing between lightweight threads can also be much 
> faster than message passing between heavyweight threads; take a 
> look at the following message-passing benchmark and compare 
> Haskell, Go and Erlang to the languages using OS threads: 
> http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=threadring

Thanks for the benchmark.  I didn't have a good reference for 
what kind of performance capabilities to hit, so there are a few 
possible optimizations I've left out of std.concurrency because 
they didn't buy much in my own testing (like a free list of 
message objects).  I may have to revisit those ideas with this 
benchmark in mind and see what happens.