75

私たちはレイテンシーの影響を受けやすいアプリケーションに取り組んでおり、あらゆる種類のメソッドを ( jmhを使用して) マイクロベンチマークしています。ルックアップ メソッドをマイクロベンチマークし、結果に満足した後、最終バージョンを実装しましたが、最終バージョンはベンチマークしたばかりの 3 倍遅いことがわかりました。

enum原因は、実装されたメソッドがではなくオブジェクトを返していたことintです。以下は、ベンチマーク コードの簡略化されたバージョンです。

@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Thread)
public class ReturnEnumObjectVersusPrimitiveBenchmark {

    enum Category {
        CATEGORY1,
        CATEGORY2,
    }

    @Param( {"3", "2", "1" })
    String value;

    int param;

    @Setup
    public void setUp() {
        param = Integer.parseInt(value);
    }

    @Benchmark
    public int benchmarkReturnOrdinal() {
        if (param < 2) {
            return Category.CATEGORY1.ordinal();
        }
        return Category.CATEGORY2.ordinal();        
    }


    @Benchmark
    public Category benchmarkReturnReference() {
        if (param < 2) {
            return Category.CATEGORY1;
        }
        return Category.CATEGORY2;      
    }


    public static void main(String[] args) throws RunnerException {
            Options opt = new OptionsBuilder().include(ReturnEnumObjectVersusPrimitiveBenchmark.class.getName()).warmupIterations(5)
                .measurementIterations(4).forks(1).build();
        new Runner(opt).run();
    }

}

上記のベンチマーク結果:

# VM invoker: C:\Program Files\Java\jdk1.7.0_40\jre\bin\java.exe
# VM options: -Dfile.encoding=UTF-8

Benchmark                   (value)   Mode  Samples     Score     Error   Units
benchmarkReturnOrdinal            3  thrpt        4  1059.898 ±  71.749  ops/us
benchmarkReturnOrdinal            2  thrpt        4  1051.122 ±  61.238  ops/us
benchmarkReturnOrdinal            1  thrpt        4  1064.067 ±  90.057  ops/us
benchmarkReturnReference          3  thrpt        4   353.197 ±  25.946  ops/us
benchmarkReturnReference          2  thrpt        4   350.902 ±  19.487  ops/us
benchmarkReturnReference          1  thrpt        4   339.578 ± 144.093  ops/us

関数の戻り値の型を変更するだけで、パフォーマンスがほぼ 3 倍向上しました。

列挙型オブジェクトと整数を返すことの唯一の違いは、一方が 64 ビット値 (参照) を返し、もう一方が 32 ビット値を返すことだと思いました。私の同僚の 1 人は、潜在的な GC の参照を追跡する必要があるため、enum を返すと追加のオーバーヘッドが追加されると推測していました。(しかし、enum オブジェクトが静的な最終参照であることを考えると、そうする必要があるのは奇妙に思えます)。

パフォーマンスの違いの説明は何ですか?


アップデート

誰でもクローンを作成してベンチマークを実行できるように、ここで Maven プロジェクトを共有しました。誰かが時間/興味を持っている場合は、他の人が同じ結果を再現できるかどうかを確認するのに役立ちます. (私は Windows 64 と Linux 64 の 2 つの異なるマシンでレプリケートしました。どちらも Oracle Java 1.7 JVM のフレーバーを使用しています)。@ZhekaKozlov は、メソッド間に違いは見られなかったと述べています。

実行するには: (リポジトリのクローン作成後)

mvn clean install
java -jar .\target\microbenchmarks.jar function.ReturnEnumObjectVersusPrimitiveBenchmark -i 5 -wi 5 -f 1
4

2 に答える 2

157

TL;DR: 何に対しても盲目的な信頼を置いてはなりません。

まず最初に、実験データから結論に飛びつく前に、実験データを検証することが重要です。単に数値を信頼するだけでなく、パフォーマンスの違いの理由を追跡する必要があるため、何かが 3 倍高速/低速であると主張するのは奇妙です。これは、あなたが持っているようなナノベンチマークにとって特に重要です.

