私はいくつかのコードをベンチマークしていましたが、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);
}
}
これを実行すると(MacOS 上の jdk 1.8.0_144-b01)、次のように出力されます。
12089nsec/mul
2559044166
インポート行をコメント解除して実行すると、次のようになります。
4098nsec/mul
2559044166
まったく同じコードを使用している場合でも、BigInteger の JDK バージョンを使用すると、私のバージョンと比較してほぼ 3 倍高速になります。
javap でバイトコードを調べ、オプションを指定して実行したときのコンパイラ出力を比較しました。
-Xbatch -XX:-TieredCompilation -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions
-XX:+PrintInlining -XX:CICompilerCount=1
どちらのバージョンも同じコードを生成しているようです。では、hotspot は、私のコードでは使用できない事前計算された最適化を使用しているのでしょうか? 使用していないと常に理解していました。この違いを説明するものは何ですか?
ベストアンサー1
BigInteger
はい、HotSpot JVMは、Javaコードにはない特別なバージョンのメソッドを備えているため、一種の「チート」です。これらのメソッドは、JVM 組み込み関数。
特に、BigInteger.multiplyToLen
HotSpotの固有のメソッドです。特別な手動でコーディングされたアセンブリ実装JVM ソースベースですが、x86-64 アーキテクチャのみです。
オプションを使用してこの組み込み機能を無効にし、-XX:-UseMultiplyToLenIntrinsic
JVM に純粋な Java 実装の使用を強制することもできます。この場合、パフォーマンスはコピーしたコードのパフォーマンスと同様になります。
追伸:こちらはリストその他の HotSpot の固有メソッド。