Fastest way to measure Hamming distance of integers

I am looking for a fast and robust way to calculate the Hamming distance of integers. The Hamming distance of two integers is the number of matching bits in their binary representations. I expect that clever methods can easily outpace HammingDistance as it works on vectors instead of integers and on any vector not just binary.

My naive bitwise method is faster than HammingDistance but I'm pretty sure that it can be further optimized. While compilation would help, it won't work on big integers ($\ge 10^{19}$). Nevertheless, I am interested in compiled solutions!

max = 10^10;
n = Length@IntegerDigits[max, 2];
data = RandomInteger[{0, max}, {100000, 2}];
m1 = Map[HammingDistance[IntegerDigits[First@#, 2, n],
IntegerDigits[Last@#, 2, n]] &, data]; // AbsoluteTiming
m2 = Map[Total@IntegerDigits[BitXor @@ #, 2] &, data]; // AbsoluteTiming
m1 === m2

{0.967202, Null}
{0.624001, Null}
True


It would be nice to work entirely on the binary representations, and I thought that using DigitCount on BitXor would help, but it gave a cruel 3x slowdown compared to the HammingDistance version.

Edit

As an answer to Kirma's comment: I have to calculate the pairwise distance matrix for a set of integers (highly related is Szabolcs's post: Fastest way to calculate matrix of pairwise distances), in the (simplest and most didactive) form:

Outer[hamming[#1, #2], Range[2^20], Range[2^20]]


Now in this case my main problem is of course memory not speed, but it would be nice to see solutions that scale well with this problem. I understand that it is another question, but I want to encourage everyone to post their solutions even if they require vectors or matrices of integers as input.

-
No idea why, but replacing Total with Tr in your definition of m2 gives you a ~20% improvement in speed (on my machine). –  gpap Apr 16 '13 at 19:09
@gpap Tr is often a bit faster than Total on packed arrays, at least in version 7. I'm assuming that's the case here. –  Mr.Wizard Apr 16 '13 at 19:49
If you can easily transpose or concatenate your data to consist of few really big integers (even hundreds of millions of binary digits) instead of many smaller ones, both Tr@IntegerDigits is faster and DigitCount is entirely feasible. Speedup may be even 400-fold. –  kirma Apr 16 '13 at 21:51
@kirma Please consider posting your approach in light of my edit. –  István Zachar Apr 17 '13 at 9:07
@IstvánZachar Sadly enough, I don't believe this is generalizable to your situation. –  kirma Apr 17 '13 at 11:37

Here is another compiled implementation:

hammingDistanceCompiled = Compile[{{nums, _Integer, 1}},
Block[{x = BitXor[nums[[1]], nums[[2]]], n = 0},
While[x > 0, x = BitAnd[x, x - 1]; n++]; n
],
RuntimeAttributes -> Listable, Parallelization -> True,
CompilationTarget -> "C", RuntimeOptions -> "Speed"
];


This appears to outperform the naive approach (Total@IntegerDigits[BitXor @@ nums, 2], as presented in Leonid's answer) by about 2.5 times. If we are serious about compiled approaches, though, we can surely do much better, by taking advantage of the SSE4.2 POPCNT instruction.

Edit: thanks to halirutan, who told me that the pointers returned by the LibraryLink functions are safe to use directly, this updated version is nearly twice as fast (on my computer) as the original attempt due to the removal of unnecessary function calls from the inner loop.

Since nobody else apparently wanted to write an answer using that suggestion, I decided to give it a try myself:

#include "WolframLibrary.h"

DLLEXPORT
mint WolframLibrary_getVersion() {
return WolframLibraryVersion;
}

DLLEXPORT
int WolframLibrary_initialize(WolframLibraryData libData) {
return 0;
}

DLLEXPORT
void WolframLibrary_uninitialize() {
return;
}

inline
mint hammingDistance(mint a, mint b) {
return (mint)__builtin_popcountll((unsigned long long)a ^ (unsigned long long)b);
}

"hammingDistance_I_I", {Integer, Integer}, Integer
] */

DLLEXPORT
int hammingDistance_I_I(WolframLibraryData libData,
mint argc, MArgument *args,
MArgument res) {
mint a, b;

if (argc != 2) return LIBRARY_DIMENSION_ERROR;

a = MArgument_getInteger(args[0]);
b = MArgument_getInteger(args[1]);

MArgument_setInteger(res, hammingDistance(a, b));
return LIBRARY_NO_ERROR;
}

"hammingDistance_T_T", {{Integer, 2, "Constant"}}, {{Integer, 1, Automatic}}
] */

DLLEXPORT
int hammingDistance_T_T(WolframLibraryData libData,
mint argc, MArgument *args,
MArgument res) {
MTensor in, out;
const mint *dims;
mint i, *indata, *outdata;
int err = LIBRARY_NO_ERROR;

in = MArgument_getMTensor(args[0]);
if (libData->MTensor_getRank(in) != 2) return LIBRARY_DIMENSION_ERROR;
if (libData->MTensor_getType(in) != MType_Integer) return LIBRARY_TYPE_ERROR;
dims = libData->MTensor_getDimensions(in);
if (dims[1] != 2) return LIBRARY_DIMENSION_ERROR;
indata = libData->MTensor_getIntegerData(in);

err = libData->MTensor_new(MType_Integer, 1, dims, &out);
if (err != LIBRARY_NO_ERROR) return err;
outdata = libData->MTensor_getIntegerData(out);

#pragma omp parallel for schedule(static)
for (i = 0; i < dims[0]; i++) {
outdata[i] = hammingDistance(indata[2*i], indata[2*i + 1]);
}

MArgument_setMTensor(res, out);
return LIBRARY_NO_ERROR;
}


We compile it, using gcc (N.B. __builtin_popcount is a gcc extension):

gcc -Wall -fopenmp -O3 -march=native -shared -o hammingDistance.dll hammingDistance.c


hammingDistance = LibraryFunctionLoad[
"hammingDistance.dll",
"hammingDistance_I_I", {Integer, Integer}, Integer
];
"hammingDistance.dll",
"hammingDistance_T_T", {{Integer, 2, "Constant"}}, {Integer, 1, Automatic}
];


Make sure everything is working:

data = RandomInteger[{0, 2^63 - 1}, {10000, 2}];
hammingDistance @@@ data ===
hammingDistanceListable[data] ===
hammingDistanceCompiled[data] ===
Tr /@ IntegerDigits[BitXor @@@ data, 2]
(* -> True *)


Now for a performance comparison:

dataLarge = RandomInteger[{0, 2^63 - 1}, {10000000, 2}];
hammingDistanceCompiled[dataLarge]; // AbsoluteTiming (* 1.203125 seconds *)
hammingDistanceListable[dataLarge]; // AbsoluteTiming (* 0.063594 seconds *)


That's about 1000 times faster than the code given in the question, so not bad. I'm using an Intel Core 2 CPU, which doesn't actually support the POPCNT instruction, and has only four cores. On more recent CPUs, it will surely be faster still.

-
Nice, Mathematica-version of the Wegner implementation. –  István Zachar Apr 16 '13 at 20:01
What about using k = 0; FixedPoint[(k++; BitAnd[#, # - 1]) &, BitXor @@ nums, SameTest -> (! Positive[#2] &)]; k within the compiled function? –  Guess who it is. Apr 16 '13 at 23:36
@J.M. do you find that this gives an improvement? I admit haven't tried it but I'd be really surprised if the bytecode was any better than that produced for a While loop. –  Oleksandr R. Apr 17 '13 at 2:06
Limited tests seem to show that they're about the same, so I suppose your version is preferred for being a bit more straightforward. BTW, any reason why you're taking a list of two integers instead of having it be a function with two arguments? –  Guess who it is. Apr 17 '13 at 2:14
@J.M. this approach allows the function to be Listable, which is a prerequisite for auto-parallelization. –  Oleksandr R. Apr 17 '13 at 2:17

On my machine this is twice as fast as your m2 code:

m3 = Tr /@ IntegerDigits[BitXor @@@ data, 2];

m2 === m3


True

-