Is multiplication and division using shift operators in C actually faster?

Question

Multiplication and division can be achieved using bit operators, for example

i*2 = i<<1
i*3 = (i<<1) + i;
i*10 = (i<<3) + (i<<1)

and so on.

Is it actually faster to use say (i<<3)+(i<<1) to multiply with 10 than using i*10 directly? Is there any sort of input that can't be multiplied or divided in this way?

Solution 1

Short answer: Not likely.

Long answer: Your compiler has an optimizer in it that knows how to multiply as quickly as your target processor architecture is capable. Your best bet is to tell the compiler your intent clearly (i.e. i*2 rather than i << 1) and let it decide what the fastest assembly/machine code sequence is. It's even possible that the processor itself has implemented the multiply instruction as a sequence of shifts & adds in microcode.

Bottom line--don't spend a lot of time worrying about this. If you mean to shift, shift. If you mean to multiply, multiply. Do what is semantically clearest--your coworkers will thank you later. Or, more likely, curse you later if you do otherwise.

Solution 2

Just a concrete point of measure: many years back, I benchmarked two versions of my hashing algorithm:

unsigned
hash( char const* s )
{
    unsigned h = 0;
    while ( *s != '\0' ) {
        h = 127 * h + (unsigned char)*s;
        ++ s;
    }
    return h;
}

and

unsigned
hash( char const* s )
{
    unsigned h = 0;
    while ( *s != '\0' ) {
        h = (h << 7) - h + (unsigned char)*s;
        ++ s;
    }
    return h;
}

On every machine I benchmarked it on, the first was at least as fast as the second. Somewhat surprisingly, it was sometimes faster (e.g. on a Sun Sparc). When the hardware didn't support fast multiplication (and most didn't back then), the compiler would convert the multiplication into the appropriate combinations of shifts and add/sub. And because it knew the final goal, it could sometimes do so in less instructions than when you explicitly wrote the shifts and the add/subs.

Note that this was something like 15 years ago. Hopefully, compilers have only gotten better since then, so you can pretty much count on the compiler doing the right thing, probably better than you could. (Also, the reason the code looks so C'ish is because it was over 15 years ago. I'd obviously use std::string and iterators today.)

Solution 3

In addition to all the other good answers here, let me point out another reason to not use shift when you mean divide or multiply. I have never once seen someone introduce a bug by forgetting the relative precedence of multiplication and addition. I have seen bugs introduced when maintenance programmers forgot that "multiplying" via a shift is logically a multiplication but not syntactically of the same precedence as multiplication. x * 2 + z and x << 1 + z are very different!

If you're working on numbers then use arithmetic operators like + - * / %. If you're working on arrays of bits, use bit twiddling operators like & ^ | >> . Don't mix them; an expression that has both bit twiddling and arithmetic is a bug waiting to happen.

Solution 4

This depends on the processor and the compiler. Some compilers already optimize code this way, others don't. So you need to check each time your code needs to be optimized this way.

Unless you desperately need to optimize, I would not scramble my source code just to save an assembly instruction or processor cycle.

Solution 5

Is it actually faster to use say (i<<3)+(i<<1) to multiply with 10 than using i*10 directly?

It might or might not be on your machine - if you care, measure in your real-world usage.

A case study - from 486 to core i7

Benchmarking is very difficult to do meaningfully, but we can look at a few facts. From http://www.penguin.cz/~literakl/intel/s.html#SAL and http://www.penguin.cz/~literakl/intel/i.html#IMUL we get an idea of x86 clock cycles needed for arithmetic shift and multiplication. Say we stick to "486" (the newest one listed), 32 bit registers and immediates, IMUL takes 13-42 cycles and IDIV 44. Each SAL takes 2, and adding 1, so even with a few of those together shifting superficially looks like a winner.

These days, with the core i7:

(from http://software.intel.com/en-us/forums/showthread.php?t=61481)

The latency is 1 cycle for an integer addition and 3 cycles for an integer multiplication. You can find the latencies and thoughput in Appendix C of the "Intel® 64 and IA-32 Architectures Optimization Reference Manual", which is located on http://www.intel.com/products/processor/manuals/.

(from some Intel blurb)

Using SSE, the Core i7 can issue simultaneous add and multiply instructions, resulting in a peak rate of 8 floating-point operations (FLOP) per clock cycle

That gives you an idea of how far things have come. The optimisation trivia - like bit shifting versus * - that was been taken seriously even into the 90s is just obsolete now. Bit-shifting is still faster, but for non-power-of-two mul/div by the time you do all your shifts and add the results it's slower again. Then, more instructions means more cache faults, more potential issues in pipelining, more use of temporary registers may mean more saving and restoring of register content from the stack... it quickly gets too complicated to quantify all the impacts definitively but they're predominantly negative.

functionality in source code vs implementation

More generally, your question is tagged C and C++. As 3rd generation languages, they're specifically designed to hide the details of the underlying CPU instruction set. To satisfy their language Standards, they must support multiplication and shifting operations (and many others) even if the underlying hardware doesn't. In such cases, they must synthesize the required result using many other instructions. Similarly, they must provide software support for floating point operations if the CPU lacks it and there's no FPU. Modern CPUs all support * and <<, so this might seem absurdly theoretical and historical, but the significance thing is that the freedom to choose implementation goes both ways: even if the CPU has an instruction that implements the operation requested in the source code in the general case, the compiler's free to choose something else that it prefers because it's better for the specific case the compiler's faced with.

Examples (with a hypothetical assembly language)

source           literal approach         optimised approach
#define N 0
int x;           .word x                xor registerA, registerA
x *= N;          move x -> registerA
                 move x -> registerB
                 A = B * immediate(0)
                 store registerA -> x
  ...............do something more with x...............

Instructions like exclusive or (xor) have no relationship to the source code, but xor-ing anything with itself clears all the bits, so it can be used to set something to 0. Source code that implies memory addresses may not entail any being used.

These kind of hacks have been used for as long as computers have been around. In the early days of 3GLs, to secure developer uptake the compiler output had to satisfy the existing hardcore hand-optimising assembly-language dev. community that the produced code wasn't slower, more verbose or otherwise worse. Compilers quickly adopted lots of great optimisations - they became a better centralised store of it than any individual assembly language programmer could possibly be, though there's always the chance that they miss a specific optimisation that happens to be crucial in a specific case - humans can sometimes nut it out and grope for something better while compilers just do as they've been told until someone feeds that experience back into them.

So, even if shifting and adding is still faster on some particular hardware, then the compiler writer's likely to have worked out exactly when it's both safe and beneficial.

Maintainability

If your hardware changes you can recompile and it'll look at the target CPU and make another best choice, whereas you're unlikely to ever want to revisit your "optimisations" or list which compilation environments should use multiplication and which should shift. Think of all the non-power-of-two bit-shifted "optimisations" written 10+ years ago that are now slowing down the code they're in as it runs on modern processors...!

Thankfully, good compilers like GCC can typically replace a series of bitshifts and arithmetic with a direct multiplication when any optimisation is enabled (i.e. ...main(...) { return (argc << 4) + (argc << 2) + argc; } -> imull $21, 8(%ebp), %eax) so a recompilation may help even without fixing the code, but that's not guaranteed.

Strange bitshifting code implementing multiplication or division is far less expressive of what you were conceptually trying to achieve, so other developers will be confused by that, and a confused programmer's more likely to introduce bugs or remove something essential in an effort to restore seeming sanity. If you only do non-obvious things when they're really tangibly beneficial, and then document them well (but don't document other stuff that's intuitive anyway), everyone will be happier.

General solutions versus partial solutions

If you have some extra knowledge, such as that your int will really only be storing values x, y and z, then you may be able to work out some instructions that work for those values and get you your result more quickly than when the compiler's doesn't have that insight and needs an implementation that works for all int values. For example, consider your question:

Multiplication and division can be achieved using bit operators...

You illustrate multiplication, but how about division?

int x;
x >> 1;   // divide by 2?

According to the C++ Standard 5.8:

-3- The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 divided by the quantity 2 raised to the power E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.

So, your bit shift has an implementation defined result when x is negative: it may not work the same way on different machines. But, / works far more predictably. (It may not be perfectly consistent either, as different machines may have different representations of negative numbers, and hence different ranges even when there are the same number of bits making up the representation.)

You may say "I don't care... that int is storing the age of the employee, it can never be negative". If you have that kind of special insight, then yes - your >> safe optimisation might be passed over by the compiler unless you explicitly do it in your code. But, it's risky and rarely useful as much of the time you won't have this kind of insight, and other programmers working on the same code won't know that you've bet the house on some unusual expectations of the data you'll be handling... what seems a totally safe change to them might backfire because of your "optimisation".

Is there any sort of input that can't be multiplied or divided in this way?

Yes... as mentioned above, negative numbers have implementation defined behaviour when "divided" by bit-shifting.

View more solutions

Comments

[Pascal Cuoq]

Actually, cheap division by a constant other than a power of two is possible, but a tricky subjet to which you are not doing justice with "/Division … /divided" in your question. See for instance hackersdelight.org/divcMore.pdf (or get the book "Hacker's delight" if you can).

[juanchopanza]

It sound like something that could easily be tested.

[Bo Persson]

As usual - it depends. Once upon a time I tried this in assembler on an Intel 8088 (IBM PC/XT) where a multiplication took a bazillion clocks. Shifts and adds executed a lot faster, so it seemed like a good idea. However, while multiplying the bus unit was free to fill the instruction queue and the next instruction could then start immediately. After a series of shifts and adds the instruction queue would be empty and the CPU would have to wait for the next instruction to be fetched from memory (one byte at a time!). Measure, measure, measure!

[RedX]

@Bo so it was more trouble implementing the shifted version then it was worth or did you end up using it?

[Kerrek SB]

Also, beware that right-shifting is only well-defined for unsigned integers. If you have a signed integer, it's not defined whether 0 or the highest bit are padded from the left. (And don't forget the time it takes for someone else (even yourself) to read the code a year later!)

