On 1/7/2013 3:13 AM, Russel Winder wrote:
I just thought I should report that 2.061 has fixed all the threading
problems I was moaning about after the 2.059 → 2.060 update.  So thanks
to all concerned with fixing the bug reports that were generated.

That is great news!


LDC is though still generally creating faster executables than DMD. This
is just a gut feeling right now, in a couple of weeks time I'll see if I
can get some actual numbers.

It's also helpful to drill down to see why. For example, a while back a D user posted a benchmark where he concluded that dmd generated poor code for integer math. Drilling down into the generated code, it was pretty much the same as what other compilers generated. What was different, however, was the implementation of the "long divide" library function. druntime had a slow one. The long divide dominated the performance profile. Fixing that brought it up to par with zero changes to the compiler.

I've also seen benchmarks where the compiler was blamed, where malloc, or printf, or strcpy, or whatever was the actual dominant cycle sucker. Or even that the wrong compiler switches were used. Yes, I've seen magazines publish benchmarks where the 'slow' compiler was used with debug switches on, and the 'fast' compiler had the optimization switches on.

Reply via email to