Optimisation possibilities: current, future and enhancements

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 26 02:30:52 PDT 2016


On 26.08.2016 10:44, kink wrote:
> On Friday, 26 August 2016 at 05:50:52 UTC, Basile B. wrote:
>> On Thursday, 25 August 2016 at 22:37:13 UTC, kinke wrote:
>>> On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote:
>>> From my perspective, the problem with this example isn't missed
>>> optimization potential. It's the code itself. Why waste
>>> implementation efforts for such optimizations, if that would only
>>> reward people writing such ugly code with an equal performance to a
>>> more sane `2 * foo.foo()`? The latter is a) shorter, b) also faster
>>> with optimizations turned off and c) IMO simply clearer.
>>
>> You're too focused on the example itself (Let's find an non trivial
>> example, but then the asm generated would be longer). The point you
>> miss is that it just *illustrates* what should happend when many calls
>> to a pure const function are occur in a single sub program.
>
> I know that it's just an illustration.  But I surely don't like any
> function with repeated calls to this pure function. Why not have the
> developer code in a sensible style (cache that result once for that
> whole 'subprogram' manually) if performance is a concern?

Better performance is better even when it is not the primary concern.

> A compiler penalizing such bad coding style is absolutely fine by me.

It's not the compiler's business to judge coding style, also:

// original code. not "bad".

int foo(int x) pure{ ... }

int bar(int x) pure{ return foo(x) + foo(5-x); }

void main(){
     writeln(bar(5));
}

// ==> inlining

void main(){
     writeln(foo(5)+foo(10-5));
}

// ==> constant folding, "bad" code

void main(){
     writeln(foo(5)+foo(5));
}



More information about the Digitalmars-d mailing list