www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Language Shootout

reply Dan <murpsoft hotmail.com> writes:
Hi guys,

This idea will only work with Walter in on it.  : p  I was thinking that we
might go through the various benchmarks in "the language shootout" and find out
those items where D is significantly behind for any reason, and correct the
performance.

For example, against Eiffel, you see their Fasta implementation is 38 times
faster than D's.  Why not compile the code, find out how it works and see why
D's that much slower - and then Walter can fix the code?

Likewise for GCC's k-nucleotide, G++'s meteor-contest and k-nucleotide, Clean's
sum-file, Erlang's cheap-concurrency etc.

We may find that there's a good reason D is slower, but we may find there's a
performance bug or enhancement that would significantly improve D?

Just an idea.
Mar 26 2007
next sibling parent "Saaa" <empty needmail.com> writes:
 Hi guys,

 This idea will only work with Walter in on it.  : p  I was thinking that 
 we might go through the various benchmarks in "the language shootout" and 
 find out those items where D is significantly behind for any reason, and 
 correct the performance.

 For example, against Eiffel, you see their Fasta implementation is 38 
 times faster than D's.  Why not compile the code, find out how it works 
 and see why D's that much slower - and then Walter can fix the code?

 Likewise for GCC's k-nucleotide, G++'s meteor-contest and k-nucleotide, 
 Clean's sum-file, Erlang's cheap-concurrency etc.

 We may find that there's a good reason D is slower, but we may find 
 there's a performance bug or enhancement that would significantly improve 
 D?

 Just an idea


I think you could make a start without Walter.
If anything interesting surfaces Walter will probably 'correct' it or at 
least tell us why we are wrong :)
maybe just start here:
http://www.digitalmars.com/d/code_coverage.html
Mar 26 2007
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
I like the idea.  Since Walter's time is so limited we shouldn't expect him 
to do all of the work.  If someone who is performance savvy could look at 
the code generated and try to suggest solutions.  Then this information 
could be submitted to Walter to help improve the compiler.

-Craig

"Dan" <murpsoft hotmail.com> wrote in message 
news:eu8t71$d2p$1 digitalmars.com...

 Hi guys,

 This idea will only work with Walter in on it.  : p  I was thinking that 
 we might go through the various benchmarks in "the language shootout" and 
 find out those items where D is significantly behind for any reason, and 
 correct the performance.

 For example, against Eiffel, you see their Fasta implementation is 38 
 times faster than D's.  Why not compile the code, find out how it works 
 and see why D's that much slower - and then Walter can fix the code?

 Likewise for GCC's k-nucleotide, G++'s meteor-contest and k-nucleotide, 
 Clean's sum-file, Erlang's cheap-concurrency etc.

 We may find that there's a good reason D is slower, but we may find 
 there's a performance bug or enhancement that would significantly improve 
 D?

 Just an idea.
Mar 26 2007
parent kmk <kmk200us yahoo.com> writes:
Craig Black Wrote:


 I like the idea.  Since Walter's time is so limited we shouldn't expect him 
 to do all of the work.  If someone who is performance savvy could look at 
 the code generated and try to suggest solutions.  Then this information 
 could be submitted to Walter to help improve the compiler.
 
 -Craig
 
 "Dan" <murpsoft hotmail.com> wrote in message 
 news:eu8t71$d2p$1 digitalmars.com...

 Hi guys,

 This idea will only work with Walter in on it.  : p  I was thinking that 
 we might go through the various benchmarks in "the language shootout" and 
 find out those items where D is significantly behind for any reason, and 
 correct the performance.

 For example, against Eiffel, you see their Fasta implementation is 38 
 times faster than D's.  Why not compile the code, find out how it works 
 and see why D's that much slower - and then Walter can fix the code?

 Likewise for GCC's k-nucleotide, G++'s meteor-contest and k-nucleotide, 
 Clean's sum-file, Erlang's cheap-concurrency etc.

 We may find that there's a good reason D is slower, but we may find 
 there's a performance bug or enhancement that would significantly improve 
 D?

 Just an idea. 


 
 


Most of the differences in speed when comparing to C and C++ on that site have
to do with slower recursion when using the DMD compiler. When I compare GDC
with DMD using the same applications from that site, GDC offers on average 2x
better performance in recursion. 

So, if GDC compiled apps were compared with the C and C++ apps compiled with
GCC, I think you would find that D performs just as well if not better.
Mar 26 2007
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
Dan Wrote:


 
 Hi guys,
 
 This idea will only work with Walter in on it.  : p  I was thinking that we
