我正在对一些代码进行基准测试,我无法让它运行得像java.math.BigInteger
一样快,即使使用完全相同的算法也是如此。因此,我将java.math.BigInteger
源代码复制到我自己的包中,并尝试执行以下操作:
//import java.math.BigInteger;
public class MultiplyTest {
public static void main(String[] args) {
Random r = new Random(1);
long tm = 0, count = 0,result=0;
for (int i = 0; i < 400000; i++) {
int s1 = 400, s2 = 400;
BigInteger a = new BigInteger(s1 * 8, r), b = new BigInteger(s2 * 8, r);
long tm1 = System.nanoTime();
BigInteger c = a.multiply(b);
if (i > 100000) {
tm += System.nanoTime() - tm1;
count++;
}
result+=c.bitLength();
}
System.out.println((tm / count) + "nsec/mul");
System.out.println(result);
}
}
当我运行这个(jdk 1.8.0_144-b 01在MacOS上)它输出:
12089nsec/mul
2559044166
当我在导入行未注解的情况下运行它时:
4098nsec/mul
2559044166
即使使用完全相同的代码,使用JDK版本的BigInteger的速度也几乎是我的版本的三倍。
我已经用javap检查了字节码,并比较了使用选项运行时的编译器输出:
-Xbatch -XX:-TieredCompilation -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions
-XX:+PrintInlining -XX:CICompilerCount=1
而且两个版本似乎生成了相同的代码。那么,hotspot是否使用了一些我无法在代码中使用的预先计算的优化?我一直认为它们不会。如何解释这种差异?
2条答案
按热度按时间whitzsjs1#
是的,HotSpot JVM是一种“欺骗”,因为它有一些
BigInteger
方法的特殊版本,这些方法在Java代码中是找不到的,它们被称为JVM intrinsics。具体来说,
BigInteger.multiplyToLen
是HotSpot中的一个内部方法,JVM源代码库中有一个特殊的手工编码的汇编实现,但仅适用于x86-64架构。您可以使用
-XX:-UseMultiplyToLenIntrinsic
选项禁用此内部函数,以强制JVM使用纯Java实现。在这种情况下,性能将与复制的代码的性能相似。erhoui1w2#
在Java8中,这确实是一个内部方法;该方法的稍微修改的版本:
使用以下项运行:
这将打印许多行,其中一行将是:
另一方面,在Java 9中,该方法似乎不再是内部函数,但反过来它调用的方法是内部函数:
因此,在Java 9下运行相同的代码(使用相同的参数)将显示:
下面是相同的方法代码,只是命名略有不同。