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