Take the 2-minute tour ×

I have this question in mind regarding optimazation of compiler when it comes to shorthanded if/else.

I have this function:

double eu_distance (const coor& x, const coor& y) {

return ((y.x - x.x)*(y.x - x.x) + (y.y - x.y)*(y.y - x.y));

I am wondering what is more efficient?

min = min > eucl_distance(point_a, point_b) ? eucl_distance(point_a, point_b) : min;


double dis = eucl_distance(point_a, point_b);
if (min > dis)
    min = dis;

in the former case, does compiler (in my case, GCC 4.6.2) know how to optimize that if/else to keep the return value of eucl_distance() to reuse instead of computing it twice?

A piggy back question would be:

What is more efficient?

(y.x - x.x)*(y.x - x.x)


pow((y.x - x.x),2)

PS: Sorry that I cannot pick more than one correct answers!! :( Thank you all for your answers! I really appreciate them!!

share|improve this question
Profile!Profile!Profile!Profile!Profile!Profile! is the only answer. –  Alok Save Feb 23 '12 at 17:17
I added gcc as a tag because the answer is likely to be quite compiler specific. –  500 - Internal Server Error Feb 23 '12 at 17:18
You could always compile the code and compare the assemblies by hand if in doubt. Even if you don't know assembly, if the code is the same then you know it optimizes to the same thing. Remember, though, premature optimization is the root of all evil. Generally optimizations of that sort really don't help you at all, unless you've already traced the program and found the hot path (and there isn't a more appropriate algorithm). –  Kitsune Feb 23 '12 at 17:19
Look at the compiled output, or time/profile a loop of millions of itterations. it will be very compiler specific. –  Dampsquid Feb 23 '12 at 17:21
In theory they are the same thing, however pow() would be slower only because when the function is called it need to be put on the stack and create copies of the data you have passed it. That being said the difference in speed would be so tiny it would be better just to use pow since then you wont have type xxxxx when you get to higher powers. –  Chris Condy Feb 23 '12 at 17:21

4 Answers 4

up vote 5 down vote accepted

There's no universal answer: you'll have to profile the code generated by your implementation to know for sure. In most cases, however, if eu_distance is in a separate translation unit, and is not specially annotated, the compiler will be unable to know that calling it twice with the same arguments will give the same results; in this case, the second form will almost surely be faster. On the other hand, If eu_distance can be inlined, any decent optimizer will end up generating almost exactly the same code for both.

In practice, I would almost certainly use a third form:

min = std::min( eu_distance( point_a, point_b ), min );

(I am supposing that eucl_distance is a typo for eu_distance.)

Also, I'd avoid a name like min. Somebody's too likely to add a using namespace std; later, or even to include <windows.h>, without hvaing defined NOMINMAX. (<windows.h> defines min and max as macros if NOMINMAX has not been defined. Which leads to some interesting error messages if you define your own min or max. Or even include <algorithm>.)

Concerning pow( x, 2 ): again, you'll really have to measure, but typically, x * x will be faster, even if x is a complicated expression. (Of course, if the expression is non trivial, then recognizing that both x are identical may not be that easy, which makes the code harder to read. In such cases, you might want to consider a small function, say squared, which does nothing but return x * x. Inline it if it makes a difference in performance.)

share|improve this answer

All questions on how optimizers treat code are hard in the sense that there are many variables that can affect the optimizer. The first part of the answer is that caching the result of the function and reusing it will not be worse than the alternative in any circumstance, so I would go ahead and use the second approach.

As of what can be optimized in the first approach, it depends on how the code is laid out. If the compiler has access to the definition of euclid_distance and it can inline it, then it can effectively determine that the function is pure and will produce the same output in the second call, so it could potentially cache the value of the first call. If the compiler does not have access to the definition of the function, then it cannot know whether the first and second calls to the function will yield the same result (consider rand(), each call will yield a different number), so it will call the function twice. You can help there by tagging the function with hints for the compiler. You can google for the __pure attribute in gcc, which if I recall correctly it will help the optimizer in this case.

On the use of pow vs. plain multiplication, again, for a power of two I would just use the direct multiplication. It is basically impossible for pow to make it more efficiently. In this case, you need not cache y.x-x.x as the compiler sees that it is reused and can do that for you.

share|improve this answer

Well, in theory this:

double dis = eucl_distance(point_a, point_b);
if (min > dis)
    min = dis;

is more efficient that this:


... just because you eliminate an additional call eucl_distance(point_a, point_b).

But if you mark your function as "pure" or if compiler can see the definition and decide that it is pure, it will eliminate an extra call to it just like it eliminates duplicate mathematical expressions, and then generate code will be nearly the same. However, you cannot always go and check assembly etc., so I'd stick with the first case, which is cleaner.

As for your piggyback question, (y.x - x.x)*(y.x - x.x) is faster (you can be more specific and store result of y - x in tmp variable)... However, compiler is well aware of pow function and since second argument is compile-time expression, it can easily unroll that code to match your manually coded multiplication. But again, you cannot really rely on you, so if you can keep the code cleaner and more obvious - do it. I don't see any reason why you would want to call pow(something, 2) for example.

And always remember that premature optimization is no good. But still, don't write crappy slow code in the first place as well :)

share|improve this answer

i would say:

  • don't assume any compiler behaviour.
  • reuse result to avoid unecessary call

nothing tells the compiler your eucl_distance function is totally idempotent.so there quite no chance it skips the extra call assuming cached result. (what if you increase a static counter variable in your call???)

for the multiplication vs pow thing, my guess is it depends on the underlying processor math optimization.

share|improve this answer

Your Answer