might go through the various benchmarks in "the language shootout" and find out
those items where D is significantly behind for any reason, and correct the
performance.
 
 For example, against Eiffel, you see their Fasta implementation is 38 times
faster than D's.  Why not compile the code, find out how it works and see why
D's that much slower - and then Walter can fix the code?
 


Huh? D is a tad better on one machine and just a bit slower on the other
machine (on the Shootout). Maybe there was some sort of problem on the site
when you looked at it?

http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all

http://shootout.alioth.debian.org/debian/benchmark.php?test=fasta&lang=all
Mar 26 2007
next sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
Dave wrote:

 Dan Wrote:
 

 Hi guys,

 This idea will only work with Walter in on it.  : p  I was thinking that we
might go through the various benchmarks in "the language shootout" and find out
those items where D is significantly behind for any reason, and correct the
performance.

 For example, against Eiffel, you see their Fasta implementation is 38 times
faster than D's.  Why not compile the code, find out how it works and see why
D's that much slower - and then Walter can fix the code?


 
 Huh? D is a tad better on one machine and just a bit slower on the other
machine (on the Shootout). Maybe there was some sort of problem on the site
when you looked at it?
 
 http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all
 
 http://shootout.alioth.debian.org/debian/benchmark.php?test=fasta&lang=all


In fact, the D version is written nicely, but the the fastest C++ 
version is clearly written for speed.  I'm willing to bet that D could 
close the gap by taking away all classes and using free functions + 
structs the way the C++ version does.  Anybody up for it?  Since we 
can't test on the shootout machine itself, improvements should be 
measured relative to the currently published version.

Dave
Mar 27 2007
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
David B. Held wrote:

 Dave wrote:

 Dan Wrote:


 Hi guys,

 This idea will only work with Walter in on it.  : p  I was thinking 
 that we might go through the various benchmarks in "the language 
 shootout" and find out those items where D is significantly behind 
 for any reason, and correct the performance.

 For example, against Eiffel, you see their Fasta implementation is 38 
 times faster than D's.  Why not compile the code, find out how it 
 works and see why D's that much slower - and then Walter can fix the 
 code?


 Huh? D is a tad better on one machine and just a bit slower on the 
 other machine (on the Shootout). Maybe there was some sort of problem 
 on the site when you looked at it?

 http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all

 http://shootout.alioth.debian.org/debian/benchmark.php?test=fasta&lang=all 


 
 In fact, the D version is written nicely, but the the fastest C++ 
 version is clearly written for speed.  I'm willing to bet that D could 
 close the gap by taking away all classes and using free functions + 
 structs the way the C++ version does.  Anybody up for it?  Since we 
 can't test on the shootout machine itself, improvements should be 
 measured relative to the currently published version.


Try changing the constants in the Random class to be 'const double' 
instead of 'const int'. Mixing ints and doubles is really slow.

Try replacing the Random class with:

double genRandom(double max)
{
    static double seed = 42;
    const double IA = 3877, IC = 29573, IM = 139968;

    return max * ((seed = (seed * IA + IC) % IM) * (1.0 / IM));
}
Mar 26 2007
parent Dave <Dave_member pathlink.com> writes:
Don Clugston wrote:

 David B. Held wrote:

 Dave wrote:

 Dan Wrote:


 Hi guys,

 This idea will only work with Walter in on it.  : p  I was thinking 
 that we might go through the various benchmarks in "the language 
 shootout" and find out those items where D is significantly behind 
 for any reason, and correct the performance.

 For example, against Eiffel, you see their Fasta implementation is 
 38 times faster than D's.  Why not compile the code, find out how it 
 works and see why D's that much slower - and then Walter can fix the 
 code?


 Huh? D is a tad better on one machine and just a bit slower on the 
 other machine (on the Shootout). Maybe there was some sort of problem 
 on the site when you looked at it?

 http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all

 http://shootout.alioth.debian.org/debian/benchmark.php?test=fasta&lang=all 


 In fact, the D version is written nicely, but the the fastest C++ 
 version is clearly written for speed.  I'm willing to bet that D could 
 close the gap by taking away all classes and using free functions + 
 structs the way the C++ version does.  Anybody up for it?  Since we 
 can't test on the shootout machine itself, improvements should be 
 measured relative to the currently published version.


 
 Try changing the constants in the Random class to be 'const double' 
 instead of 'const int'. Mixing ints and doubles is really slow.
 
 Try replacing the Random class with:
 
 double genRandom(double max)
 {
    static double seed = 42;
    const double IA = 3877, IC = 29573, IM = 139968;
 
    return max * ((seed = (seed * IA + IC) % IM) * (1.0 / IM));
 }


I tried that and get about 10% slower on a P4?

Thanks,

