Optimisation possibilities: current, future and enhancements

[Basile B. via Digitalmars-d]

On Friday, 26 August 2016 at 08:44:54 UTC, 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? A compiler penalizing such bad coding style is 
> absolutely fine by me.

To be honnest I would have expected another criticism against 
this optimization idea, which is that the aggregate can expose 
shared methods that could, this time, modify the state, 
invalidating the automatic cache produced by the optim for one 
thread, even if this scenario is not plausible without hacks (e.g 
casting away the "shared" part in the type of a variable that's 
used in the const pure function.