www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why did D leave the programming language shootout and will it return?

reply Chris Dew <cmsdew gmail.com> writes:
I've found some links which show that D used to be in the
programming language shootout http://shootout.alioth.debian.org/

Why did it disappear from there and can we put it back?

It is a great sanity check for a new user to be able to see that a
language and its implementation aren't a dog.

I *expect* that D's performance is similar to C/C++ when used in the
same fashion (i.e. functions and structs, rather than classes and
delegates).  I would like to be able to confirm this.

Thanks,

Chris.
Sep 20 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 20 Sep 2011 15:44:33 -0400, Chris Dew <cmsdew gmail.com> wrote:


 I've found some links which show that D used to be in the
 programming language shootout http://shootout.alioth.debian.org/

 Why did it disappear from there and can we put it back?

 It is a great sanity check for a new user to be able to see that a
 language and its implementation aren't a dog.

 I *expect* that D's performance is similar to C/C++ when used in the
 same fashion (i.e. functions and structs, rather than classes and
 delegates).  I would like to be able to confirm this.


The maintainer of that site has discussed why D is no longer included on  
the D newsgroup:

http://www.digitalmars.com/d/archives/digitalmars/D/The_Computer_Languages_Shootout_Game_120841.html
http://www.digitalmars.com/d/archives/digitalmars/D/Re_The_Computer_Languages_Shootout_Game_120847.html
http://www.digitalmars.com/d/archives/digitalmars/D/Re_The_Computer_Languages_Shootout_Game_120849.html

And various other responses.  The conversation happened on Nov-1-2010, so  
you can search the archives for it.

-Steve
Sep 20 2011
parent reply Chris Dew <cmsdew gmail.com> writes:
Does this just boil down to them not wanting to include D and it's their si=
te?

(Yet they include ATS and Go.)

Regards,

Chris.

On 20 September 2011 21:04, Steven Schveighoffer <schveiguy yahoo.com> wrot=
e:

 On Tue, 20 Sep 2011 15:44:33 -0400, Chris Dew <cmsdew gmail.com> wrote:


 I've found some links which show that D used to be in the
 programming language shootout http://shootout.alioth.debian.org/

 Why did it disappear from there and can we put it back?

 It is a great sanity check for a new user to be able to see that a
 language and its implementation aren't a dog.

 I *expect* that D's performance is similar to C/C++ when used in the
 same fashion (i.e. functions and structs, rather than classes and
 delegates). =C2=A0I would like to be able to confirm this.


 The maintainer of that site has discussed why D is no longer included on =


the

 D newsgroup:

 http://www.digitalmars.com/d/archives/digitalmars/D/The_Computer_Language=


s_Shootout_Game_120841.html

 http://www.digitalmars.com/d/archives/digitalmars/D/Re_The_Computer_Langu=


ages_Shootout_Game_120847.html

 http://www.digitalmars.com/d/archives/digitalmars/D/Re_The_Computer_Langu=


ages_Shootout_Game_120849.html

 And various other responses. =C2=A0The conversation happened on Nov-1-201=


0, so

 you can search the archives for it.

 -Steve
Sep 20 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Chris Dew:


 Does this just boil down to them not wanting to include D and it's their site?
 
 (Yet they include ATS and Go.)


It mostly boils down to reducing the amount of effort to keep the site up and
running.
The author has decided to keep only languages sufficiently important (as in
used) or sufficiently different from the other languages. D is not used enough
and it's too much similar to other languages (for speed reasons D entries were
very similar to C/C++ ones). This is also an advantage for D, because it means
a C/C++ programmer doesn't need too much work to learn to use D. So be happy.

Bye,
bearophile
Sep 20 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 20 Sep 2011 16:36:25 -0400, Chris Dew <cmsdew gmail.com> wrote:


 Does this just boil down to them not wanting to include D and it's their  
 site?


Yes.  But I think it's not because he doesn't like D, I think it's more  
because he did not want to maintain every language out there, and he had  
to pick only 20.  So it's not really fair to fault him for not picking D,  
or for not picking up D again.  I'm sure if he replaced another language  
with D, people would complain about that too.


 (Yet they include ATS and Go.)


*shrugs* I probably would pick different ones, but whichever ones I didn't  
pick would probably feel left out.

Maybe he likes doing Go more than D, so he picked Go.  But I'm not him,  
and people are entitled to their opinion, it is *his* site, not ours.  As  
he rightly points out, the code for his tests are available, we can always  
publish our own results.

