Re: std::pow implementation

[Felix Lee <felix dot 1 at canids dot net>]

dewar@gnat.com (Robert Dewar):
> 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.

Ah, then the problem is not premature optimization, it's
premature worrying about efficiency. :)

Seriously, I find I have to struggle against my own programming
habits that were acquired years ago.  There's a cycle
in programming:
   1. write "natural" code
   2. check the program's performance
   3. modify the code to increase performance

Since this is rather time-consuming, an efficient programmer
learns what techniques found in step 3 are often a good idea, and
starts using them naturally in step 1.

I'm discovering that this cycle of learning is itself a premature
optimization, mainly because of Moore's Law and the increases in
speed and complexity of computer systems.  Habits like "avoid
trivial functions because function calls are expensive" are a
waste of time.  Ten years later, all the costs are going to be
different again.

I suspect the only time-optimization technique that's worth
learning is: a) identify the code paths and data paths that are
followed most often, b) reduce those paths as much as possible.

This implies a need for better program analysis tools.
Traditional profiling is focused on the units of code path called
"functions", but that's becoming increasingly irrelevant.

I think I want tools that will make steps 2-3 efficient,
and tools that I can ask to collapse code paths for me.
("inline" is pretty much worthless for that.  "leafify" is
better.)
--