December 18, 2011
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).

- Alex
December 18, 2011
As far as I understand Erlang performance is reached by horizontal scheduling (i'm not sure i used exact word) by which i mean that if you have lack of performance you can buy new hardware nodes (servers) and without any changes in code and even recompiling you can distribute workload.

That is very good approach in situation when processor stopped getting faster but become more parallelized and cheaper.

GC is just a mater of implementation. In presence of resources implement good GC algorithm offers no difficulty.

> All languages have their place

sure. and many people doubt of place of D. It would be nice if such good lang will find it's place.

On 2011-12-18 12:19:43 +0000, Alex Rønne Petersen said:

> 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).
> 
> - Alex


-- 
BR, Ruslan Mullakhmetov

December 18, 2011
Le 18/12/2011 13:19, Alex Rønne Petersen a écrit :
> 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

As I said inmy previous post, the kind of performance that Erlang has is useful for specific applications, but not really for a general purpose language. For instance, it's very well suited for writing the server side software of a MMORPG like World of Warcraft, but it's pretty much useless for writing the client.
December 18, 2011
Le 18/12/2011 15:07, Ruslan Mullakhmetov a écrit :
> 
> GC is just a mater of implementation. In presence of resources implement good GC algorithm offers no difficulty.
> 

Oh really ? Then please make us a favor and write one for D. Also I'm sure the C++ guys will be pleased to hear that it's such an easy task.
December 18, 2011
Am 18.12.2011, 01:09 Uhr, schrieb Ruslan Mullakhmetov <tiabaldu@gmail.com>:

> Hi all,
>
>   I want to ask you about D future, i mean next big iteration of D and propose some new feature, agent-based programming. Currently, after introducing C++11 i see the only advantages of D over C++11 except syntax sugare is  garbage collector and modules.

Sorry, but you clearly haven't used D for anything serious.
You still have plenty of things like static if, compile-time reflection and CTFE which is basically _impossible_ in C++.
And even if you consider C++11, it's just awful compared to D. I constantly wonder why they had to invent such a horrible syntax. That has nothing to do with syntax sugar. D just got it straight.
December 18, 2011
Am 18.12.2011, 11:51 Uhr, schrieb Ruslan Mullakhmetov <tiabaldu@gmail.com>:

> On 2011-12-18 00:56:33 +0000, Timon Gehr said:
>
>> C++11 does not change the relation between D and C++ a lot. Why do you think it does?
>
> Because it incorporates many features D declared to be unique to it over C++ like
>    - thread local variables
Not a C++11 invention. We've had that for years with __thread.
D turned things around by making thread-local the default!

>    - type deduction
C++ auto isn't as powerful as D's.

>    - generalized constant expressions
That's really ludicrous. You have to mark functions manually while the compiler could do that much better. CTFE ftw.
December 18, 2011
On Sun, Dec 18, 2011 at 6:19 AM, Alex Rønne Petersen <xtzgzorex@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.
December 18, 2011
On 12/18/11 6:19 AM, Alex Rønne Petersen 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.

I'm not so sure. That seems to presuppose that use of any non-C features of D exacts a performance overhead, something I'd disagree with.

> 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)).

Walter and I are both interested in making the GC precise.

> 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.

That may be the case, perhaps outside Ericsson. I know a few people at Ericsson, and according to them the use of Erlang there is waning. No new projects are started in Erlang and some production software is rewritten in C++.

> 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).

We need to improve the GC, that's a given. Then the question remains whether fault tolerance and location transparency are language features or library/environment/deployment attributes.


Andrei
December 18, 2011
Yet, most high performance network elements from Ericson are running Erlang. Able to process millions of phone calls per second.

What is D doing in real world?

This is the type of questions the community has to provide to naysayers.

--
Paulo

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.

December 18, 2011
On Sunday, 18 December 2011 at 17:19:33 UTC, Andrei Alexandrescu wrote:
> On 12/18/11 6:19 AM, Alex Rønne Petersen 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.

<snip>

> Walter and I are both interested in making the GC precise.

Wouldn't support for precise GC collection mean larger executable because type information is needed at runtime for precise collection?

If so, could extra info be used to improve runtime reflection as well?

/Jonas