H1 2015 Priorities and Bare-Metal Programming

[Daniel Murphy via Digitalmars-d]

"Walter Bright"  wrote in message news:maq0rp$2ar8$1 at digitalmars.com...

> 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.

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.

> 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.

> 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.

> 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.