H1 2015 Priorities and Bare-Metal Programming

[Walter Bright via Digitalmars-d]

On 2/3/2015 1:49 AM, Daniel Murphy wrote:
> This doesn't make sense to me, because even if a function is 'hot' it still
> shouldn't be inlined if inlining is turned off.

'hot' can be interpreted to be inline even if inlining is turned off. (That is 
what Manu wanted.)


>> 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.
>
> Nobody is suggesting that.  forceinline if for when either a) the function is a
> trivial wrapper and should always always be expanded inline (ie where macros are
> typically used in C) or b) the compiler's heuristics have failed and
> profiling/inspecting the generated code has shown that the function should be
> inlined.

It's still elevating inlining above all other optimizations (and inlining is 
nothing more than just another optimization). For example, register allocation 
is critical to code performance, and the optimizer frequently doesn't do the 
best job of it.


>> 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.
>
> Yes and no.  It is still useful to have a way to tell the compiler exactly what
> to do, when needed.  Eg we can allocate arrays on the stack, even though the
> compiler could theoretically move heap allocations there without user intervention.

Back in the olden days, with dmc you could individually turn various 
optimizations on and off. I finally gave up on that because it was useful to 
nobody. The 'register' keyword was dropped because although it could be used to 
do better register allocation, in reality it was so misused it would just make 
things worse.

Like I said, there are thousands of optimizations in the compiler. They all 
interact with each other in usually unexpected ways. Focusing on just one in 
isolation is not likely to yield best results. But with hot-or-not, instead you 
are giving the compiler useful information to guide its heuristics.

It's like the old joke where a captain is asked by a colonel how he'd get a 
flagpole raised. The captain replied with a detailed set of instructions. The 
colonel said wrong answer, the correct response would be for the captain to say: 
"Sergeant, get that flag pole raised!"

Hot-or-not gives information to guide the heuristics of the compiler's decisions.

For a related example, the compiler assumes that loops are executed 10 times 
when weighting variables for who gets enregistered. Giving hot-or-not guidance 
may raise it to 20 for hot, and lower it to 1 for not. There are many places in 
the optimizer where a cost function is used, not just inlining decisions.


>> Perhaps the fault here is calling it pragma(inline,true). Perhaps if it was
>> pragma(hot) and pragma(cold) instead?
>
> That would indeed be a better name, but it still wouldn't be what people are
> asking for.

I understand. And I suggest instead they ask me to "get that flagpole raised, 
sergeant!"