Re: std::pow implementation

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul 30, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
> | On Jul 30, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> | 
> | > But the fact is that the compiler is not doing better by going its own
> | > programmed logic.  We've not reached the same level of sophistication
> | > as for register allocation.
> | 
> | And your solution for the problem is to dumb it down further such that
> | it doesn't even attempt to do a good job?

> I'm not proposing to dumb it further.  

Oh.  `The compiler should do what the user tells it to (WRT inline),
no more, no less.'  Can you explain to me what room is left for the
compiler to be intelligent (WRT inline) given this proposition?

> In fact, people like you who make bogus quote of the standard to claim
> that inline is implicit in C++ have already push the compiler to its
> dumbest state.

I'm tempted to respond with something along the lines of `people like
you who refuse to accept obvious arguments claiming they're
unconvincing...', but I'll get out of this discussion now, before it
turns into a fight.  I've already exposed my arguments, and so far
your arguments have only shown that you only care about a small part
of the big picture.

> In effect, I'm proposing to return to first principles where the C++
> programmer is trusted, is listened to, not treated by the software
> as a dumb person unable to make sensible decisions.

If you're not reasonable when presented with a simple argument just
because it goes against your theory, why should I expect you to be
reasonable when tagging functions as inline?  If you won't listen to
me, why should I listen to you?  Why do you insist on making claims
that `old is good' while all the evidence we have is that, when using
the inlining heuristics that you propose, namely, that the compiler
should inline any function declared inline (explicit or implicitly, or
whatever term you'd rather use to describe the fact that a member
function defined inside a class body is regarded as inline), compile
time *and* run time got significantly worse.

The fact that you are careful about marking functions as inline only
when you guess it will be profitable to inline them (and I'm assuming
you do), in the scenarios in which you're using the functions, won't
make it so for every C++ developer in the world, no matter how much
you whine.  People in different scenarios than yours, in which full
knowledge about the users of classes is available and their platforms,
won't be able to make as perfect a judgement WRT marking functions as
to-be-inlined as you are.  For people writing reusable software
components, this is just not possible: they can't predict how a
software component is going to be used.  Of course, if you keep on
convinced that the context of use of a function can't possibly affect
whether it's profitable to inline the function, then the only person
who will have learned anything form this debate is me, and it's that
you're blinded by prejudice and/or pride.

> When, the programmed logic of your inliner will reach the
> sophisticated level comparable to that of automatic register
> allocation, then you will have evidence to have your software not to
> trust the programmer.

Removing the logic we have in place that attempts to do a better job,
but fails, won't help us get closer to it.  If you have any concrete
suggestions to improve it, please post the patches.  If you don't, go
at least do some research and re-discover that taking your approach to
inlining has been tried with real-life C++ code, and results were
disastrous.  Could we do better?  Sure.  But it's not by wasting time
on this debate that we will get there.  We're just rehashing an
argument that we've had at least twice in the past.  Nothing new was
brought in, and all you brought was a set of prejudicial personal
convictions that burden programmers with decisions computers are
better suited to make for them, except in very special cases.  When
you have facts to present that would add to the discussion, I'll be
hear eager to listen to you.  Meanwhile, I'll stop feeding the flame
war.  The only thing it has produced is heat.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer