On 4 April 2015 at 22:48, H. S. Teoh via Digitalmars-d <[email protected]> wrote: > On Sat, Apr 04, 2015 at 01:10:43PM -0700, Walter Bright via Digitalmars-d > wrote: >> On 4/3/2015 9:41 AM, David Nadlinger wrote: >> >On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: >> >>On 4/3/15 3:10 AM, Andrea Fontana wrote: >> >>>It would be great to have dmd on embedded platforms. >> >> >> >>I agree. We just don't have the champion for that yet. -- Andrei >> > >> >I might obviously be biased, but to be honest I don't see much value >> >in starting to port a largely obsolete backend to a whole new >> >processor architecture. >> >> It's not obsolete at all. There's nothing fundamentally wrong with it, >> or preventing new optimizations being added to it. After all, I didn't >> have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux, >> to OSX, to SIMD, etc. > > The trouble with the dmd backend is that it currently doesn't produce > very well-optimized code. I have consistently observed a 20-30% > performance degradation with code compiled with dmd vs. code compiled > with gdc (both with all optimization switches turned to the max). From > cursory investigation of the asm output, dmd appears to be unable to > inline beyond the most trivial function calls, doesn't do loop > refactoring / unrolling as well as gdc does, and a host of other little > things that all add up to poorer performance when CPU-intensive inner > loops are concerned. A lot of this deficiency shows up especially in > range-based code, which consists of lots of calls to small functions > from inner loops, where performance really matters. >
Not just inlining, each CPU has it's own quirks that need tending to as well, for instance, a Bonnel (Atom) CPU should have loop branches aligned to a 16-byte boundary, where-as other chips (Core i7, Sandybridge, etc) are fine on an 8-byte boundary. (Observation made in issue 5100) Iain.
