"Walter Bright" wrote in message news:maq7f1$2hka$1...@digitalmars.com...
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.)
It's just a naming thing, it's not important.
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.
So what? It's a pragma used in low-level code. Some C/C++ compilers
provide similar hints for loop unrolling, vectorization, etc. It's
certainly not worth a keyword or any major language changes, but a pragma
doesn't cost anything to add. D has inline assembly for a similar reason -
sometimes the programmer knows best.
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.
And yet you kept -inline as a separate flag in dmd.
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.
Hot-or-not is certainly useful, and probably much more widely useful than
forceinline. But that doesn't mean forceinline isn't useful.
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.
Yes, this information is useful. So is forceinline.
I understand. And I suggest instead they ask me to "get that flagpole
raised, sergeant!"
We have inline assembler because sometimes being explicit is what's needed.
I would consider using forceinline in the same situations where inline
assembly is a viable option. eg interfacing with hardware, computation
kernels
