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