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!"