This is the mail archive of the
mailing list for the GCC project.
Re: std::pow implementation
- From: Felix Lee <felix dot 1 at canids dot net>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 30 Jul 2003 11:19:10 -0700
- Subject: Re: std::pow implementation
firstname.lastname@example.org (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
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
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