Base on the answers i've got, i think this problem is kind of meaningless. Thanks for all your kind replies!
i want to get a binary number with its rightmost j bits set to 1 and others set to be 0. basically, there are two methods. i wanna know which of them is more efficient, or is there a more efficient way than these two?
1. ~(~0 << j)
2. (1 << j) - 1
Not sure if it's the answer you're looking for, but I'll bet it won't make more than a nanosecond of difference. :)
Or, to put it another way: Don't micro-optimize it unless that one-liner is the bottleneck in your code.
If you need other forms of fast bit manipulation that might actually be slower, try looking at the compiler intrinsic functions, like _BitScanForward. Those might actually make your bit operations faster, when used correctly (but not in a situation like this).
You are micro-optimising. Your compiler knows the best translation for those operations. Just write the one that looks the cleanest to the human eye, and move on.
In addition to the comments already posted:
In addition to benchmarking, examine the assembler that's emitted. The optimiser might have produced the same code for each....
This is sort of a lazy answer, but have you tried writing a trivial program like the following? Sure it is micro-optimizing, but it might be fun and interesting to see if there is any difference.
#include <ctime>
main()
{
int i;
time_t start = time();
for (i = 0; i < 1000000; i++)
{
// your operation here
}
time_t stop = time();
double elapsed = difftime(stop, start);
}
If you really want the fastest, use a lookup table:
const unsigned numbers[] = {
0x00000000,
0x00000001, 0x00000003, 0x00000007, 0x0000000f,
0x0000001f, 0x0000003f, 0x0000007f, 0x000000ff,
0x000001ff, 0x000003ff, 0x000007ff, 0x00000fff,
0x00001fff, 0x00003fff, 0x00007fff, 0x0000ffff,
0x0001ffff, 0x0003ffff, 0x0007ffff, 0x000fffff,
0x001fffff, 0x003fffff, 0x007fffff, 0x00ffffff,
0x01ffffff, 0x03ffffff, 0x07ffffff, 0x0fffffff,
0x1fffffff, 0x3fffffff, 0x7fffffff, 0xffffffff};
unsigned h(unsigned j) {
return numbers[j];
}
Extending this to 64 bits is left as an exercise for the reader. And as others have said, none of this matters.
Unless you change 0 to 0U, the expression ~(~0 << j) has implementation-specific behavior based on bit patterns. On the other hand, the expression (1 << j) - 1 is purely arithmetic and has no bit arithmetic in it, so it's value is well-defined across all implementations. Therefore, I would always use the latter.
The true answer is probably dependent on processor architecture. But for all intents and purposes it's almost certainly irrelevant. Also consider that your complier may output the same assembly either way. If you truly need to know, benchmark it, although the difference will almost certainly be too small to measure (which is your answer, it doesn't matter).
No timing experiments necessary, just check the generated machine code. You'll find that gcc compiles them both to identical machine instructions.
