On Nov 2, 2009, at 11:36 AM, Sherm Pendley wrote:
On Mon, Nov 2, 2009 at 2:25 PM, Ed Wynne <[email protected]> wrote:

That said, the original question is a good one. Using x*x instead of
pow(x,2) would be quite a bit faster

Are you certain of that? With loop unrolling and inlined functions, it
should result in identical code being produced by the compiler.

With the single caveat of the compile time optimization pow(x,2) -> x*x,
I am certain of that.

Even the most inlined replacement for pow() would still have to handle
arbitrary values for the exponent, which would add conditional tests,
loops, code bloat, etc. One step down from that and you have the
overhead of a function call. Another step down and you have cross
library function call glue. All of which depends entirely your compiler
and your execution environment.

Absolute best case you can hope for is to be no-worse than x*x, and
perhaps my old crotchity roots are showing, but decades of gcc usage
has taught me that the absolute best case doesn't happen that often,
or even that reliably.

so except for clarity reasons, there isn't a
good reason to use pow() in that case.

Clarity should be the default, not the exception. Unless you've
profiled your code and found the use of pow() to be a significant
bottleneck, there's no good reason *not* to use it.


In general, I agree with this sentiment (as I said) but specifically as
it applies to this case, I would argue the meaning of x*x is easier to
deduce than pow(x,2) for those not versed in writing math in C. The
fact that its always guaranteed to be optimal is just the exception
to the rule, or is that icing on the cake?

-Ed

_______________________________________________

Cocoa-dev mailing list ([email protected])

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to