第二に、実験者は自分たちが何をコントロールし、何をコントロールしていないかを明確に理解する必要があります。特定の例では、@Benchmarkメソッドから値を返していますが、外部の呼び出し元がプリミティブと参照に対して同じことを行うと合理的に確信できますか? この質問を自問すると、基本的にテスト インフラストラクチャを測定していることに気付くでしょう。

ポイントまで。私のマシン (i5-4210U、Linux x86_64、JDK 8u40) では、次の結果が得られます。

Benchmark                    (value)   Mode  Samples  Score   Error   Units
...benchmarkReturnOrdinal          3  thrpt        5  0.876 ± 0.023  ops/ns
...benchmarkReturnOrdinal          2  thrpt        5  0.876 ± 0.009  ops/ns
...benchmarkReturnOrdinal          1  thrpt        5  0.832 ± 0.048  ops/ns
...benchmarkReturnReference        3  thrpt        5  0.292 ± 0.006  ops/ns
...benchmarkReturnReference        2  thrpt        5  0.286 ± 0.024  ops/ns
...benchmarkReturnReference        1  thrpt        5  0.293 ± 0.008  ops/ns

さて、参照テストは 3 倍遅く表示されます。しかし、待ってください。古い JMH (1.1.1) を使用しています。現在の最新 (1.7.1) に更新しましょう。

Benchmark                    (value)   Mode  Cnt  Score   Error   Units
...benchmarkReturnOrdinal          3  thrpt    5  0.326 ± 0.010  ops/ns
...benchmarkReturnOrdinal          2  thrpt    5  0.329 ± 0.004  ops/ns
...benchmarkReturnOrdinal          1  thrpt    5  0.329 ± 0.004  ops/ns
...benchmarkReturnReference        3  thrpt    5  0.288 ± 0.005  ops/ns
...benchmarkReturnReference        2  thrpt    5  0.288 ± 0.005  ops/ns
...benchmarkReturnReference        1  thrpt    5  0.288 ± 0.002  ops/ns

おっと、今はかろうじて遅いだけです。ところで、これは、テストがインフラストラクチャに依存していることも示しています。さて、実際に何が起こるか見てみましょうか?

ベンチマークを作成し、@Benchmarkメソッドを正確に呼び出すものを調べると、次のようになります。

public void benchmarkReturnOrdinal_thrpt_jmhStub(InfraControl control, RawResults result, ReturnEnumObjectVersusPrimitiveBenchmark_jmh l_returnenumobjectversusprimitivebenchmark0_0, Blackhole_jmh l_blackhole1_1) throws Throwable {
    long operations = 0;
    long realTime = 0;
    result.startTime = System.nanoTime();
    do {
        l_blackhole1_1.consume(l_longname.benchmarkReturnOrdinal());
        operations++;
    } while(!control.isDone);
    result.stopTime = System.nanoTime();
    result.realTime = realTime;
    result.measuredOps = operations;
}

これl_blackhole1_1にはconsume、値を「消費」するメソッドがあります (Blackhole理論的根拠を参照してください)。参照プリミティブBlackhole.consumeのオーバーロードがあり、それだけでパフォーマンスの違いを正当化するのに十分です。

これらのメソッドが異なって見えるのには理由があります。それらのメソッドは、引数の型に対して可能な限り高速にしようとしているからです。それらを一致させようとしても、必ずしも同じパフォーマンス特性を示すとは限らないため、新しい JMH とより対称的な結果になります。-prof perfasmテスト用に生成されたコードを参照して、パフォーマンスが異なる理由を確認することもできますが、それはここでは要点を超えています。

プリミティブおよび/または参照を返すことがパフォーマンスに関してどのように異なるかを本当に理解したい場合は、微妙なパフォーマンスベンチマークの大きな恐ろしいグレーゾーンに入る必要があります. たとえば、このテストのようなもの:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(5)
public class PrimVsRef {

    @Benchmark
    public void prim() {
        doPrim();
    }

