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
