Newsgroups, off-topic
Steven Schveighoffer
schveiguy at yahoo.com
Fri Apr 23 13:04:47 PDT 2010
On Fri, 23 Apr 2010 14:00:50 -0400, Joseph Wakeling
<joseph.wakeling at webdrake.net> wrote:
> Joseph Wakeling wrote:
>> No ... ! That was true in the original code I posted, but following
>> bearophile's kind example that part of the code was updated to a form
>> along the lines of,
>
> Just for reference, here are the two pieces of code, for side-by-side
> comparison. As far as I can tell the algorithms are identical; the
> results are certainly identical; and the D code is significantly slower
> (on the order of half the speed on my machine). I don't know what the
> cause is, but my guess would be something along the lines of iterating
> across or writing values to arrays in D.
I did a little review of the code, I concur that the code is pretty
identical, and the D version does not really do any extra allocation. I
found one place where you were using pow(x, 2) to square something in the
D version but doing it with simple multiplication in the C++ version, but
that didn't account for any slowdowns when fixed. I also saw some places
where you write 0 to arrays several times, but removing those didn't help
either.
My measurements were 2 minutes 2 seconds on D to 1 minute 20 seconds on
C++, so not quite a 2x difference, but still significant.
I can only attribute the difference to g++'s more mature
optimization/inlining techniques. I can see why you are interested in
having gdc working to try and compare the two :)
In spite of all this, I still remain convinced that there is nothing
inherently bad about these results, D compilers can and probably will get
better at optimizing code. That it doesn't beat a compiler which has been
in production/mainstream for many more years probably shouldn't be
surprising to any of us, even though we want D compilers to perform the
best.
-Steve
More information about the Digitalmars-d-learn
mailing list