This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: std::pow implementation

From: Scott Robert Ladd <coyote at coyotegulch dot com>
To: Richard dot Earnshaw at arm dot com
Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, Karel Gardas <kgardas at objectsecurity dot com>, Alexandre Oliva <aoliva at redhat dot com>,Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>, gcc at gcc dot gnu dot org
Date: Wed, 30 Jul 2003 12:00:25 -0400
Subject: Re: std::pow implementation
References: <200307301338.h6UDc2p19569@pc960.cambridge.arm.com>

Richard Earnshaw wrote:

Profiling doesn't help if the answer comes back as "sometimes"
(function foo's use of bar is best inlined, function wibble's use of
bar is best not inlined).

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.

The programmer, not the compiler, has the responsibility to create an effective program.

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

References:
- Re: std::pow implementation
  - From: Richard Earnshaw

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]