H1 2015 Priorities and Bare-Metal Programming

[Daniel Murphy via Digitalmars-d]

"Walter Bright"  wrote in message news:maq7f1$2hka$1 at 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