[Bo Persson]

@Rex - No, I ended up using the multiply, because that was the fastest for the whole routine. The 8088 was limited by the 8-bit bus, so the code size was often more important than the number of clocks for each instruction.

[Peter G.]

Actually, a good optimizing compiler will implement multiplication and division with shifts when they are faster.

[FumbleFingers]

@Peter G. In the [s|b]ad old days before good optimizing compilers and fast processors, I used my own "times 10" routine (shift once & save, then shift twice more and add to saved value). Nowadays it's not worth bothering, but back then it made the difference between users getting a report out immediately, or going for a coffee break while they waited.

[someguy]

It should be mentioned that the optimization is called strength reduction.

[doug65536]

There is no such thing as "better". On an 8-pin microcontroller, you might optimize for fewer instructions. If the processor is a vector processor you might worry that you can do 16 multiplications in one instruction and need to shoehorn your algorithm into a wide vector engine. Like everyone says, make your code say what to do, not how to do it. If you happen to know that a specific code path takes 90% of your CPU time, then do this low level stuff IF measurements say it helps. Anything else is wasting time that could be spent actually optimizing things.

[supercat]

@PeterG.: I'm not sure I've ever seen a compiler where dividing a signed number by a power of 2 was not slower than doing a right shift. One could argue that if dividend will never be negative one should cast to unsigned and do the division, but that can cause quirks of its own.

[JPtheK9]

I'm a little late to this discussion but a recent test out of curiosity showed that int64 division was about 8 times slower than bitshifting but int64 multiplication was the same. Interestingly, int32 division produced about the same results as int32 bitshifting. I ran this test very impromptu in debug mode so these results might not be representative of the subject in application.

[Jens]

Just to add a rough estimation: On a typical 16-Bit processor (80C166) adding two ints comes at 1-2 cycles, a multiplication at 10 cycles and a division at 20 cycles. Plus some move-operations if you optimize i*10 into multiple ops (each mov another +1 cycle). The most common compilers (Keil/Tasking) do not optimize unless for multiplications/divisions by a power of 2.

[user703016]

And in general, the compiler optimizes code better than you do.

[Bo Persson]

The people writing compilers for those machines have also likely read the Hackers Delight and optimize accordingly.

[asawyer]

@Drew for some reason your comment made me laugh and spill my coffee. thanks.

[Joel B]

There are no random forum threads about liking math. Anyone who likes math knows how hard it is to generate a true "random" forum thread.

[Joel B]

Avoidable with simple parenthesis?

[Dave]

Yep, as said the possible gains for almost every application will totally outweigh the obscurity introduced. Don't worry about this kind of optimisation prematurely. Build what is sematically clear, identify bottlenecks and optimise from there...

[Eric Lippert]

@Joel: Sure. If you remember that you need them. My point is that it is easy to forget that you do. People who get in the mental habit of reading "x<<1" as though it were "x*2" get in the mental habit of thinking that << is the same precedence as multiplication, which it is not.

[Bo Persson]

You would have gotten a big upvote for this if you had skipped the part about the vector. If the compiler can fix the multiply it can also see that the vector doesn't change.

[Charles Goodwin]

How can a compiler know a vector size won't change without making some really dangerous assumptions? Or have you never heard of concurrency...

[Lie Ryan]

It's probably only worth it to do things like this if you have profiled and found this to be a bottleneck and implemented the alternatives and profile again and get at least 10 times performance advantage.

[Lie Ryan]

or cast the number to unsigned

[Bo Persson]

Ok, so you loop over a global vector with no locks? And I loop over a local vector who's address hasn't been taken, and call only const member functions. At least my compiler realizes that the vector size will not change. (and soon someone will probably flag us for chatting :-).

[Kerrek SB]

Are you sure that the shifting behaviour is standardized? I was under the impression that right-shift on negative ints is implementation-defined.

[Ivan Danilov]

Well, I find expression "(hi << 8) + lo" more intent-revealing than "hi*256 + lo". Probably it is a matter of taste, but sometimes it is more clear to write bit-twiddling. In most cases though I totally agree with your point.

[Eric Lippert]

@Ivan: And "(hi << 8) | lo" is even more clear. Setting the low bits of a bit array is not addition of integers. It is setting bits, so write the code that sets bits.

[Ivan Danilov]

Wow. Didn't think of it this way before. Thanks.

[Maister]

Integer multiplies are microcoded for example on PlayStation 3's PPU, and stall the whole pipeline. It's recommended to avoid integer multiplies on some platforms still :)

[Drew Hall]

Very nice answer. Core i7 vs. 486 comparison is enlightening!

[Olof Forshell]

Many unsigned divisions are - assuming the compiler knows how - implemented using unsigned multiplies. One or two multiplies @ a few clock cycles each can do the same work as a division @ 40 cycles each and up.

[Paul R]

@Olof: true, but only valid for division by a compile-time constant of course

[Pascal Cuoq]

You may be interested in the following blog post, in which the author notes that modern optimizing compilers seem to reverse-engineer common patterns that programmers might use thinking them more efficient into their mathematical forms so as to really generate the most efficient instruction sequence for them. shape-of-code.coding-guidelines.com/2009/06/30/…

[James Kanze]

@PascalCuoq Nothing really new about this. I discovered pretty much the same thing for Sun CC close to 20 years ago.

[user703016]

@BoPersson Finally, after all this time, I removed my statement about the compiler not being able to optimize away vector<T>::size(). My compiler was quite ancient! :)

[doug65536]

Agreed, optimizing for readability and maintainability will probably net you more time to spend actually optimizing things that the profiler says are hot code paths.

[supercat]

While you should perhaps mention that code which relies upon any particular behavior for right-shifting negative numbers should document that requirement, the advantage to right-shifting is huge in cases where it naturally yields the right value and the division operator would generate code to waste time computing an unwanted value which user code would then have to waste additional time adjusting to yield what the shift would have given in the first place. Actually, if I had my druthers, compilers would have an option to squawk at attempts to perform signed division, since...

[supercat]

...code which knows the operands are positive could improve optimization if it cast to unsigned before division (possibly casting back to signed afterward), and code which knows that operands might be negative should generally deal with that case explicitly anyhow (in which case one may as well assume them to be positive).

[supercat]