-Steve
Sep 20 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/20/2011 09:44 PM, Chris Dew wrote:

 I've found some links which show that D used to be in the
 programming language shootout http://shootout.alioth.debian.org/

 Why did it disappear from there and can we put it back?

 It is a great sanity check for a new user to be able to see that a
 language and its implementation aren't a dog.

 I *expect* that D's performance is similar to C/C++ when used in the
 same fashion (i.e. functions and structs, rather than classes and
 delegates).  I would like to be able to confirm this.


DMDs optimizer is good but not as great as some of the modern C++ 
compilers. (the optimizer is really fast though, and as I hear it will 
get even faster) In my experience, gdc generates machine code that is 
just as fast as equivalent C++ code compiled with g++.

Basically, D code that does reasonably well at memory management is 
fast. And it is (way) easier to write fast D code than to write fast C++ 
code imho. Once the D compilers get more mature, I am sure that many 
D-specific optimizations will be added that cannot be performed on C++ 
code. (pure and immutable come to mind) Ds standard approach for 
substring computations (often needed for parsing) is also inherently 
faster than the standard C and C++ way, because it does not require to 
copy around that much data. As long as your delegates are scoped, using 
them often leads to superior performance, because they can save memory 
allocations.

I agree that it would be nice to have benchmarks that prove this. 
Recently, Dmitry Olshansky's new std.regex module has managed to 
outperform all the other implementations on the shootout at the 
regex-dna task. The module provides the (now still experimental) means 
to compile regexen to native machine code at compile time by using Ds 
advanced meta programming facilities.
Sep 20 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2011 4:24 PM, Timon Gehr wrote:

 Basically, D code that does reasonably well at memory management is fast. And
it
 is (way) easier to write fast D code than to write fast C++ code imho. Once the
 D compilers get more mature, I am sure that many D-specific optimizations will
 be added that cannot be performed on C++ code. (pure and immutable come to
mind)


Once subtlety that Andrei and I suspect will have a huge impact in the future
is 
that we've carefully designed the semantics of structs so they can be moved 
around in memory with a simple bitcopy.

(In contrast, C++ must invoke the copy constructor.)

Two consequences are:

1. A moving garbage collector becomes practical.

2. An object can be "transferred". For example,


void foo()
{
     A x;
     ....
     bar(x);
}

Note that there is no use of x in foo() after the call to bar(x). Thus, x can 
simply be pushed onto the argument stack (i.e. a bitcopy) and bar() is called. 
bar() takes care of the destruction of x's copy.

C++ is doomed to running the copy constructor for x to make a *copy* of it on 
the argument stack, and then must destroy the original x at the close of foo(). 
This costs:

1. an extra copy construction
2. an extra destructor call
3. extra exception handling & recovery code to deal with (1) throwing

Think of it a bit like the Star Trek transporter. Does it actually do a bit 
transfer, or does it create a copy and destroy the original? As a red shirt,
I'd 
prefer the D implementation of the transporter :-)
Sep 20 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/21/2011 01:37 AM, Walter Bright wrote:

 On 9/20/2011 4:24 PM, Timon Gehr wrote:

 Basically, D code that does reasonably well at memory management is
 fast. And it
 is (way) easier to write fast D code than to write fast C++ code imho.
 Once the
 D compilers get more mature, I am sure that many D-specific
 optimizations will
 be added that cannot be performed on C++ code. (pure and immutable
 come to mind)


 Once subtlety that Andrei and I suspect will have a huge impact in the
 future is that we've carefully designed the semantics of structs so they
 can be moved around in memory with a simple bitcopy.


Yes, I completely forgot about that, that is one of my favorite D features.


 (In contrast, C++ must invoke the copy constructor.)


C++11 rvalue references manage to make that effect somewhat less painful 
though.


 Two consequences are:

 1. A moving garbage collector becomes practical.


