コード命令の整列

このような単純な関数のパフォーマンスを測定するのはどれほど難しいでしょうか？

// func.cpp void benchmark_func(int* a) { for (int i = 0; i < 32; ++i) a[i] += 1; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、それをある種のマイクロベンチマークでラップし、何度も（結果を平均するために）呼び出して、何が起こるか見てみましょう。 コンパイラーがそこで何かを「最適化」していないことを確認するためだけに、生成された命令を見ることができます。 また、ループがボトルネックであることを確認するために、いくつかの異なるテストを実行できます。 まあ、それだけです。 私たちは測定するものを理解していますよね？



ファイルに別の関数があることを想像してみましょう。速度も測定しますが、個別のテストです。 すなわち ファイルは次のようになります。

 // func.cpp void foo(int* a) { for (int i = 0; i < 32; ++i) a[i] += 1; } void benchmark_func(int* a) { for (int i = 0; i < 32; ++i) a[i] += 1; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてある日、あなたのマネージャーがあなたのところに来て、あなたのライブラリのユーザーから、あなたが約束したほど速く動作しないという苦情を示します。 ただし、パフォーマンスをよく測定し、テスト結果から得たものを正確に約束しました。 何が悪かったのですか？



ユーザーは、benchmark_func（）関数のテストにのみ興味があるため、そのためだけにパフォーマンステストを実行したと言います。

フィギュア

次のオプションを使用して、最新のClangでこのコードをコンパイルしました。

 -O2 -march=skylake -fno-unroll-loops
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードをIntel Core i7-6700 Skylakeプロセッサーで実行しました

すべてのコードとビルドスクリプトは、 ここからダウンロードできます 。 Googleベンチマークライブラリも必要になります 。



2つの関数を使用するコードのバージョンを「基本」、そして、benchmark_func関数のみを使用するオプション-「no_foo」を呼び出しましょう。 結果は次のとおりです。

 $ ./baseline.sh --------------------------------------------------------- Benchmark CPU Iterations Throughput Clockticks/iter --------------------------------------------------------- func_bench_median 4 ns 191481954 32.5626GB/s 74.73 $ ./no_foo.sh --------------------------------------------------------- Benchmark CPU Iterations Throughput Clockticks/iter --------------------------------------------------------- func_bench_median 4 ns 173214907 29.5699GB/s 84.54
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「Clockticks / iter」メトリックを自分で計算し、benchmark_func（）関数のティック数を反復回数で除算しました。

奇妙なことに、テストではまったく呼び出されない関数foo（）をソースコードのあるファイルから削除すると、残りの関数のパフォーマンスが10％ほど低下しました。

ここで何が起こっているのかを理解してみましょう。

少し先を見て、benchmark_func（）関数用に生成されたアセンブラコードは両方の場合で同一であり、唯一の違いはバイナリ内の位置と内部ループのアライメントです。



最初に、「ベース」バージョン用に生成されたコードを見てみましょう。

 $ objdump -d a.out -M intel | grep "<_Z14benchmark_funcPi>:" -A15 00000000004046c0 <_Z14benchmark_funcPi>: 4046c0: 48 c7 c0 80 ff ff ff mov rax,0xffffffffffffff80 4046c7: c5 fd 76 c0 vpcmpeqd ymm0,ymm0,ymm0 4046cb: 0f 1f 44 00 00 nop DWORD PTR [rax+rax*1+0x0] 4046d0: c5 fe 6f 8c 07 80 00 vmovdqu ymm1,YMMWORD PTR [rdi+rax*1+0x80] 4046d7: 00 00 4046d9: c5 f5 fa c8 vpsubd ymm1,ymm1,ymm0 4046dd: c5 fe 7f 8c 07 80 00 vmovdqu YMMWORD PTR [rdi+rax*1+0x80],ymm1 4046e4: 00 00 4046e6: 48 83 c0 20 add rax,0x20 4046ea: 75 e4 jne 4046d0 <_Z14benchmark_funcPi+0x10> 4046ec: c5 f8 77 vzeroupper 4046ef: c3 ret
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードがキャッシュラインの境界に配置されていることがわかります（0x406c0 mod 0x40 == 0x0）。 これはいいです。 しかし、Intelプロセッサアーキテクチャについては、まだ知っておくべきことがあります。 Skylakeプロセッサーには、1回のパスで16バイトの命令を選択するマイクロ命令変換エンジンであるMITE（マイクロ命令変換エンジン）があります。 ここで重要な点は、16バイトだけでなく、16バイト間隔にアラインされたウィンドウからの16バイトであるということです。 これらの命令が選択された後、デコーダーはそれらを一連の小さなマイクロ操作（uop）に変換します。 さらに、これらのマイクロオペレーションは、実行の次のステージに転送されます。



