Basically I converted the problem to the lowest level with a consistent pattern, which happen if you work on the problem in nibbles (4-bits). Then breaking that down into quadrant and the 2 least significant bits, their counts follow the patten 0, 1, 1, 2 respectively, which can be treated as the if case “return (v == 0) ? 0 : v == 2 ? 2 : 1″ which is quick.

Then these “quadrants” which are really the 2 most significant bits, can be added separately through a similar set of if statements: “return (v < 4) ? 0 : v >= 12 ? 2 : 1″ which is actually the same pattern as the lower bits, but skipping the bit shifting by comparing different numbers.

I think it's clear where to go from here… I just break out each nibble with another overloaded method of each bit level… 8bits, 16, 32, and 64 and I get the value I need for all types.

So each nibble is taking 5 ifs, 1 and, 2 adds… which are all likely to be single opcode operations. If we can optimize the nibble code further, then the rest of the algorithm with also be improved.

So the 32 bit case is Count(v & 0x0000FFFF) + Count(v & 0xFFFF0000 >> 16) for example, so the 32 bit case calling each of the methods, you end up with 8 nibble calls, 4 char call, 2 short calls for that one int32 call (I'm using c#) so I'd bet the method calls are the thing taking the most time, which could also be rolled out for better performance, like the good old Apple II programming days :)

So my algorithm is definitely O(1) since I don't loop, and since splitting the problem to each lower bit-level takes 2 ANDs, 1 SHIFT-RIGHT, and 1 ADD, I'd venture to say the total number of opcodes if we don't consider the call stack and method calls would be 4 operations per split, and we're splitting 7 times and running 8 nibbles…

— 7*4 + 8*8 = 64 + 28 = 92
I think I'm looking at a fixed set of 92 operations to achieve this. This definitely takes less RAM than having an array of 4 billion elements. Perhaps a lookup table on the nibbles or byte level would hit a better memory/cpu sweet spot.

Also seems like these 92 very simple opcodes would be something the processor could pipeline fairly well and perhaps become one of those rare instances where you can get more than 1 opcode per cycle on average. I don't know if this is really much more efficient, but I bet there's a way to implement this line of reasoning on super long arrays that could be computed using scalar/SSE instructions.

simple steps
int count_bit(int num)
{
count =0;
while(num)
{
num=(num) & (num-1);
count++;
}
return count;
// complete program will be available in
// http://goursaha.freeoda.com
}

Using VHDL :) in hardware level (like CRC32 computation). All can be done in one instruction like it do real routers :)

http://www.cs.utk.edu/~vose/c-stuff/bithacks.html#CountBitsSetParallel

This version doesn’t use a for loop so that you can clearly see the c*log_2{n} == c*5 steps (for n=32). Easily changed to accomodate counting bits set for 64 bit integers of course.

Another interesting solution, which is faster than the naive solution only for integers where the bits set are few, is here:

http://www.cs.utk.edu/~vose/c-stuff/bithacks.html#CountBitsSetKernighan

for ( i = 0; (1<<i) < 32; i++) n = ((n & ~masks[i]) > > (1<<i)) + (n & masks[i]);

int bitcount(unsigned int n) {
    unsigned int i, masks[] = {0x55555555, 0x33333333, 0x0F0F0F0F, 0x00FF00FF, 0x0000FFFF};
    for ( i = 0; (1<<i) > (1<<i)) + (n & masks[i]);
    return n;
}

(I hope it survives wordpress’ munging)

Creating the bitmasks programatically, to make it independent of int size, is left as a trivial exercise for the reader.