What's the point of bitshift?

[Ryan]

Aren't the bitshift operators pointless?

a << b is the same as a = a * 2^b;
a >> b is the same as a = a % 2^b;

I've run some tests and the bitshift operators aren't any faster than
their equivalent math expressions.

R

 

[Stefan Schulz]

Aren't the bitshift operators pointless?

a << b is the same as a = a * 2^b;
a >> b is the same as a = a % 2^b;

I've run some tests and the bitshift operators aren't any faster than
their equivalent math expressions.

First of all, they are a lot shorter to write. Also, they are much more
expressive. They speak to you about what happens. So they are
good. Following your train of thought, you might also argue that we can
throw away all equality operations safe <=

Also, the bit shifts are usually faster then the math expressions. If you
are very lucky, the JVM realizes that it can inline the
Math.pow() calls, and implement the Math.pow() calls as bit shifts. This
is why you get same performance. Try that with any other power, and you'll
take a severe hit.

 

[Dotty]

Aren't the bitshift operators pointless?

a << b is the same as a = a * 2^b;
a >> b is the same as a = a % 2^b;

I've run some tests and the bitshift operators aren't any faster than
their equivalent math expressions.

R

Did you try negative numbers?
int c = -5;
int a = 2^c;
System.out.println(a);
-7

 

[Alan Krueger]

I'm going to assume (perhaps wrongly) that this isn't a troll.

Aren't the bitshift operators pointless?

a << b is the same as a = a * 2^b;

I think you meant "a <<= b".

a >> b is the same as a = a % 2^b;

I think you meant "a >>= b" and "a = a / 2^b".

Except that the ^ operator doesn't appear to do what you think: it's not
exponentiation, it's an exclusive-or operator.

I've run some tests and the bitshift operators aren't any faster than
their equivalent math expressions.

I wonder what that code looks like? Did you test the results that came
back?

When I run a quick million-cycle test of these two, the second method
using Math.pow gives takes about ten times as long to run. This makes
sense, given the complexity of the code involved. For a sample, see:

http://www.devdaily.com/scw/c/cygwin/src/winsup/mingw/mingwex/math/pow.c.shtml

Implementation of bit-shift operators, on the other hand, is usually as
simple as a single machine instruction.

Note that the expansions you give only work with a subset of the domain
values. For instance, -1 >> 1 == -1 not 0.

 

[Rusty Wright]

Because for some stuff you want to shift some pattern of bits a
certain way and not have to figure out what number that pattern of
bits represents, and what power of 2 the shift represents. For
example, if you're fiddling with bits in a hardware register that
controls some device.

In my C days I would use some defines for bit positions:

# define BIT0 (1 << 0)
# define BIT1 (1 << 1)
# define BIT2 (1 << 2)
etc.

Then I could turn on a specific bit or bits with something like

reg |= BIT0 | BIT2;

And sometimes it made more sense (at least to mea, at the time) to
shift the building-block bits rather than specify the final bits:

reg |= (BIT0 | BIT1) << 3;

The c compiler will compute and generate the actual constant for that
final bit pattern at compile time, since everything is a constant.

Or, you want to shift and mask:

reg2 = (reg1 << 4) & 0xf0;

Hex 0xf0 is the high nibble (4 bits) of a byte, so we're shifting the
lower 4 bits up, and masking to make sure we have only those 4 bits.

Also, think about what happens when you shift bits so far to the left
that some of the high-order bits fall off the left end; can you get
that behaviour with the math expressions? (I really don't know; math
was never one of my strengths.)