And this is a requirement for highly efficient GC. How does it cope with 
pointers that point to memory not allocated on the GC heap though? Would 
the overhead of tracking references just be invasive on parts of the 
code that uses manual memory management if a program uses a moving GC?



 2. An object can be "transferred". For example,


 void foo()
 {
 A x;
 ....
 bar(x);
 }

 Note that there is no use of x in foo() after the call to bar(x). Thus,
 x can simply be pushed onto the argument stack (i.e. a bitcopy) and
 bar() is called. bar() takes care of the destruction of x's copy.

 C++ is doomed to running the copy constructor for x to make a *copy* of
 it on the argument stack, and then must destroy the original x at the
 close of foo(). This costs:

 1. an extra copy construction
 2. an extra destructor call
 3. extra exception handling & recovery code to deal with (1) throwing

 Think of it a bit like the Star Trek transporter. Does it actually do a
 bit transfer, or does it create a copy and destroy the original? As a
 red shirt, I'd prefer the D implementation of the transporter :-)
Sep 20 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2011 4:58 PM, Timon Gehr wrote:

 On 09/21/2011 01:37 AM, Walter Bright wrote:

 1. A moving garbage collector becomes practical.


 And this is a requirement for highly efficient GC. How does it cope with
 pointers that point to memory not allocated on the GC heap though?


No problem. Only GC references get moved and hence updated.


 Would the
 overhead of tracking references just be invasive on parts of the code that uses
 manual memory management if a program uses a moving GC?


You'll still have to 'register' those blocks of memory with the GC if they hold 
any pointers into it.
Sep 20 2011
prev sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 21/09/11 12:58 AM, Timon Gehr wrote:

 On 09/21/2011 01:37 AM, Walter Bright wrote:

 (In contrast, C++ must invoke the copy constructor.)


 C++11 rvalue references manage to make that effect somewhat less painful
 though.


Less expensive computationally, yes, but the cost to the programmer is huge.

I'm willing to bet that the % of professional C++ programmers that could 
write (for example) std::vector, using move and copy semantics 
correctly, with all the correctness and exception safety guarantees, is 
incredibly low -- probably less than 1%.

In D, you just memcpy most of the time. It makes things so much easier.

And what do you lose? Internal pointers?

Who cares about internal pointers? They are so rarely used and easily 
replaceable that the overwhelming cost of supporting them is completely 
unjustified.
Sep 21 2011
prev sibling parent reply Heinz Saathoff <newshsaat arcor.de> writes:
Walter Bright wrote...

 Once subtlety that Andrei and I suspect will have a huge impact in the future
is 
 that we've carefully designed the semantics of structs so they can be moved 
 around in memory with a simple bitcopy.
 
 (In contrast, C++ must invoke the copy constructor.)


Only if a user supplied constructor is defined. The compiler generated 
constructor is just a bit copy and the destructor a null-operation.
The rule in C++ is that you only pay for what you use. 


- Heinz
Sep 23 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2011 12:27 AM, Heinz Saathoff wrote:

 Walter Bright wrote...

 Once subtlety that Andrei and I suspect will have a huge impact in the future
is
 that we've carefully designed the semantics of structs so they can be moved
 around in memory with a simple bitcopy.

 (In contrast, C++ must invoke the copy constructor.)


 Only if a user supplied constructor is defined. The compiler generated
 constructor is just a bit copy and the destructor a null-operation.
 The rule in C++ is that you only pay for what you use.


Yes, I understand that those operations may be trivial. On the other hand,
there 
is no limit to their complexity.
Sep 23 2011
parent travert phare.normalesup.org (Christophe) writes:
Walter Bright , dans le message (digitalmars.D:145096), a écrit :

 On 9/23/2011 12:27 AM, Heinz Saathoff wrote:

 Walter Bright wrote...

 Once subtlety that Andrei and I suspect will have a huge impact in the future
is
 that we've carefully designed the semantics of structs so they can be moved
 around in memory with a simple bitcopy.

 (In contrast, C++ must invoke the copy constructor.)


 Only if a user supplied constructor is defined. The compiler generated
 constructor is just a bit copy and the destructor a null-operation.
 The rule in C++ is that you only pay for what you use.


 
 Yes, I understand that those operations may be trivial. On the other hand,
there 
 is no limit to their complexity.


My C++ compiler don't even call a constructor when it is not trivial. 
And it is rarely as trivial as it should be when you use things like 
containers and smart pointers.

myStruct a = someFun();

Don't always call the copy constructors and destructors, even it should 
run them twice (one for the return statement, and one for the 
construction).
I had a program working thanks to this. I forgot to implement the copy 
constructor (which doesn't mean it was trivial), and the destructor 
should have destroyed my data.

But that is buggy behavior that we don't have to care about when we use 
D.
Sep 23 2011