インテルは、AMDプロセッサー向けに意図的に不良コードを生成する関数をコンパイラーから削除する必要がありますか？

多くのプログラマーは、Intelコンパイラーが市場で入手可能な最適な最適化コンパイラーであり、最も要求の厳しいパフォーマンスプログラムに使用することを好みます。 さらに、インテルはさまざまな技術的および科学的目的のために、高度に最適化された多くのライブラリを提供しています。 多くの場合、Intelライブラリの適切な代替手段はありません。



残念ながら、Intelコンパイラーまたはライブラリーを使用してコンパイルされたプログラムは、AMDおよびVIAプロセッサー上で著しく動作が悪くなります。 その理由は、プログラムコードの場合、コンパイラ（またはライブラリ）は複数のバージョンのマシンコードを生成でき、それぞれが特定のプロセッサと命令セット（SSE2、SSE3など）に対して最適化されるためです。 システムには、実行しているプロセッサーのタイプを判別し、最適なバージョンを選択する機能が含まれています。 この機能は、プロセッサマネージャと呼ばれます。 Intelプロセッサマネージャは、プロセッサでサポートされている命令セットだけでなく、 プロセッサメーカーの識別子もチェックします 。 識別子が文字列「GenuineIntel」の場合、コードの最適なバージョンが選択されます。 ただし、プロセッサがIntel製でない場合、プロセッサが最適なバージョンと完全に互換性がある場合でも、ほとんどの場合、可能な限り低速のオプションが選択されます。



私は、他の多くの人々と同じように、長年この行動について不満を述べていましたが、Intelはディスパッチャの変更を拒否しました。 IntelがコンパイラをIntelプロセッサとのみ互換性があると宣言した場合、ほとんどの場合、苦情はありません。 問題は、彼らがしていることを隠そうとしていることです。 多くのプログラマーは、IntelコンパイラーがAMDプロセッサーと互換性があると考えています。 これはそうですが、プログラマーからの秘密により、彼はプログラムに偏ったプロセッサーマネージャーを含めており、Intelを除くすべての企業のプロセッサーで作業するときに最悪のバージョンのコードを選択します。 プログラマがこの事実を知っていれば、おそらく別のコンパイラを使用するでしょう。 AMDプロセッサで動作が不十分なプログラムを販売したいのは誰ですか？



Intelは、そのサイズにより、他のプロセッサメーカーよりも多くのコンパイラを投資する余裕があります。 Intelコンパイラは比較的安価に販売され、優れたパフォーマンスを提供し、優れたサポートを提供しています。 そのようなコンパイラを販売することは、確かにそれ自体が有益なビジネスではありません。 それどころか、明らかにIntelプロセッサの販売をサポートする方法です。 マイクロプロセッサに使用するツールがなければ、マイクロプロセッサに新しい命令セットを追加しても意味がありません。 AMDもコンパイラを製造していますが、現在のバージョンはLinuxでのみ動作し、Windows用のバージョンはまだありません。



多くの人々は、この偏ったマネージャーがパフォーマンスを評価するための一般的なプログラムで使用されているという疑念を表明しています（ link link ）。 これは非常に深刻な質問です。 多くのお客様が公開されているテスト結果に基づいて購入を決定し、偏ったテストが数十億ドルという不公平な市場優位性をもたらすことを知っています。

法的戦い

AMDは、少なくとも2005年から不当な競争でインテルを繰り返し訴え、2009年11月に和解に達しました 。 Intelコンパイラを含む、明らかに不公平な競争の多くの問題に関係しています。 ここから引用です：

2.3技術的慣行

インテルは、インテル製品に人工性能障害を含めたり、このサードパーティ製品に人工性能障害を含めることを第三者に要求したりすることはできません。 このセクション2.3で、「人工的なパフォーマンスの低下」とは、（i）特定のAMD製品のパフォーマンスまたはパフォーマンスを低下させる、（ii）インテル製品の改善の結果ではない、Intelの積極的なエンジニアリングアクションまたはIntelの設計（ただし、非行動ではない）アクションを指し、（iii ）AMD製品のパフォーマンスまたはパフォーマンスを低下させるように意図的に設計されています。 このセクション2.3の目的において、「製品の改善」とは、生産性、運用、価格、コスト、製造可能性、信頼性、相互運用性、または他の製品の動作またはパフォーマンスを改善する能力の点での利益、利点、または改善を意味します。



いかなる状況においても、このセクション2.3は、Intelが（i）AMD製品またはサードパーティの製品改善を目的とする行為を行う義務を課すものではなく、課すものと解釈することはできません。このAMD製品またはサードパーティ製品を個別に、または他の製品と組み合わせて、（ii）特定のAMD製品用に製品を最適化するか、（iii）AMDに技術情報、文書、またはノウハウを提供します。

これはAMDの勝利に似ています。 「すべてのインテル製品」がインテルのコンパイラーおよびライブラリーであり、「サードパーティ」がこれらのコンパイラーおよびライブラリーを使用するプログラマーであり、「人工的なパフォーマンス障害」がメーカーの識別子のプロセッサー識別子チェックであると考える場合、この契約はインテルに義務付けられますディスパッチャを変更します。 Intelコンパイラとライブラリの次のバージョンを確実にチェックして、これを行うか、この契約に抜け穴があるかどうかを確認します。



興味深いことに、物語はそこで終わりませんでした。 AMDとIntelの合意からわずか1か月後、米国連邦取引委員会（FTC）はIntelに対して独占禁止法違反の申し立てを行いました。 FTCの苦情申し立ては異常に強い：

インテルは、コンパイラーやライブラリーなどのソフトウェア製品を再設計および配布する際に、インテルx86プロセッサーに対する他社のx86プロセッサーのパフォーマンス上の利点を損なうことを試みました。

[...] [...]

パブリック、OEM、独立系ソフトウェアベンダー、およびテスト組織は、Intel製品を使用してコンパイルされたアプリケーションで他社のプロセッサのパフォーマンスが低下したのは、Intelソフトウェアではなくプロセッサが原因であるという印象を受けました。 インテルは、2003年以降またはその前後にソフトウェアに加えた変更の影響を顧客や一般に公開しませんでした。 インテルは、コンパイラーおよびライブラリーに関する誤ったドキュメントまたは誤解を招くドキュメントも配布しました。 インテルは、独立したソフトウェアベンダー、OEM、テスト組織、および一般の人々に、プログラムが最初に競合他社よりも高速にインテルプロセッサで実行されることを保証しました。 実際、多くの違いは主にまたは完全にIntelソフトウェアによるものです。 インテルのソフトウェアに関する誤解を招くまたは虚偽の主張と不作為は、プロセッサを購入して使用する際に、独立系ソフトウェアベンダー、OEM、テスト組織、および一般大衆によって考慮されました。 したがって、Intelのプログラムは、競合他社のプロセッサよりもインテルのプロセッサで最初に優れた結果を最初に表示するという保証は、虚偽または誤解を招くものです。 インテルは、これらの違いは主にインテルのソフトウェアによるものであるということを開示することを拒否しました。 さらに、これらのゆがみや欠落は、x86プロセッサの他のメーカーの評判を傷つけ、競争を傷つける可能性があります。

[...] [...]

一部のサードパーティソフトウェアベンダーは、Intelおよび他のプロセッサで起動したときの同様のプログラムの速度の明らかな違いに関する情報をIntelに要求しています。 このような要求に応えて、インテルはこの問題の原因と解決の可能性を直接的または間接的に繰り返し不当に伝えました。

[...] [...]

Intelソフトウェアの変更により、正当な技術的利益なしに、他のメーカーのx86プロセッサのパフォーマンスが低下しました。 インテルの欺de的な行動により、消費者はインテルチップと競合他社の間、およびインテルソフトウェアと競合他社の間の意識的な選択を奪われ、それぞれのプロセッサ市場での競争コストが増加しました。 Intelコンパイラとライブラリによるパフォーマンスの低下は、Intel以外の企業のx86プロセッサを使用している消費者にも直接的な被害をもたらしました。

FTCが要求する制裁も非常に行き過ぎています。

苦情に記載されているように、Intel以外のマイクロプロセッサーの実際の性能または見かけの性能を引き起こすまたは有害なコンパイラ（「損傷したコンパイラ」）をIntelから購入したIntelのお客様の場合、以下が必要です。

1. Intelは、ダメージコンパイラではない代替コンパイラを追加料金なしで提供しました。
2. Intelは、Damage Compilerを使用してコンパイルしたソフトウェアを再コンパイルして交換する費用、および再コンパイルしたソフトウェアを顧客に配布する費用を払い戻しました。 そして
3. Intelは、Intel Damaged Compilersでコンパイルされたソフトウェアを購入した個人が、交換が必要な可能性があることを通知できるように、公示と警告を行っています。

おそらくFTCは、AMDとIntelの間の合意は、Intelの排他的行為に対する公正かつ十分な防御ではないと判断しました。 AMDの損害を補償しますが、VIA、他のマイクロプロセッサーメーカー、および不十分な競争とIntelコンパイラーを使用して作成された「欠陥」ソフトウェアに苦しんでいる顧客には何もしません。

私自身の発見

数年前にインテル®コンパイラーのテストを開始したとき、すぐにそのプロセッサー・マネージャーに偏りがあることがわかりました。 2007年1月、Intelに不公平なプロセッサマネージャーについて不満を言いました。 私はこの問題についてインテルのエンジニアと長い間連絡を取りました。 彼らは絶えず問題を否定し、私はますます多くの証拠をもたらしました。 彼らは次のように主張した：

最適化と組み合わされたプロセッサマネージャは、すべてのIntelおよびAMDプロセッサのパフォーマンスを最適化して、可能な限り最高の結果をもたらすように設計されています。 これが私たちの目標であり、1つの例外を除き、私たちはそれを達成したと信じています。 この例外は、リリース日のために、コンパイラーのバージョン9.xのAMDプロセッサーでSSE3がサポートされていないことです（AMDがSSE3をサポートする前にコンパイラーが開発されました）。 ベータテストが今四半期に開始され、最終バージョンが今年の半ば頃にリリースされる10.xコンパイラの次のバージョンは、新しいAMDプロセッサに適応する十分な時間があったため、この問題を解決します。

良さそうに聞こえますが、実際には、プロセッサマネージャは、AMDプロセッサのSSEとSSE2さえもサポートしていませんでした。新しいバージョンは言うまでもなく、まだサポートしていません（Intelコンパイラバージョン11.1.054）。 後に、他の人も同様の苦情でインテルに連絡し、同じ役に立たない言い訳を受け取ったことがわかりました（ リンク リンク ）。



Intel Processor Managerは、プロセッサの製造元IDとサポートされている命令セットを確認するだけではありません。 また、特定のプロセッサモデルをチェックします。 彼は、ファミリー番号が6とは異なる将来のIntelプロセッサーを認識できなくなります。これについてインテルのエンジニアに尋ねると、彼らは答えました。

あなたは、コンパイラを更新しないと、「6」以外のファミリ指定を持つ将来のIntelプロセッサをサポートできないと述べました。 はい、それは真実で意図的です。 コンパイラーによって発行されたプログラムが将来動作を停止しないという高い信頼性が必要です。 したがって、インテル、AMD、またはその他のメーカーの将来のプロセッサについては何も想定できません。 あなたは私たちがもっと積極的に行動できることに気づきました。 これは、（コンパイラでコンパイルされた）コードが遠い将来も機能し続けることを確認したいお客様にとっては不合理だと考えています。 あなたが提案した方法は合理的と思われますが、私たちの非常に最適化されたコンパイラにとっては保守的ではありません。 私たちの経験は、控えめなコード出力につながります。 新しいIntelおよびAMDプロセッサで機能をテストした後、コンパイラを更新します。 これは、コンパイラの公式バージョンでの新しいプロセッサのサポートに遅れがあることを意味します。

つまり、特定の命令セットではなく、特定のプロセッサモデル用に最適化すると主張しています。 trueの場合、これはIntelに欠陥のあるAMDプロセッササポートを支持する議論を提供します。 ただし、Intelコンパイラを使用するすべてのソフトウェア開発者は、新しいIntelプロセッサが市場に登場するたびにコードを再コンパイルし、新しいバージョンを顧客に配布する必要があります。 それは3年前です。 古いバージョンのインテル®コンパイラーでコンパイルされたプログラムを最新のインテル®プロセッサーで実行しようとするとどうなりますか？ 推測：彼女はまだ最高のコードブランチを選択します。 理由を推測するのはさらに困難です。インテルは、新しいプロセッサーのCPUIDファミリー番号を操作して、古いインテルコンパイラーがそれらを既知のモデルと見なすようにします。 別の記事で技術的な詳細を説明しました。



