H1 2015 Priorities and Bare-Metal Programming

[Walter Bright via Digitalmars-d]

On 2/2/2015 8:36 PM, Daniel Murphy wrote:
>> If so, what corrective action is the user faced with:
> The user can modify the code to allow it to be inlined.  There are a huge number
> of constructs that cause dmd's inliner to completely give up.  If a function
> _must_ be inlined, the compiler needs to give an error if it fails.

I'd like to reexamine those assumptions, and do a little rewinding.

The compiler offers a -inline switch, which will inline everything it can. 
Performance oriented code will use that switch.

So why doesn't the compiler inline everything anyway? Because there's a downside 
- it can make code difficult to symbolically debug, and it makes for 
difficulties in getting good profile data.

Manu was having a problem, though. He wanted inlining turned off globally so he 
could debug his code, but have it left on for a few functions where not inlining 
them would make the debug version too slow.

pragma(inline,true) tells the compiler that this function is 'hot', and 
pragma(inline, false) that this function is 'cold'. Knowing the hot and cold 
paths enables the optimizer to do a better job.

There are literally thousands of optimizations applied. Plucking exactly one out 
and elevating it to a do-or-die status, ignoring the other 999, is a false god. 
There's far more to a programmer reorganizing his code to make it run faster 
than just sprinkling it with "forceinline" pixie dust.

There is a lot of value to telling the compiler where the hot and cold parts 
are, because those cannot be statically determined. But exactly how to achieve 
that goal really should be left up to the compiler implementer. Doing a better 
or worse job of that is a quality of implementation issue, not a language 
specification issue.

Perhaps the fault here is calling it pragma(inline,true). Perhaps if it was 
pragma(hot) and pragma(cold) instead?