Re: [v3] conditional tweak

[Phil Edwards <phil at codesourcery dot com>]

On Fri, Nov 07, 2003 at 11:32:35PM +0100, Gabriel Dos Reis wrote:
> Martin Sebor <sebor@roguewave.com> writes:
> | Gabriel Dos Reis wrote:
> | ...
> | > | While I haven't measured Jerry's particular patch, on machines with deep
> | > | pipelines, an incorrectly-predicted branch can be a significant stall
> | > | (most/all of the pipeline has to be cleared).
> | > In theory, yes.  In this particular case, we're speaking of an I/O
> | > formatting flag setting which is nowhere a bottleneck (expect probably
> | > in a testsuite).
> | 
> | This conditional actually does happen to have a significant impact
> | on performance -- fill() is called every time a number is inserted
> | into a stream, for example.
> 
> compared to the actual work for formatting?

I consider fill() to /be/ part of the actual work.

Here's my opinion before I vanish into non-networked-land for a few days:
for years, the GCC team has been warning of the dangers of slowing down the
compiler and runtime by a few percent at a time, because it accumulates
so quickly.  Why should the opposite not be true?  Yes, even if it only
speeds up Martin's testcase by a few percent, that's still a few percent
we didn't have before.

The patch should not degrade performance, and might improve it.  I see no
reason why it should not go in.

Phil

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan