Math.Pow vs multiply operator (performance)

Question

Anyone knows if multiply operator is faster than using the Math.Pow method? Like:

n * n * n

vs

Math.Pow ( n, 3 )

Answer 1

A few rules of thumb from 10+ years of optimization in image processing & scientific computing:

Optimizations at an algorithmic level beat any amount of optimization at a low level. Despite the "Write the obvious, then optimize" conventional wisdom this must be done at the start. Not after.

Hand coded math operations (especially SIMD SSE+ types) will generally outperform the fully error checked, generalized inbuilt ones.

Any operation where the compiler knows beforehand what needs to be done are optimized by the compiler. These include: 1. Memory operations such as Array.Copy() 2. For loops over arrays where the array length is given. As in for (..; i<array.Length;..)

Always set unrealistic goals (if you want to).

Answer 2

This is so micro that you should probably benchmark it for specific platforms, I don't think the results for a Pentium Pro will be necessarily the same as for an ARM or Pentium II.

All in all, it's most likely to be totally irrelevant.

Answer 3

I disagree that handbuilt functions are always faster. The cosine functions are way faster and more accurate than anything i could write. As for pow(). I did a quick test to see how slow Math.pow() was in javascript, because Mehrdad cautioned against guesswork

    for (i3 = 0; i3 < 50000; ++i3) { 
      for(n=0; n < 9000;n++){ 
        x=x*Math.cos(i3);
      }
    }

here are the results:

Each function run 50000 times 

time for 50000 Math.cos(i) calls = 8 ms 
time for 50000 Math.pow(Math.cos(i),9000) calls = 21 ms 
time for 50000 Math.pow(Math.cos(i),9000000) calls = 16 ms 
time for 50000 homemade for loop calls 1065 ms

if you don't agree try the program at http://www.m0ose.com/javascripts/speedtests/powSpeedTest.html

Answer 4

I just happened to have tested this yesterday, then saw your question now.

On my machine, a Core 2 Duo running 1 test thread, it is faster to use multiply up to a factor of 9. At 10, Math.Pow(b, e) is faster.

However, even at a factor of 2, the results are often not identical. There are rounding errors.

Some algorithms are highly sensitive to rounding errors. I had to literally run over a million random tests until I discovered this.

Answer 5

Basically, you should benchmark to see.

Educated Guesswork (unreliable):

In case it's not optimized to the same thing by some compiler...

It's very likely that x * x * x is faster than Math.Pow(x, 3) as Math.Pow has to deal with the problem in its general case, dealing with fractional powers and other issues, while x * x * x would just take a couple multiply instructions, so it's very likely to be faster.

Answer 6

Let's use the convention x^n. Let's assume n is always an integer.

For small values of n, boring multiplication will be faster, because Math.Pow (likely, implementation dependent) uses fancy algorithms to allow for n to be non-integral and/or negative.

For large values of n, Math.Pow will likely be faster, but if your library isn't very smart it will use the same algorithm, which is not ideal if you know that n is always an integer. For that you could code up an implementation of exponentiation by squaring or some other fancy algorithm.

Of course modern computers are very fast and you should probably stick to the simplest, easiest to read, least likely to be buggy method until you benchmark your program and are sure that you will get a significant speedup by using a different algorithm.