しかし、DSB（Decoded Stream Buffer）と呼ばれる別のハードウェアユニットがあり、その名前が示すように、これはマイクロオペレーションキャッシュです。 すでに最近完了した一連の命令を実行する場合は、DSBでそれに対応するマイクロ操作があるかどうかを最初に確認します。 そこで見つかった場合、これにより、MITEを再ブロードキャストするだけでなく、RAMから読み取ることもできます（一般的には優れています）。 ただし、マイクロ命令がDSBに到達する（または取得しない）方法に影響する特定の制限があります。これについては以下で説明します。



上記のアセンブラーコマンドでは、コードがベクトル化されており、実際にはループの反復が4回のみであることがわかります。これはこの例に適しています。それ以外の場合は、LSD（ループストリームディテクター）がループを検出し、メモリからの命令のフェッチを停止します。



Intelアーキテクチャのこれらすべてのニュアンスに関する詳細は、ドキュメント「Intel 64およびIA-32アーキテクチャ最適化リファレンスマニュアル」に記載されています。 このトピックに関する優れたZia Ansariのプレゼンテーションもご覧ください。

コード命令の整列が重要

後で議論する内容をすでに推測していると思います。 どちらの場合でも、benchmark_func（）関数がコード内でどのように配置されているかを見てみましょう。



「基本ケース」：







「No_foo」：







上の図の太い長方形は32バイトのウィンドウを示し、ループ本体の指示は黄色の背景でマークされています。 最初の観察結果は、2番目の場合、ループのコード全体が1つの32バイトウィンドウに分類され、最初の場合は2つのウィンドウに分散されるということです。 実際、2番目のケースでは、DSBにアクセスするときにミスが半分になり（DSB_MISS_PS 1800M対888M）、DSB-MITEを切り替えるオーバーヘッドがまったくゼロ（DSB2MITE_SWITCHES、PENALTY_CYCLES 888M対0）になります。 しかし、なぜ、すべてが10％悪くなるのでしょうか？ おそらく、まだ考慮に入れていない他のアーキテクチャ機能がいくつかあります。



いくつかの実験を行い、デコードされた命令がDSBにどのように配置されるかについてのさまざまな仮説をテストしましたが、それでも完全に理解しているとは100％確信できません。 ここに実験を投稿しました 。



パフォーマンスカウンターに異常はありませんでした。 注意できる唯一のことは、パラメーターの2つのケースの違いです。

IDQ_UOPS_NOT_DELIVERED、CYCLES_0_UOPS_DELIV（4100M対5200M）。 あなたがそれが何であるかわからない場合-記事の終わりを見て、すべての使用されたカウンターの説明があります。

さらに先へ

アライメントを明示的に設定して、さらに2つの実験を行いました。-mllvm-align-all-functions = 5および-mllvm -align-all-blocks = 5：

 $ ./aligned_functions.sh --------------------------------------------------------- Benchmark CPU Iterations Throughput Clockticks/iter --------------------------------------------------------- func_bench_median 3 ns 218294614 36.8538GB/s 63.37 $ ./aligned_blocks.sh --------------------------------------------------------- Benchmark CPU Iterations Throughput Clockticks/iter --------------------------------------------------------- func_bench_median 3 ns 262104631 44.3106GB/s 46.25
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

bench_func（）を32バイトの境界で整列すると、+ 13％のパフォーマンスが得られ、32バイトの境界で関数bench_func（）のすべてのベースブロック（関数の開始を含む）を整列すると、+ 36％の速度向上が得られました。 おかしいですよね？



