I'm developing a IMHO very interesting algorithm for integer division. This algorithm uses boolean shifting(It shifts left for multiplication by 2). I'm wondering if << c is $O(c)$ or $O(n)$. I'm hearing it depends on architecture. Algorithms ideally should be architecture independent. So for the purposes of analysing the time complexity of my algorithm, should I consider << c as 1 primitive operation or c primitive operations.

I've looked at the other questions here, and they are saying it depends on the machine.

I'm using RAM model of computation, but don't want to assign << c a cost of 1 when it may in fact cost c.

  • $\begingroup$ Of course it depends on the architecture. You have to check your CPU vendors manual to see how many cycles a shift takes. $\endgroup$
    – adrianN
    Dec 28 '16 at 14:45

Most of architectures use a single instruction for left and right shift.

Usually, this instruction (WLOG we condier only logical shift left) is LSL, the syntax is the following:

lsl $rd,$rs,#$offset

where rd is the registry in which load the variable, rs is the registry in which store the result and #offset is the number of bit to shift.

So you could consider the left or right shift operation as taking $O(1)$, because this operation takes only a single CPU's clock.

  • $\begingroup$ Sorry, don't know what 'WLOG' means. $\endgroup$ Dec 28 '16 at 13:22
  • $\begingroup$ Without loss of generality $\endgroup$
    – darioSka
    Dec 28 '16 at 13:23

In the RAM machine model, operations on "machine words" cost $O(1)$, where a machine word has width $O(\log n)$ bits, $n$ being the length of the input (in bits). This reflects the instruction sets of real world CPUs, as mentioned in the other answers.

While the RAM machine model makes sense for many algorithmic tasks, it is not a good fit for large integer arithmetic, since in practice the machine word is fixed while the integer length is growing. Instead, one usually measures bit operations. Shifting an $m$-bit integer by $c$ bits takes $O(m+c)$ bit operations.

These issues are explored in a paper of Martin Fürer, the inventor of the fastest known integer multiplication algorithm (which is also the fastest known integer division algorithm).

  • 3
    $\begingroup$ Fürer's algorithm is no longer the fastest known. ​ ​ $\endgroup$
    – user12859
    Dec 29 '16 at 0:49
  • $\begingroup$ I disagree with your analysis of shifting. To shift an $m$ bit integer by $c$ bits, I would need at most $c$ bit operations. To expand, shifting right by $c$ bits, is deleting the $c$ most significant bits. Shifting left by $c$ bits, is simply adding $c$ trailing 0s, so all in all $c$ operations. I guess the time complexity of shifting is $O(c)$ then. $\endgroup$ Dec 29 '16 at 15:41
  • $\begingroup$ @TobiAlafin We will have to disagree. $\endgroup$ Dec 29 '16 at 22:41
  • $\begingroup$ I'm not against disagreeing. But please at least explain why you disagree? Is there a fault in my argument? $\endgroup$ Dec 29 '16 at 22:55
  • 1
    $\begingroup$ @TobiAlafin it depends on how you implement arrays. The usual implementation doesn't allow you to add elements on both sides for free, but you could use an alternative implementation. $\endgroup$ Dec 30 '16 at 8:14

On most modern CPU architectures, such as an i5 or i7, bitshifting isn't only constant time, it's typically done in just a couple clock cycles max. It's generally considered one of the fastest operations you can do.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.