std::pow implementation

[Scott Robert Ladd]

Robert Dewar wrote:
>>Inlining is an optimization; in all but the most obvious and trivial
>>cases (e.g., simple assignments), it should be performed by a programmer 
>>*after* profiling, and not before. "Premature optimization is the root 
>>of all evil", according to Hoare and Knuth; in code reviews, I tend to 
>>grumble about people who insist on inlining and using cute tricks, when 
>>they haven't done any analysis as to how their choices affect code 
>>quality and performance.

> I strongly disagree with this. Profiling is simply not an effective way of
> identifying functions that benefit from inlining. Profiling is a very crude
> tool that is helpful in eliminating hot spots but that's all.

The value of profiling depends on its sophistication. There are many 
ways to instrument a program...

> The reason for not taking this view of inlining is that unless you get in the
> mindset that inlining will be done routinely by the compiler (at your direction)
> then you will tend to shy away from the use of trivial abstraction functions
> because you will worry about efficiency.

Note that I said "in all but the most obvious and trivial cases (e.g. 
assignment)"; in other words, a good programmer will inline "trivial 
abstraction functions" because they know that such provide conceptual 
value without an efficiency hit.

> The quote about premature optimization here is wrong I think. What Knuth
> was talking about (go back and look at what he really said, not just the
> sound bite) was distorting the code prematurely and unnecessarily in the
> interests of optimization.

Using "inline" willy-nilly is distorting code, in my opinion. You are 
telling the compiler to do something without evidence of inlining's 
efficacy.

> In fact, the liberal use of inline tends to *prevent* premature optimization
> (of the kind I mentioned above, avoidance of abstraction), and certainly does
> not distort the code.

I think we actually agree here! :) I'm strongly against anyone using 
"inline" unless they have a reason for doing so; indeed, indescriminate 
inlining is a Bad Thing. A good programmer isn't going apply inline 
without good reason, and the compiler shouldn't silently veto those 
decisions.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing