c++ - Intel C++ コンパイラーが AMD 用に最適ではないコードを出力することについて、どの程度心配する必要がありますか?

Question

私たちは常にインテルのショップです。すべての開発者は Intel マシンを使用しており、エンド ユーザーに推奨されるプラットフォームは Intel です。エンド ユーザーが AMD で実行したい場合は、それが彼らの目を光らせています。おそらく、テスト部門は AMD マシンをどこかに置いて、完全に壊れたものを出荷していないことを確認していたのでしょうが、それだけでした。

数年前まで、私たちは MSVC コンパイラを使用していましたが、SSE レベルを超える多くのプロセッサ チューニング オプションを実際には提供していないため、コードが特定の x86 ベンダーを別のベンダーよりも優先するかどうかについてあまり心配していませんでした。ただし、最近は Intel コンパイラを頻繁に使用しています。私たちのものは、(インテルのハードウェア上で) それから確実にいくつかの重要なパフォーマンス上の利点を得ており、そのベクトル化機能により、asm/intrinsics に行く必要が少なくなります。しかし、人々は、Intel コンパイラが AMD ハードウェアに対して実際にそれほど良い仕事をしていないのではないかと心配し始めています。確かに、Intel CRT または IPP ライブラリに足を踏み入れると、明らかに最適化された関数へのジャンプ テーブルを設定するための多くの cpuid クエリが表示されます。ただし、Intel が AMD のチップに何か良いことをしようと苦労する可能性は低いと思われます。

この分野の経験のある人なら、それが実際に大したことかどうかについてコメントできますか? (AMD で実際にパフォーマンス テストを行ったことはまだありません)。

Update 2010-01-04 : まあ、AMD をサポートする必要性は、私が自分でテストするほど具体的ではありませんでした。この問題に関する興味深い読み物がいくつかありますhere、here、およびhere .

更新 2010-08-09 : Intel-FTC 和解は、この問題について何か言いたいことがあるようです -この記事の「コンパイラとダーティ トリック」セクションを参照してください。

Answer 1

AMD ボックスを購入し、その上で実行します。インターネット上の見知らぬ人を信頼するよりも、それが唯一の責任ある行動のようです ;)

それとは別に、Intel に対する AMD の訴訟の一部は、Intel のコンパイラが特に AMD プロセッサ上で非効率的に実行されるコードを生成するという主張に基づいていると思います。それが本当かどうかはわかりませんが、AMD はそう信じているようです。

しかし、彼らが意図的にそうしなくても、Intel のコンパイラが Intel プロセッサ専用に最適化していることに疑いの余地はありません。

そう言われると、大きな違いになるとは思えません。AMD CPU は、コンパイラのすべての自動ベクトル化およびその他の巧妙な機能の恩恵を受けます。

Answer 2

これまで見てきたことは、インテル コンパイラーが使用可能な命令セットについて実行時に選択を行う必要がある場合、インテル CPU を認識しない場合は、「標準」コードで実行されるということです (これは、ご想像のとおり、最適ではない可能性があります)。 ）。

上記で「コンパイラ」という言葉を使用したとしても、これは主に、命令セットをチェックして最適なコードを呼び出す、提供された (コンパイル済みの) ライブラリと組み込み関数で発生することに注意してください。

Answer 3

このスレッドが開始された時点で、Microsoft C++ はデフォルトでコード生成を行っていました。これは、場合によっては AMD には有効で、Intel には無効です。最近のコンパイラは、特に両方のブランドの CPU が固有のパフォーマンスのバグを解決した後、両方に適したblend オプションにデフォルト設定されています。私が最初にインテルで働いていたとき、インテルのコンパイラーは、インテル固有のアーキテクチャー設定用にいくつかの最適化を予約していました。私の 10 時間の証言では取り上げられませんでしたが、それは FTC の証言録取のトピックであった可能性があると思います。また、最新の CPU モデルとコンパイラの開発時間をより生産的に使用する必要があります。これらの古いコンパイラのいずれかを最新の Intel CPU で使用した場合、同様のパフォーマンスの欠陥が見られる場合があります。

Answer 4

私の一般ボタンを押したらごめんなさい。

これは低レベルの最適化に関するものであるため、1) プログラム カウンターが多くの時間を費やすコード、および 2) コンパイラーが実際に確認するコードのみが問題になります。たとえば、PC がほとんどの時間をコンパイルしないライブラリ ルーチンに費やす場合、それはあまり問題になりません。

条件 1 と 2 が満たされているかどうかにかかわらず、最適化がどのように進むかについての私の経験は次のとおりです。

サンプリングと修正を数回繰り返します。これらのそれぞれで問題が特定されますが、ほとんどの場合、問題はプログラム カウンターの場所ではありません。むしろ、パフォーマンスが最優先であるため、コール スタックの中間レベルに関数呼び出しが存在するということです。それらをすばやく見つけるために、私はこれを行います。

いくつかの長い呼び出しであろうと、非常に多くの短い呼び出しであろうと、実行時間のかなりの部分でスタック上にある関数呼び出し命令がある場合、その呼び出しはその時間の一部を担当することに注意してください。それを実行するか、実行する頻度を減らすと、多くの時間を節約できます。そして、その節約は、低レベルの最適化をはるかに上回ります。

プログラムは、当初よりも何倍も高速になりました。 どんなに注意深く書かれたとしても、このプロセスの恩恵を受けられないほどのサイズのプログラムは見たことがありません。 プロセスが完了していない場合、低レベルの最適化がプログラムを高速化する唯一の方法であると想定しないでください。

このプロセスがそれ以上実行できないところまで実行された後、コンパイラが認識するコード内に PC があることをサンプルが示している場合は、低レベルの最適化が違いを生む可能性があります。

Answer 5

行動できないのなら、心配しても無駄です。可能なアクションは次のとおりです。AMD を購入しない、または別のコンパイラを使用する。したがって、やるべきことは次のとおりです。

(1) AMD ボックスを 1 つ購入し、Intel コンパイラでコンパイルされたコードの速度を測定します。それは十分に速いですか？はいの場合は、完了です。AMD を購入できます。心配はいりません。

(2) いいえの場合: 別のコンパイラでコードをコンパイルし、AMD ボックスで実行します。それは十分に速いですか？いいえの場合は、AMD を購入することはできません。心配する必要はありません。

(3) はいの場合: Intel ボックスで同じコードを実行します。それは十分に速いですか？はいの場合は、AMD を購入できますが、コンパイラを切り替える必要があります。心配する必要はありません。

(4) いいえの場合: 可能性は次のとおりです: AMD を購入しない、すべての Intel コンピュータを捨てる、または 2 つの異なるコンパイラでコンパイルする。一つを選ぶ。

Answer 6

私は、ベンダーがロータス製品を提供前に市場に投入するのを阻止しようとしたときに、意図的にテクノロジを無効にした経験を直接経験しました。有効なテクノロジーが利用可能でしたが、ロータスはそれを使用することを禁じられていました。まぁ...

数年前、Intel コンパイラで 1 バイトにパッチを当てると、AMD で使用しても問題のない「最適な」コードが生成されることをユーザーに示すブログがありました。私はこれらのブログエントリを何年も探していません。

私は、そのような競争行動が続くと信じたいと思っています。他に提供できる証拠はありません。