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.

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

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.

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?

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?

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

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?

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.

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?

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.

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?

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.

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

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

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

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?

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

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

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?

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.