- Dave
Mar 30 2007
prev sibling parent reply janderson <askme me.com> writes:
David B. Held wrote:

 Dave wrote:

 Dan Wrote:


 Hi guys,

 This idea will only work with Walter in on it.  : p  I was thinking 
 that we might go through the various benchmarks in "the language 
 shootout" and find out those items where D is significantly behind 
 for any reason, and correct the performance.

 For example, against Eiffel, you see their Fasta implementation is 38 
 times faster than D's.  Why not compile the code, find out how it 
 works and see why D's that much slower - and then Walter can fix the 
 code?


 Huh? D is a tad better on one machine and just a bit slower on the 
 other machine (on the Shootout). Maybe there was some sort of problem 
 on the site when you looked at it?

 http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all

 http://shootout.alioth.debian.org/debian/benchmark.php?test=fasta&lang=all 


 
 In fact, the D version is written nicely, but the the fastest C++ 
 version is clearly written for speed.  I'm willing to bet that D could 
 close the gap by taking away all classes and using free functions + 
 structs the way the C++ version does.  Anybody up for it?  Since we 
 can't test on the shootout machine itself, improvements should be 
 measured relative to the currently published version.
 
 Dave


That would be a C verse C comparison.  I don't think that would be of 
much advantage.  I think the C++ version should be OO too (not that we 
can change that).

D really needs to be done in a way that looks like D.  Hopefully, the 
extra overhead can be optimized in other ways.
Mar 27 2007
next sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
janderson wrote:

 [...]
 That would be a C verse C comparison.  I don't think that would be of 
 much advantage.  I think the C++ version should be OO too (not that we 
 can change that).
 
 D really needs to be done in a way that looks like D.  Hopefully, the 
 extra overhead can be optimized in other ways.


The FAQ clearly states that you should write the program in the fastest 
manner possible.  I think we can agree that inline asm is not 
appropriate for C/C++/D, but I think it's perfectly fair to forego the 
OOP aspects of the langauge where it is possible to do so and realize a 
speed benefit.  After all, that is much of the point of D, isn't it? 
You can't exactly shoehorn stack objects into Java, and that is much of 
what makes the Language Shootout relevant.

So what if it turns out to be C vs. C?  That would be great advertising 
for D, IMO.  The fact that D is in the top 5 on both platforms for this 
test is great.  The fact that C++ is actually faster than C in some 
cases is very interesting and worth of consideration.  The assumption 
that C is automatically the fastest language does not always hold.  The 
fact that Eiffel is near the top is interesting, as well as Scala.  The 
fact that Haskell is 5-6x slower than C is also very interesting.

If you want a test that exercises the OOP aspects of languages, perhaps 
we could create a reasonable one and suggest it to the Shootout.

Dave
Mar 27 2007
parent janderson <askme me.com> writes:
David B. Held wrote:

 janderson wrote:

 [...]
 That would be a C verse C comparison.  I don't think that would be of 
 much advantage.  I think the C++ version should be OO too (not that we 
 can change that).

 D really needs to be done in a way that looks like D.  Hopefully, the 
 extra overhead can be optimized in other ways.


 
 The FAQ clearly states that you should write the program in the fastest 
 manner possible.  I think we can agree that inline asm is not 
 appropriate for C/C++/D, but I think it's perfectly fair to forego the 
 OOP aspects of the langauge where it is possible to do so and realize a 
 speed benefit.  After all, that is much of the point of D, isn't it? You 
 can't exactly shoehorn stack objects into Java, and that is much of what 
 makes the Language Shootout relevant.
 
 So what if it turns out to be C vs. C?  That would be great advertising 
 for D, IMO.  The fact that D is in the top 5 on both platforms for this 
 test is great.  The fact that C++ is actually faster than C in some 
 cases is very interesting and worth of consideration.  The assumption 
 that C is automatically the fastest language does not always hold.  The 
 fact that Eiffel is near the top is interesting, as well as Scala.  The 
 fact that Haskell is 5-6x slower than C is also very interesting.
 
 If you want a test that exercises the OOP aspects of languages, perhaps 
 we could create a reasonable one and suggest it to the Shootout.
 
 Dave


Actually I'm not a huge oop fan, I kinda just wanted peoples reaction. 
If the algorithm makes sense as a free function, then do it that way.

-Joel
Mar 27 2007
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
I would agree with this if the aim here is not to produce fastest and/or
resource-friendly and/or shortest applications (we can chose what we apriciate
most of these three values).
It would be really nice if we could "measure" how well OO code it is. :)

Kind regards

