こことインターネットを見回すと、多くの実際の状況で最新のコンパイラが SSE を打ち負かしているという多くの投稿を見つけることができます.2006 年に整数ベースの画像処理のために書かれた SSE コードを無効にしたときに継承したコードに遭遇しました。コードを標準の C ブランチに強制すると、より高速に実行されます。
複数のコアと高度なパイプラインなどを備えた最新のプロセッサでは、古い SSE コードはパフォーマンスが低下しgcc -O2ますか?
質問する
2411 次
5 に答える
10
マイクロベンチマークには注意が必要です。自分が思っていたものとは違うものを測定するのは本当に簡単です。また、L1 I-cache / uop-cache および branch-predictor エントリへのプレッシャーに関して、マイクロベンチマークは通常、コード サイズをまったく考慮していません。
ほとんどの場合、マイクロベンチマークでは通常、可能な限りすべての分岐が予測されますが、頻繁に呼び出されるがタイトなループではないルーチンは、実際にはうまく機能しない可能性があります。
長年にわたり、SSE には多くの機能が追加されてきました。新しいコードの妥当なベースラインは、スカラー フォールバックがある限り、SSSE3 (Intel Core2 以降、および AMD Bulldozer 以降で使用) です。高速なバイト シャッフル ( pshufb) の追加は、いくつかのゲーム チェンジャーです。SSE4.1 では、整数コードにもかなりの優れた機能が追加されています。古いコードがそれを使用しない場合、コンパイラの出力または新しい手書きのコードは、はるかにうまく機能する可能性があります。
現在、256b レジスターで 2 つの 128b レーンを同時に処理する AVX2 までです。256b シャッフル命令がいくつかあります。AVX/AVX2 は、以前のすべての SSE 命令の 3 オペランド (非破壊的な dest、src1、src2) バージョンを提供します。整数コードの場合は AVX2)。
1 年か 2 年以内に、おそらく最初の AVX512 デスクトップ ハードウェアが登場するでしょう。これにより、膨大な量の強力な機能 (マスク レジスター、非常に非直交性の SSE / AVX 命令セットのギャップを埋める) だけでなく、幅の広いレジスターと実行ユニットが追加されます。
古い SSE コードが、スカラー コードが作成された時点でわずかなスピードアップしか得られなかった場合、または誰もベンチマークしていなかった場合、それが問題である可能性があります。コンパイラの進歩により、スカラー C 用に生成されたコードが、多くのシャッフルを必要とする古い SSE を打ち負かす可能性があります。時々、データをベクトルレジスターにシャッフルするコストが、いったんそこにあると高速であることのすべてのスピードアップを食い尽くします。
または、コンパイラ オプションによっては、コンパイラが自動ベクトル化することさえあります。IIRCgcc -O2は有効にしないため、 auto-vec-ftree-vectorizeが必要です。-O3
古い SSE コードを妨げている可能性があるもう 1 つのことは、整列されていないロード/ストアが低速でありpalignr、レジスタ内の整列されていないデータと整列されたロード/ストアの間を行き来するために、または同様の手法が使用されていると想定している可能性があることです。そのため、古いコードは古いマイクロアーチ向けに調整されている可能性がありますが、最近のものでは実際には遅くなります。
そのため、以前は利用できなかった命令を使用しなくても、別のマイクロアーキテクチャに合わせて調整することが重要です。
コンパイラの出力が最適であることはめったにありません。ポインターがエイリアシングされていない（restrict）、または整列していないことを伝えていない場合。しかし、多くの場合、かなり高速に実行できます。多くの場合、少し改善できます (特に、同じ作業を行うための uops/insns を少なくすることでハイパースレッディングに適したものにするため)、ターゲットにしているマイクロアーキテクチャを知る必要があります。たとえば、Intel Sandybridge 以降では、1 レジスタ アドレス指定モードのメモリ オペランドのみをマイクロヒューズできます。x86 wikiのその他のリンク。
タイトルに答えるために、いいえ、SSE命令セットは決して冗長でも推奨されていません。asm を使用して直接使用することは、カジュアルな使用にはお勧めできません (代わりに組み込み関数を使用してください)。実際にコンパイラ出力を高速化できない限り、組み込み関数の使用は推奨されません。それらが今結び付けられている場合、将来のコンパイラーは、ベクトル組み込み関数よりもスカラー コードをより適切に処理する方が簡単になります。
于 2015-11-27T00:51:35.017 に答える
3
これらは、厳密に言えば無関係な 2 つの別個の質問でした。
1) SSE 全般、特に SSE で調整されたコードベースは時代遅れになった / 「推奨されない」 / 廃止されましたか?
簡単に答えてください。高レベルの理由: (HPC ドメインであっても、Nehalem を簡単に見つけることができる) 十分なハードウェアがまだあり、SSE* のみが搭載されていて、AVX* が利用できないためです。HPC の外を見ると、現在 SSE4 までしかサポートしていないIntel Atom CPUなどを考えてみてください。
2) なぜ gcc -O2 (つまり、自動ベクトル化され、SSE のみのハードウェアで実行される) は、9 年前に書かれた古い (おそらく組み込み) SSE 実装よりも高速です。
回答: 場合によりますが、まず第一に、コンパイラ側で非常に積極的に改善されています。私の知る限り、上位 4 つの x86 コンパイラの開発チームは、過去 9 年間に自動ベクトル化または明示的ベクトル化の分野に多額の投資を行ってきました。また、彼らがそうした理由も明らかです。x86 ハードウェアでの SIMD "FLOPs" の可能性は、過去 9 年間で (正式には) "8 倍" (つまり、SSE4 ピーク フロップの 8 倍) 増加しました。
もう 1 つ質問させてください。
3) OK、SSE は時代遅れではありません。しかし、それは今から X 年後に時代遅れになるでしょうか?
回答: 少なくとも HPC では、AVX-2 および AVX-512 と互換性のあるハードウェアが広く採用されているため、SSE 組み込みコードベースはすぐに廃止される可能性が非常に高くなりますが、これも開発内容によって異なります。一部の低レベルに最適化された HPC/HPC+Media ライブラリは、高度に調整された SSE コード パスを長期間保持する可能性があります。
于 2015-11-30T20:23:07.550 に答える
0
最新のコンパイラが SSE4 を使用しているのをよく目にするかもしれません。しかし、同じ ISA に固執している場合でも、スケジューリングに関してははるかに優れていることがよくあります。SSE ユニットをビジー状態に保つということは、データ ストリーミングを慎重に管理することを意味します。
各命令ストリーム (スレッド) は単一のコアで実行されるため、コアは無関係です。
于 2015-11-27T00:32:59.090 に答える