Multiply by 0.5 rather than divide by 2

Question

While I was reading tips in C, I have seen this tip here http://www.cprogramming.com/tips/tip/multiply-rather-than-divide but I am not sure. I was told both multiply and divide are slower and time consuming and requires many cycles.

and I have seen people often use i << 2 instead of i x 4 since shifting is faster.

Is it a good tip using x0.5 or /2 ? or however modern compilers do optimize it in a better way?

Answer 1

It's true that some (if not most) processors can multiply faster than performing a division operation, but, it's like the myth of ++i being faster than i++ in a for loop. Yes, it once was, but nowadays, compilers are smart enough to optimize all those things for you, so you should not care about this anymore.

And about bit-shifting, it once was faster to shift << 2 than to multiply by 4, but those days are over as most processors can multiply in one clock cycle, just like a shift operation.

A great example of this was the calculation of the pixel address in VGA 320x240 mode. They all did this:

address = x + (y << 8) + (y << 6)

to multiply y with 320. On modern processors, this can be slower than just doing:

address = x + y * 320;

So, just write what you think and the compiler will do the rest :)

Answer 2

I find that this service is invaluable for testing this sort of stuff:

http://gcc.godbolt.org/

Just look at the final assembly. 99% of the time, you will see that the compiler optimises it all to the same code anyway. Don't waste the brain power!

In some cases, it is better to write it explicitly. For example, 2^n (where n is a positive integer) could be written as (int) pow( 2.0, n ) but it is obviously better to use 1<<n (and the compiler won't make that optimisation for you). So it can be worth keeping these things in the back of your mind. As with anything though, don't optimise prematurely.

Answer 3

1. "multiply by 0.5 rather than divide by 2" (2.0) is faster on fewer environments these days than before, primarily due to improved compilers that will optimize the code.

2. "use i << 2 instead of i x 4" is faster in fewer environments for similar reasons.

3. In select cases, the programmer still needs to attend to such issues, but it is increasingly rare. Code maintenance continues to grow as a dominate issue. So use what makes the most sense for that code snippet: x*0.5, x/2.0, half(x), etc.

4. Compilers readily optimize code. Recommend you code with high level issues in mind. E. g. Is the algorithm O(n) or O(n*n)?

5. The important thought to pass on is that best code design practices evolve and variations occur amongst environments. Be adaptable. What is best today may shift (or multiply) in the future.