What would you consider the most idiomatic way of e.g. dividing a signed number (which isn't near Int32.MaxValue) by 256 with rounding? (X+128)>>8 is fast and pretty clear compared with anything I can figure using the "/" operator. Do you know any formulations using "/" which are not both harder to read and slower to execute?

[Eric Lippert]

@supercat: Slower to execute is irrelevant. Unacceptably slow is relevant, and that's a question that can only be answered by knowing what acceptable speed is. If either technique has acceptable speed then pick the one that is easier to read; if neither is acceptable then choosing the harder-to-read one does not solve the problem. The middle ground, where the hard-to-read one is acceptable but the easy-to-read one is not, is rare; if you're in that rare situation then the code is extraordinarily perf sensitive and should be well-commented.

[supercat]

@EricLippert: Even just focusing on ease of reading, do you know any nice way to compute a rounded division by 256 other than by using shift? Something like x >= 0 ? (x + 128)/256 : (x-127)/256 would seem ugly even if it performed just as well as (x+128)>>8.

[Eric Lippert]

@supercat: I must confess that the operation "divide a signed integer by 256 with rounding" I have not once had to do in my career, so I've spent no time considering how to optimize it for either readability or speed.

[supercat]

@EricLippert: Fair enough. Such things arise pretty often in the embedded-systems world (things like digital thermometers, etc.) where floating-point is expensive, and also used to be very common in graphics programming (though floating-point hardware has by now become somewhat ubiquitous). If you think 256 is an unusual value, pick any other. For example, using integer math, is there any nicer way than (a+b+c+d+2)>>2 to compute a value that is within 0.5 of the average value? That would seem a pretty normal thing to do.

[supercat]

I agree that when multiplying "quantities", the multiplication operator is generally better, but when dividing signed values by powers of 2, the >> operator is faster than / and, if the signed values can be negative, it's often semantically superior as well. If one needs the value which x>>4 would produce, that's a lot clearer than x < 0 ? -((-1-x)/16)-1 : x/16;, and I can't imagine how a compiler could optimize that latter expression to something nice.

[Drew Hall]

I agree with you, too. I follow the same guideline subconsciously, though I haven't ever had a formal requirement to do so.

[Peter Cordes]

These comments make it sound like you're giving up on potential performance from telling the compiler how to do its job. This is not the case. You actually get better code from gcc -O3 on x86 with return i*10 than from the shift version. As someone who looks at compiler output a lot (see many of my asm / optimization answers), I'm not suprised. There are times when it can help to hand-hold the compiler into one way of doing things, but this isn't one of them. gcc is good at integer math, because it's important.

[Paul Wieland]

Just downloaded an arduino sketch that has millis() >> 2; Would it have been too much to ask to just divide?

[Barleyman]

@PaulWieland Embedded processors are very different from x86 compatibles. MSP430 has neither division nor multiplication instruction. Some of them have a separate multiplication peripheral which is not lightning fast, 4 cycles for 2 16 bit values and the result is broken into 4 8-bit registers.. When you're working at 16MHz and have no fancy pipeline optimizations or predictive execution, this kind of thing starts to matter. Yes, you can leave it up to the compiler but again, you're two orders of magnitude slower than what's discussed here.

[j riv]

To be fair the readability argument is subjective. It does make perfect sense when the target is novices but to a person very experienced with binary arithmetic it might be more readable to be that way. An example might be a project that already uses a lot of binary arithmetic so it will fit better in that case - and hence become more readable - to have the few odd divisions or multiplications to be in bit arithmetic too.

[PunyCode]

+1 for the last comment. But I think it used to give some sort of overhead at a time when compilers were not as advanced as today.

[supercat]

On all commonplace architectures, intVal>>1 will have the same semantics which differ from those of intVal/2 in a way that is sometimes useful. If one needs to compute in portable fashion the value that commonplace architectures would yield for intVal >> 1, the expression would need to be rather more complicated and harder to read, and would be likely to generate substantially inferior code to that produced for intVal >> 1.

[robsn]

I tested i / 32 vs i >> 5 and i / 4 vs i >> 2 on gcc for cortex-a9 (which has no hardware division) with optimisation -O3 and the resulting assembly was exactly the same. I didn't like using divisions first but it describes my intention and the output is the same.