d future or plans for d3

Andrew Wiley wiley.andrew.j at gmail.com
Sun Dec 18 09:01:50 PST 2011


On Sun, Dec 18, 2011 at 6:19 AM, Alex Rønne Petersen
<xtzgzorex at gmail.com> wrote:
> On 18-12-2011 12:45, Somedude wrote:
>>
>> Le 18/12/2011 12:13, Ruslan Mullakhmetov a écrit :
>>>
>>>  I do not want to make a flame over D vs C++11.
>>>
>>> ...
>>>  Once again, i'm not trying to make a holywar. I'm D lover myself. But a
>>> lot of people do not consider this benefits of D enough to shift to it
>>> as for my opinion and experience.
>>>
>>>
>>
>> These people will not change their mind whatever you throw at them. For
>> them, it's a matter of religion, not a matter of comparison. We
>> shouldn't bother pleasing such or such group of people.
>>
>> BTW, your comparison with Erlang misses one crucial point: performance.
>> A part for some very specific applications for which it is designed,
>> Erlang's general performance is simply not comparable to that of D. A
>> lot of D's complex set of features is geared towards increasing runtime
>> performance. Erlang just doesn't compare.
>
>
> On the other hand, Erlang's runtime is built around message-passing. I
> *extremely strongly doubt* that you can get similar performance out of
> message-passing in D, for two reasons:
>
> 1) The Erlang runtime is written in highly optimized C.
> 2) Erlang uses better garbage collection strategies than D.
>
> On point 1: Of course, you can write a message-passing implementation in D
> that's basically just glorified C, but that defeats the point of using D in
> the first place IMHO.
>
> On point 2: This is highly unlikely to change. It seems (from reading the
> NG's past discussions) that there is virtually no interest from the core
> devs of D to do The Right Thing to make precise garbage collection possible,
> sadly (and neither to make thread-local GC possible, and other such
> techniques (Erlang runs a separate GC per Erlang process, very
> successfully)).
>
> Yes, Erlang's emulator is not good in raw performance. It was never geared
> for this (that's why it has easy interfacing with C for
> performance-sensitive code). However, things like HiPE improve the
> situation.
>
> All languages have their place, and Erlang is still going strong in the
> world of massive concurrency. I doubt D will be able to challenge this until
> its GC issues have been resolved (and even then, D is nowhere near as
> convenient, lacking fault tolerance and location transparency; sometimes
> these traits are *much* more desirable than raw performance when dealing
> with concurrency on such high levels).
>

So I'm currently working on a message passing library in D that should
scale better than std.concurrency currently does, and I went ahead and
implemented this benchmark in it:
http://www.krazykoding.com/2011/07/scala-actor-v-erlang-genserver.html

Now, this benchmark doesn't really measure parallelism, but it does
measure message passing speed.
Some results:
Erlang (OTP): 7.253 seconds, 413,602.903 per sec
Erlang (receive):  5.486 seconds, 546,891.677 sec
My Library: 3.021 seconds, 993,048.659 per sec

Now, my library isn't complete enough for Github yet, and that will
probably get worse before it's completed, but it does show that D can
compete. This library supports closure-based actors (this benchmark
was run on them), which gets us to Erlang's level in terms of how many
actors can run.

The other thing D has going here is that unlike Scala (which is known
for its message passing implementations), we can statically guarantee
the safety of data passed between threads and avoid all heap
allocation if a message can be passed as a struct that isn't too
large.


More information about the Digitalmars-d mailing list