我最近对Integer.bitCount做了一些调查。 我发现一个有趣的结果,即使代码是相同的,Integer.bitCount也比我自己的func快得多。
我认为是由于JIT引起的,但是我检查了文档,发现JIT基于运行时策略。这让我感到困惑。
public static void main(String[] args) {
long sum = 0;
long start, end;
start = System.currentTimeMillis();
for (int i = Integer.MIN_VALUE; i != Integer.MAX_VALUE; i++) {
sum += bitCount(i);
//sum += Integer.bitCount(i);
}
end = System.currentTimeMillis();
System.out.println(sum);
System.out.println(end - start);
}
private static int bitCount(int i) {
i = i - ((i >>> 1) & 0x55555555);
i = (i & 0x33333333) + ((i >>> 2) & 0x33333333);
i = (i + (i >>> 4)) & 0x0f0f0f0f;
i = i + (i >>> 8);
i = i + (i >>> 16);
return i & 0x3f;
}
//表示bitCount结果
68719476736
8715
//用于Integer.bitCount结果
68719476736
1892
答案 0 :(得分:4)
Your benchmark is not accurate.但无视此,一个原因是因为Integer#bitCount
被标记为@HotSpotIntrinsicCandidate
。这意味着HotSpot JVM可以用汇编代码替换方法主体以提高性能。从注释的source code:
@HotSpotIntrinsicCandidate
注释特定于HotSpot虚拟机。它指示HotSpot VM可能会(但不保证会)引入带注释的方法。如果HotSpot VM用手写的程序集和/或手写的编译器IR(编译器固有的)替换注释的方法以提高性能,则该方法会被激化。@HotSpotIntrinsicCandidate
注释是Java库的内部注释,因此不应与应用程序代码相关。
尝试disabling intrinsics并再次运行测试;您应该会看到速度显着下降。