digitalmars.D - Language Shootout
- Dan <murpsoft hotmail.com> Mar 26 2007
- "Saaa" <empty needmail.com> Mar 26 2007
- "Craig Black" <cblack ara.com> Mar 26 2007
- kmk <kmk200us yahoo.com> Mar 26 2007
- Dave <Dave_member pathlink.com> Mar 26 2007
- "David B. Held" <dheld codelogicconsulting.com> Mar 27 2007
- Don Clugston <dac nospam.com.au> Mar 26 2007
- Dave <Dave_member pathlink.com> Mar 30 2007
- janderson <askme me.com> Mar 27 2007
- "David B. Held" <dheld codelogicconsulting.com> Mar 27 2007
- janderson <askme me.com> Mar 27 2007
- Dejan Lekic <dejan.lekic gmail.com> Mar 30 2007
- janderson <askme me.com> Mar 27 2007
- "David B. Held" <dheld codelogicconsulting.com> Mar 27 2007
- Don Clugston <dac nospam.com.au> Mar 27 2007
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
"Saaa" <empty needmail.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
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
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
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
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
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
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
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
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
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
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
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
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
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
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