関数の配置があるケースの関数の位置は、「ベース」の場合とそれほど変わりません。







つまり、「ベース」の場合のように、DSBで何らかの問題を処理しています。 DSB_MISS_PS 2600M対1800Mのカウンターでは、さらに悪いDSBパフォーマンスが示されます。 さらに重要なのは、カウンターIDQ_UOPS_NOT_DELIVERED、CYCLES_0_UOPS_DELIVを比較することです：330M対4100M。 最後に、私たちにとって本当に重要なのは、バックエンドがデコードされたマイクロ命令で満たされるようにすることです。



ベースブロックが整列している場合：







興味深いのは、DSBの使用率が高いことと、配信されたマイクロ命令がなかった対策の数が少ないことです。 特定のカウンター値を含む以下の表をご覧ください。

使用済みパフォーマンスカウンター

そして、この表の列見出しの説明は次のとおりです。



FRONTEND_RETIRED.DSB_MISS_PS -DSB（デコードストリームバッファー）で検索ミスが発生した命令をカウントします



DSB2MITE_SWITCHES.PENALTY_CYCLES -DSBとMITEを切り替える際のペナルティ測定値をカウントします。 必要な指示がなく、MITEを使用しなければならなかったDSBへのアピールは、最悪の場合、IDQにマイクロ操作が転送されない最大6クロックサイクルかかる可能性があります。 原則として、これには最大2つの手段が必要です。



IDQ.ALL_DSB_CYCLES_4_UOPS-デコードストリームバッファー（DSB）から命令デコードキュー（IDQ）に正確に4つのマイクロ命令が配信されたメジャーの数をカウントします



IDQ.ALL_DSB_CYCLES_ANY_UOPS-デコードストリームバッファー（DSB）から命令デコードキュー（IDQ）にマイクロ命令が配信されたメジャーの数をカウントします



IDQ_UOPS_NOT_DELIVERED.CORE-各ストリームのリソース割り当てテーブル（RAT）に配信されないマイクロオペレーションの数をカウントし、命令デコードキュー（IDQ）がリソース割り当てテーブル（RAT）にx個のマイクロオペレーションを配信するときに「4」を追加します（xはセット{0 、1,2,3}）



IDQ_UOPS_NOT_DELIVERED.CYCLES_0_UOPS_DELIV.CORE-各ストリームについて、マイクロオペレーションがリソース割り当てテーブル（RAT）に配信されなかったメジャーの数をカウントします。 IDQ_Uops_Not_Delivered.core = 4。

警告

この特定のケースでは、たとえば、反復回数を1024に増やすと、これらのアライメントの問題はすべてなくなります。この時点で、ループ検出器（LSD）が機能します。 彼は、私たちが循環していることを理解し、同じ指示を何度も繰り返します。 次に、メモリからの命令の読み取りを禁止し、内部バッファから実行を開始します。 この時点で、命令がメモリ内でどのように配置され整列されるかは完全に無関係になります。



別の興味深い例として、 ゴールドリンカーを使用したときにパフォーマンスがさらに10％低下したことがあります。 これは、それが何らかの理由で悪いからではなく、コードのアライメントのためです。

常にコードを揃えないのはなぜですか？

アライメントとは、コンパイラーがコードにNOP命令を挿入することを意味します。 これにより、バイナリのサイズが大きくなり、これらのNOP命令が一般的に使用されるループに陥ると、パフォーマンスが低下する可能性があります。 NOP命令の実行は完全に無料ではありません。メモリから読み取り、デコードする必要があります。

結論

ご覧のとおり、このような少量のコードでも難しい場合があります。 私たち全員がマイクロプロセッサアーキテクチャの専門家である必要はないと思いますが、少なくともそのような問題が存在する可能性があることを知っておく必要があります。 一度測定された関数のパフォーマンスは、この関数のコードを変更しなくても将来変更される可能性があることに注意してください。 これが重要なポイントである場合-追加のパフォーマンス測定を行って、この記事で説明した問題と同様の問題を特定することを忘れないでください。