H1 2015 Priorities and Bare-Metal Programming

[Iain Buclaw via Digitalmars-d]

On 3 February 2015 at 11:15, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
> On 3 February 2015 at 08:28, Walter Bright via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> 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?
>
> pragma(hot/cold) or @attribute(hot/cold)
>
> This maps well in gdc's framework too.

Also 'flatten' - which allows you to control inlining at the caller,
rather than the callee.