    @Benchmark
    public void ref() {
        doRef();
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private int doPrim() {
        return 42;
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private Object doRef() {
        return this;
    }

}

...プリミティブと参照に対して同じ結果が得られます。

Benchmark       Mode  Cnt  Score   Error  Units
PrimVsRef.prim  avgt   25  2.637 ± 0.017  ns/op
PrimVsRef.ref   avgt   25  2.634 ± 0.005  ns/op

上で述べたように、これらのテストでは、結果の理由を追跡する必要があります。この場合、生成された両方のコードはほぼ同じであり、それが結果を説明しています。

堅苦しい:

                  [Verified Entry Point]
 12.69%    1.81%    0x00007f5724aec100: mov    %eax,-0x14000(%rsp)
  0.90%    0.74%    0x00007f5724aec107: push   %rbp
  0.01%    0.01%    0x00007f5724aec108: sub    $0x30,%rsp         
 12.23%   16.00%    0x00007f5724aec10c: mov    $0x2a,%eax   ; load "42"
  0.95%    0.97%    0x00007f5724aec111: add    $0x30,%rsp
           0.02%    0x00007f5724aec115: pop    %rbp
 37.94%   54.70%    0x00007f5724aec116: test   %eax,0x10d1aee4(%rip)        
  0.04%    0.02%    0x00007f5724aec11c: retq  

参照:

                  [Verified Entry Point]
 13.52%    1.45%    0x00007f1887e66700: mov    %eax,-0x14000(%rsp)
  0.60%    0.37%    0x00007f1887e66707: push   %rbp
           0.02%    0x00007f1887e66708: sub    $0x30,%rsp         
 13.63%   16.91%    0x00007f1887e6670c: mov    %rsi,%rax     ; load "this"
  0.50%    0.49%    0x00007f1887e6670f: add    $0x30,%rsp
  0.01%             0x00007f1887e66713: pop    %rbp
 39.18%   57.65%    0x00007f1887e66714: test   %eax,0xe3e78e6(%rip)
  0.02%             0x00007f1887e6671a: retq   

[皮肉] それがいかに簡単か見てください! [/皮肉]

パターンは次のとおりです。質問が単純であるほど、もっともらしく信頼できる答えを出すために、より多くの努力をしなければなりません。

于 2015-04-06T18:09:47.947 に答える
5

一部の人が (@Mzf) に陥った参照メモリの誤解を解消するために、Java 仮想マシン仕様に飛び込みましょう。しかし、そこに行く前に、1 つ明確にしておく必要があります。オブジェクトをメモリから取得することはできず、そのフィールドのみを取得できます。実際、このような大規模な操作を実行するオペコードはありません。

このドキュメントでは、リファレンスをスタック タイプ(スタック上で操作を実行する命令の結果または引数となるように) として定義します。これは、単一のスタック ワード (32 ビット) を使用するタイプのカテゴリです。表 2.3 を参照してください Java スタック タイプのリスト

さらに、メソッド呼び出しが仕様に従って正常に完了すると、スタックのトップからポップされた値がメソッドの呼び出し元のスタックにプッシュされます (セクション 2.6.4)。

あなたの質問は、実行時間の違いの原因です。第 2 章の序文の回答:

Java 仮想マシンの仕様の一部ではない実装の詳細は、実装者の創造性を不必要に制約します。たとえば、ランタイム データ領域のメモリ レイアウト、使用されるガベージ コレクション アルゴリズム、および Java 仮想マシン命令の内部最適化 (マシン コードへの変換など) は、実装者の裁量に任されています。

言い換えれば、参照の使用に関するパフォーマンスのペナルティなどは論理的な理由でドキュメントに記載されていないため (最終的には単なるスタック ワードintですfloat)、実装のソース コードを検索するか、まったく検索しないかのいずれかになります。まったくわかります。

ある程度、実際には常に実装を非難するべきではありません。答えを探すときに利用できる手がかりがいくつかあります。Java では、数値と参照を操作するための個別の命令が定義されています。参照操作命令はa(たとえばastorealoadまたはareturn) で始まり、参照を操作できる唯一の命令です。areturn特に、の実装に興味があるかもしれません。

于 2015-04-06T15:04:10.560 に答える