最初は、将来のモデルを考慮せずに、有名なプロセッサモデルのみを最適化するために、Intelプロセッサマネージャが実際に呼び出された可能性があります。 私の生徒の一人がそのような決定に合格した場合、私はそれを重大な欠陥とみなしたでしょう。 おそらくインテルのエンジニアは、将来のプロセッサのサポートが不足しているために修正するには遅すぎることに気付き、既存のインテルソフトウェアが有名なモデルに対応するように次世代のプロセッサを設計することを余儀なくされました。



Intelがディスパッチャを変更することをきっぱりと拒否した後、私は彼らに彼らの心を変える最も効果的な方法はこの問題に関する情報を広めることだと決めました。 私はいくつかの雑誌に連絡しましたが、誰も彼女について書きたくありませんでした。 申し訳ありませんが、これらはすべてIntelの広告配置に依存しているため、驚くことではありません。 これをカバーすることができた唯一の場所は、プログラムを最適化するための私自身のガイドでした。そこでは、状況を詳細に説明し、不公平なディスパッチャを置き換える方法を示しました。 AMDがこの情報を広めなかった理由はわかりません。 おそらく、彼らは裁判の進行について沈黙を保つ必要があったのでしょうか？ VIAとケンタウロスはどうですか？

一時的な解決策

現時点では、インテルが製造元の識別子を検証しない新しいコンパイラーと新しいライブラリをリリースするかどうか、およびリリースする場合はその時期はわかりません。 しかし、この前にできることは次のとおりです。

1. 別のコンパイラを使用してください。 私のテストによると、 Linux用のGnuコンパイラーはIntelコンパイラーと同様のレベルでパフォーマンスを最適化しますが、Gnu関数ライブラリー（Glibc）はIntelよりも劣っています。 他のすべてのコンパイラは、パフォーマンスが低下します。 Windowsでは、Intelコンパイラに近いパフォーマンスのコンパイラは存在しません。
2. Intelコンパイラーを使用して、ディスパッチャーを置き換えます。 私のC ++マニュアルでは、Intelコンパイラーの代替プロセッサーディスパッチャーのコードと、関数のライブラリー、およびそれらを埋め込む方法の説明を公開しました。 もちろん、彼らはIntelソフトウェアデバイスに関する文書化されていない詳細を使用します。 この変更により、多くの場合、Intel以外のプロセッサーのパフォーマンスが大幅に向上します。
3. ソースコードが閉じているか、GnuやMicrosoftなどの中立なコンパイラーを使用していない場合、単一のパフォーマンステストを信頼しないでください。
4. AMD仮想化の指示により、AMDプロセッサーのCPUIDを変更できます。 誰かがこのためのプログラムを作成することを願っています。 これにより、特定のテストが公正であるかどうかを簡単に確認でき、AMDプロセッサー上のIntelコンパイラーでコンパイルされたソフトウェアのパフォーマンスが向上します。

参照資料

2007年のAceshardwareフォーラムでの私の議論 。



開発者フォーラムでの議論

AMD、2008年 。



AMDzone 2009での私の議論 。



グループディスカッション

comp.arch、2004年 。



Intelの苦情、slashdot.orgでの議論、2004年 。



2005年のIntelにおけるMackeyの苦情 。



PCMark 2005テスト、Arstechnicaの不正が証明されています。



証言

テスト組織BAPCoに関するJohn Oram 。



2005年AMD Developer Centralにコメントしてください 。



AMDは2005年に訴訟を起こしました 。



独占禁止法に関する苦情AMD、2005年 。



AMDとIntelの間の友好的な合意、2009年 。



FTC苦情、2009年 。



C ++最適化ガイドの技術的な詳細 。



XtremeSystemsフォーラムでのディスカッション 。