Compare multiplication and division

Question

I want to know if there is any difference in speed between the following two methods

#include<math.h>
#include<iostream>
using namespace std;

int main()
{
    float k=7;
    float b=4;
    cout<<(float)k/b<<" "<<endl;
    cout<<(float)(k*powf(b,-1))<<" "<<endl;

    return 0;
}

trivial diivision k/b
using multiplication k*b^(-1),

I think that in second method, there is not actual division procedure. So I think the second is faster. Am I right?

Typically, on most architectures, division is slower than multiplication. But seriously, the best way to get an answer is to just time it yourself. — Charles Salvia, Apr 16 '12 at 19:12
The / operator must be faster than powf, because don't make a CALL to a function... — DGomez, Apr 16 '12 at 19:12
Your question is misleading, since option 2) contains a call to powf() which is probably more expensive than division and multiplication. — Frank Schmitt, Apr 16 '12 at 19:14
This is a question to ask a compiler. StackOverflow is not a human-powered compiler. Draw your conclusions. — R. Martinho Fernandes, Apr 16 '12 at 19:14
All simple arithmetic operations are on average much faster than the IO bound stream operations. So if you want to compare, you'll need to put a lot of each ot them in a seperate, ideally unrolled loop, and _not_ send the value to `cout` on each iteration but only some final result, to make sure not all of it is simply optimised away by the compiler. — leftaroundabout, Apr 16 '12 at 19:15
@DGomez Not necessarily true, since powf() might be inlined. — Frank Schmitt, Apr 16 '12 at 19:15
i have done ,using loop over million times,but no difference i got — dato datuashvili, Apr 16 '12 at 19:22

score 4 · Answer 1 · answered Apr 16 '12 at 19:18

Chances are pretty good that you're wrong. Even if the compiler can generate powf as an intrinsic (i.e., generate inline code for it), N^-1 is equivalent to 1/N, so you're just doing the division in a more roundabout fashion. If raising to a power was a faster way to do division, the compiler would probably already generate code to do it that way.

On the other hand, if you're doing a lot of division using the same denominator, you might gain something by turning a loop like:

for (int i=0; i<some_size; i++)
    somearray[i] /= denom;

into:

double scale = 1.0/denom;

for (int i=0; i<some_size; i++)
    somearray[i] *= scale;

Of course, the compiler might be smart enough to do that as well, but at least with something like this, what you're doing stands a decent chance of being an improvement -- the only question is whether the compiler is already doing it for it for you.

score 2 · Answer 2 · answered Apr 16 '12 at 19:20

You should profile both versions and check which one's faster, but I'm almost prepared to eat my hat if it's the second, for several reasons:

powf is a general function that is very slow for typical values of the exponent parameter. Even if it's optimized to handle the case -1 specially, there will still be ifs, etc, checking for this special case, which will add overhead to the computation.
Depending on the implementation, powf may not be inlined, and you will incur the cost of the function call.
If k*(1.0/b) were really faster than k/b, then the compiler would optimize the latter into the former already (especially when specifying compiler flags to allow fast, but not necessarily perfectly IEEE-compliant, floating-point math.)

The bottom line is that modern compilers are extremely good at performing microoptimizations; I wouldn't dream of tryings "tricks" like this one unless profiling and disassembly showed clear evidence the compiler was doing something inefficient.

score 1 · Answer 3 · answered Apr 16 '12 at 19:15

1

Speed always depends on how well your compiler optimizes. So, a reliable answer can only be found by measuring.

However, the second method implies more calls than the first. Therefore, I guess the first will be faster.

answered Apr 16 '12 at 19:15

bjhend

1,424
9
22

score 1 · Accepted Answer · answered Apr 16 '12 at 19:17

1

Calculating b^(-1) isn't trivial, and will sometimes (though not always) be converted to 1/b by an optimizer. Just as much, an optimizer might switch *b^(-1) with /b. This is probably hardware-dependent (and possibly even number-dependent, if numbers are known in compilation time).

If you want to test it, put each one in a loop that runs many times (don't print anything to the screen), and time each execution.

Also note that in some cases, these 2 methods will give you slightly different results, if you're interested in precise computation.

answered Apr 16 '12 at 19:17

Eran Zimmerman Gonen

4,250
1
17
30

i have looped it,also increase values of k and b to 7000 and 4000,no difference – dato datuashvili Apr 16 '12 at 19:24
@dato Make enough iterations so that you at least pass the 20 seconds mark with one of the loops. If you did so and there's still no difference - then either they really do take (roughly) the same time, or the optimizer turned one into the other. – Eran Zimmerman Gonen Apr 16 '12 at 19:28
somebody is downloading without any sense,but i am studing from my questions,please be more curious – dato datuashvili Apr 17 '12 at 07:44

score 1 · Answer 5 · answered Apr 16 '12 at 19:25

As others have stated, profile. In computer science, division may be implemented by repetitive subtraction. Which may be faster than multiplication by the inverse.

I believe that division would be faster than multiplying by the inverse since the inverse has to be calculated first, then multiplication performed. So while division is performing subtractions, the other method is determining the inverse. After the inverse is calculated, multiple shifts and adds (multiplication) must be performed.

See Wikipedia article on division algorithm

score 1 · Answer 6 · answered Apr 16 '12 at 19:33

Using gcc -O2 on my x86-64 machine, k / b translates to one instruction:

divss   xmm0, xmm1

The 'powf' way results in the following:

movss   xmm2, DWORD PTR .LC0[rip]
divss   xmm2, xmm1
mulss   xmm2, xmm0
movaps  xmm0, xmm2

where .LC0 is 1065353216, or 1.0f.

So it would seem to me that, at least for the x86-64 machines that are common nowadays, k / b is faster.

Compare multiplication and division

6 Answers6

Linked

Related