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.

The C++ code relies on the Boost libraries, another reason to like D2: you get a lot of nice functionality built-in ... :-)

Best wishes,

    -- Joe

On Fri, 23 Apr 2010 14:00:50 -0400, Joseph Wakeling <joseph.wakeling@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

Steven Schveighoffer wrote:
> 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.

Not several times superfluously?  I think I would be embarrassed if that were true :-P

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

ldc already speeds things up somewhat (its inlining is better), but still leaves a fairly sizeable gap.  There seem to be some fairly sizeable performance differences between gcc and llvm: http://www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=1

... which if I recall correctly was the motivation for the current gdc team to start working on it again.

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

Completely agree here.  I was concerned based on early experience that I was doing 'un-D-ish' things that were screwing performance, but now I'm fairly confident that I can write OK D code.  From now on it will be all pleasure as the compilers speed things up ... :-)

Thanks and best wishes,

    -- Joe

On Sat, 24 Apr 2010 05:32:25 -0400, Joseph Wakeling <joseph.wakeling@webdrake.net> wrote:

> Steven Schveighoffer wrote:
>> 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.
>
> Not several times superfluously?  I think I would be embarrassed if that
> were true :-P

Hm... I hate to embarrass you :)

I found it while manually inlining some functions (to try and see if that helps speed it up).  So it wasn't obvious until I saw the two lines together.

In Yzlm.objectReputationUpdate, you zero out reputationObject array, then call super.opCall, which also zeros out reputationObject.

It's understandable that this got introduced in the D version, you are doing something quite different than in the C++ version, swapping with another array and you were just being thorough.  I wouldn't be too embarrassed, and I note that it doesn't affect the runtime significantly anyways.

>> 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.
>
> Completely agree here.  I was concerned based on early experience that I
> was doing 'un-D-ish' things that were screwing performance, but now I'm
> fairly confident that I can write OK D code.  From now on it will be all
> pleasure as the compilers speed things up ... :-)
>
> Thanks and best wishes,

Good luck to you too!

-Steve

On 04/23/2010 10:04 PM, Steven Schveighoffer wrote:
> 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 :)

Just a small note.  As per discussion on the D.gnu list, I installed an alpha version of gdc2 based on the dmd 2.015 frontend and gcc 4.3. There were difficulties in making a direct comparison -- compilation problems which I guess are down to changes between 2.015 and 2.043 meant I had to make some code tweaks -- but the speed of the gdc-compiled code in terms of iterations per second did not seem much different to the dmd-compiled code.