Mid-term vision review

[Iain Buclaw via Digitalmars-d]

On 4 April 2015 at 22:48, H. S. Teoh via Digitalmars-d
<digitalmars-d at puremagic.com> 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.