Dejan
Mar 30 2007
prev sibling parent reply janderson <askme me.com> writes:
Dave wrote:

 Dan Wrote:
 

 Hi guys,

 This idea will only work with Walter in on it.  : p  I was thinking that we
might go through the various benchmarks in "the language shootout" and find out
those items where D is significantly behind for any reason, and correct the
performance.

 For example, against Eiffel, you see their Fasta implementation is 38 times
faster than D's.  Why not compile the code, find out how it works and see why
D's that much slower - and then Walter can fix the code?


 
 Huh? D is a tad better on one machine and just a bit slower on the other
machine (on the Shootout). Maybe there was some sort of problem on the site
when you looked at it?
 
 http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all
 
 http://shootout.alioth.debian.org/debian/benchmark.php?test=fasta&lang=all
 


There's something radically different about those 2 benchmarks.  I know 
Intel can be slow but 14times slower.  Either the algorithm is 
different, the input data is different, the machine configuration is 
massively different or AMD kicks ass for this algorithm.

-Joel
Mar 27 2007
next sibling parent "David B. Held" <dheld codelogicconsulting.com> writes:
janderson wrote:

 [...]
 There's something radically different about those 2 benchmarks.  I know 
 Intel can be slow but 14times slower.  Either the algorithm is 
 different, the input data is different, the machine configuration is 
 massively different or AMD kicks ass for this algorithm.


The AMD is a 2.2 GHz Sempron while the Intel is a 2.0 GHz Pentium 4. 
Just goes to prove that Intel really does need a much higher clock speed 
to compete.  Memory and disk were otherwise the same, but who knows how 
fast they were running the FSB or what the memory timings were.  They 
also don't list cache sizes or speeds.  With 512 MB of RAM and careful 
testing, I would hope that I/O doesn't play any role in the tests, but 
you never know.

Dave
Mar 27 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
janderson wrote:

 Dave wrote:

 Dan Wrote:


 Hi guys,

 This idea will only work with Walter in on it.  : p  I was thinking 
 that we might go through the various benchmarks in "the language 
 shootout" and find out those items where D is significantly behind 
 for any reason, and correct the performance.

 For example, against Eiffel, you see their Fasta implementation is 38 
 times faster than D's.  Why not compile the code, find out how it 
 works and see why D's that much slower - and then Walter can fix the 
 code?


 Huh? D is a tad better on one machine and just a bit slower on the 
 other machine (on the Shootout). Maybe there was some sort of problem 
 on the site when you looked at it?

 http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all

 http://shootout.alioth.debian.org/debian/benchmark.php?test=fasta&lang=all 


 
 There's something radically different about those 2 benchmarks.  I know 
 Intel can be slow but 14times slower.  Either the algorithm is 
 different, the input data is different, the machine configuration is 
 massively different or AMD kicks ass for this algorithm.


N= 2.5 million in one case, N=25 million in the other.


 
 -Joel
Mar 27 2007
prev sibling parent reply Dan <murpsoft hotmail.com> writes:
Wow...

The pages actually are quite different than the last time I saw them.  Maybe
someone recently submitted some code, or maybe, yeah their site was broken?

Regardless, it shows that D's 2.2x slower than GCC (and GDC?) on recursion,
which is bad.  I would guess that the function call overhead alone is
sufficient to taint the benchmarks away in C's favor.

Also, yeah, we probably should have a class-less implementation of everything
if we care about speed.  

Classes are inefficient, and unnecessary IMHO - structs can have static methods
and constructors/destructors too.  Only remaining thing is inheritance and
interfaces.

I learned about the -cov feature.  : )
Lovely!
Mar 27 2007
parent kris <foo bar.com> writes:
Dan wrote:

 Wow...
 
 The pages actually are quite different than the last time I saw them.  Maybe
someone recently submitted some code, or maybe, yeah their site was broken?
 
 Regardless, it shows that D's 2.2x slower than GCC (and GDC?) on recursion,
which is bad.  I would guess that the function call overhead alone is
sufficient to taint the benchmarks away in C's favor.
 
 Also, yeah, we probably should have a class-less implementation of everything
if we care about speed.  
 
 Classes are inefficient, and unnecessary IMHO - structs can have static
methods and constructors/destructors too.  Only remaining thing is inheritance
and interfaces.


IMO, classes are as you describe them only when badly abused :)

There are also times when a class is used rather than a struct, for the 
sake of consistency and/or due to the lack of a struct ctor construct in D.

For example, there are a two or three cases in Tango where this occurs, 
such as the Random aggregate. Would be great to get sorted out with a 
struct ctor, but in the meantime those instances will remain as classes 
since the syntax will likely still be valid when structs become further 
endowed (we hope)

2c
Mar 30 2007