May be. But this does not explain strange behavior with `if t <> 0 then t := PopCnt(t);`

The comparison test is a single cycle on most cpu's , popcnt takes at least three, so testing for zero optimizes a little here.

Yes - a little, but not from 15s to 6.5s. It's impossible.

Hi julkas - from my perspective it is very well possible, as the difference simply relates to the number of 0s detected. You seem to calculate the hamming distance over two arrays. If the arrays are held on heap and are not preset with random values prior to calculation then the run-time will be erratic, depending on the values found in the uninitialized heap. If your code uses variant arrays which get sized but again not preset prior to calculation then the array content is explicitely 0. There are other, more theoretical, explanations on the runtime difference.

@MathMan thank you for reply.

But, I have only one line of code with RTL PopCnt - time is 15s

Inc(c, PopCnt(a.bs[i] and b.bs[i]));

I replace call to RTL PopCnt with my own pure Pascal (NOT ASM) function PopCount - now time is 7s.

function PopCount(x: QWORD): SizeInt; inline;

begin

Result := 0;

while x <> 0 do

begin

Inc(Result);

x := x and (x - 1);

end;

end;

...

Inc(c, PopCount(a.bs[i] and b.bs[i]));

Is it normal behavoir ? And finally, RTL PopCnt with

`if t <> 0 then t := PopCnt(t);` test runs as my PopCount version (without if test).

If test excludes zero value call (PopCnt(0) = 0)!

Thanks.