Itaniumプロセッサがコンパイラを書くのが難しいのはなぜですか？
革命的な EPIC命令セット が優れたコンパイラーを書くことが非常に困難であったため、インテルのItanium 64ビットプロセッサーアーキテクチャーが失敗したと一般に言われています。アーキテクチャ用のプログラムを作成している開発者の数が多いため、多くのソフトウェアを使用せずにハードウェアを使用したくなかったため、プラットフォームが失敗しました。 馬蹄ネイル 良いコンパイラ。
しかし、なぜコンパイラーはそれほど難しい技術的な問題を抱えていたのでしょうか？ EPICでの明示的な並列処理がコンパイラベンダーにとって実装が困難であると思われる場合、なぜ最初にそれらに負担をかけるのでしょうか。これは、この問題に対する優れた、よく理解されたソリューションがまだ存在していなかったようなものではありません。代わりにその負担をIntelに課し、コンパイラライターにシンプルなターゲットを与えてください。
Itaniumは1997年にリリースされました。この時点で、 CSD P-Code バイトコードシステムはほぼ20年前のものであり、 Z-machine はわずかに若く、JVMはプログラミング言語の世界で新しい注目の新星。 Intelが「単純なItaniumバイトコード」言語を指定せず、このバイトコードを最適化されたEPICコードに変換するツールを提供して、システムを最初に設計した人々の専門知識を活用した理由はありますか？
当時思い出したように、問題はIA64の詳細だけではなく、AMDのx86-64命令セットとの競合でした。 AMDは、アーキテクチャをx86命令セットと下位互換にすることで、既存のツールと開発者のスキルセットを活用できました。 AMDの動きは非常に成功したため、Intel（およびVia）は本質的にx86-64アーキテクチャーの採用を余儀なくされました。
当時の大きな障壁は、デスクトップPCで4 GB RAMでした（より現実的にはWindowsで約3.4GBが使用可能）。 x86-64はその障壁を打ち破り、より高いパワーのコンピューティングをすべての人に開放しました。 AMDがx86-64を思い付かなかったとしたら、4GB +にジャンプしたいと思ったすべての人にRAMにそのプレミアムを何年も高額で支払うことをIntelが喜んでいたと思います。市場の動きが遅いことを示すため、アプリケーションが最大64ビットのマルチスレッドプログラミングをキャッチするには何年もかかり、現在でも4GB RAMがローエンドPCの標準となっています。
つまり、IntelはIA64アーキテクチャーで革命的な飛躍を遂げようとし、AMDはx86-64で革新的な一歩を踏み出しました。確立された市場では、ナレッジワーカーが既存のスキルを活用できるようにする進化的なステップが、誰もが新しいスキルを学ぶことを必要とする革命的なステップに勝ちます。 AMDがx86-64拡張機能を追加すると、IA64は、アーキテクチャ間の質的な違いに関係なく、独自のx86プラットフォームの勢いを克服できませんでした。
IA64がプログラムするには難しすぎるという説明は買えません。それは代替案に比べて難しいだけでした。低レベルIRに関する@delnanの要点はごまかしですが、違いがあったとは思いません。
インテルがその負担を自分で負担しようとしなかった理由については、誰が知っていますか？それらは当時の市場支配力でした。 AMDは脅威の一部でしたが、Intelは丘の王でした。おそらく彼らは、IA64が他の何よりもはるかに優れているので、市場全体を動かすことができると考えていました。おそらく彼らはプレミアム層を作り、AMDやVIAなどをマージンの少ない商品ハードウェアをめぐって戦う第2層に残そうとしていました。これはIntelとAppleの両方がかなりうまく採用している戦略です。
Itaniumは、プレミアムプラットフォームを作成し、AMDやVIAなどから敷物を引き出しようとする意図的な試みでしたか？もちろん、それがビジネスの仕組みです。
EPICに関するWikipediaの記事 は、VLIWとEPICに共通する多くの危険をすでに概説しています。
だれかがその記事から致命的な感覚をつかまえないならば、これを強調しておきます：
CPUキャッシュとDRAMを含むメモリ階層からのロード応答には、確定的な遅延はありません。
言い換えれば、メモリアクセスからの非決定的なレイテンシ（*）に対応できないハードウェア設計は、見事な障害になるだけです。
（*）「に対処する」ことにより、適度に良好な実行パフォーマンス（つまり、「コスト競争力のある」）を達成する必要があり、CPUが数十から数百のサイクルの間頻繁にアイドル状態にならないようにする必要があります。
EPICで採用されている対処戦略（上記のWikipediaの記事に記載されている）では問題が実際に解決されないことに注意してください。データの依存関係を示す負担はコンパイラにかかっているとだけ言っています。それはいいです;コンパイラはすでにその情報を持っているので、コンパイラが準拠するのは簡単です。問題は、CPUがメモリアクセスで数十から数百サイクルの間アイドル状態になることです。言い換えれば、それは二次的な責任を外部化する一方で、依然として主要な責任に対処することに失敗しています。
質問は次のように言い換えることができます。「障害が発生する運命にあるハードウェアプラットフォームを考えると、なぜ（1）できなかったのか（2）コンパイラの作成者がそれを利用するために勇敢な努力をしなかったのか」
私の言い回しがその質問への答えを明白にすることを願っています。
致命的である失敗の2番目の側面があります。
対処方法（同じ記事で説明）は、ソフトウェアベースのプリフェッチを使用して、メモリアクセスからの非決定的な遅延によるパフォーマンスの損失の少なくとも一部を回復できることを前提としています。
実際には、プリフェッチは、ストリーミング操作（シーケンシャルな、または非常に予測可能な方法でメモリを読み取る）を実行している場合にのみ有益です。
（とはいえ、コードがローカライズされたメモリ領域に頻繁にアクセスする場合は、キャッシュが役立ちます。）
ただし、ほとんどの汎用ソフトウェアは、大量のランダムメモリアクセスを行う必要があります。次の手順を検討した場合：
- 住所を計算してから
- 値を読み取り、次に
- 一部の計算で使用する
ほとんどの汎用ソフトウェアでは、これら3つをすばやく連続して実行する必要があります。言い換えると、（ソフトウェアロジックの範囲内で）事前にアドレスを計算したり、これら3つのステップの間にストールを埋めるのに十分な作業を見つけることが常に可能であるとは限りません。
屋台を埋めるのに十分な作業を常に見つけることが常に可能であるとは限らない理由を説明するために、これを視覚化する方法を次に示します。
- ストールを効果的に隠すために、メモリに依存しない100の命令を埋める必要があるとしましょう（追加のレイテンシの影響を受けません）。
- ここで、プログラマーとして、任意のソフトウェアを逆アセンブラーにロードしてください。分析するランダム関数を選択します。
- メモリアクセスがまったくない100命令のシーケンス（*）をどこにでも特定できますか？
（*）もしNOPに役立つ作業をさせることができたら...
最新のCPUは、パイプラインを循環する各命令の進行状況を同時に追跡することにより、動的情報を使用してこれに対処しようとします。上で述べたように、その動的な情報の一部は非決定的なメモリレイテンシに起因するため、コンパイラによってある程度の正確さを予測することはできません。一般に、コンパイル時に利用可能な情報が足りないため、これらのストールをいっぱいにする可能性のある決定を下すことができません。
AProgrammerの回答に応じて
「コンパイラー...並列処理の抽出が難しい」ということではありません。
最新のコンパイラによるメモリと算術命令の並べ替えは、独立して、したがって同時に実行可能な操作を特定するのに問題がないことを示しています。
主な問題は、非決定論的なメモリレイテンシは、VLIW/EPICプロセッサ用にエンコードされた「命令ペア」がメモリアクセスによって停止されることを意味することです。
ストールしない（レジスタのみ、算術）命令を最適化しても、ストールする可能性が非常に高い命令（メモリアクセス）によって引き起こされるパフォーマンスの問題には役立ちません。
これは、最適化の80-20ルールを適用できない例です。すでに高速なものを最適化しても、遅いものが最適化されていない限り、全体的なパフォーマンスは大幅に向上しません。
Basile Starynkevitchの回答に応じて
それは「...（何でも）難しい」ではなく、EPICはレイテンシの高いダイナミズムに対処する必要があるプラットフォームには適していません。
たとえば、プロセッサに次のすべてがある場合：
- 直接メモリアクセスなし;
- すべてのメモリアクセス（読み取りまたは書き込み）は、DMA transfer;
- すべての命令の実行待ち時間は同じです。
- 順序実行;
- ワイド/ベクトル化された実行ユニット。
その場合、VLIW/EPICが適しています。
そのようなプロセッサはどこにありますか？ DSP。そして、これがVLIWが栄えた場所です。
振り返ってみると、Itaniumの失敗（および明白な証拠にもかかわらずR＆Dの努力が失敗に絶え間なく注がれていること）は組織の失敗の例であり、詳細に調査する価値があります。
確かに、ハイパースレッディング、SIMDなどのベンダーの他のベンチャーは非常に成功しているようです。 Itaniumへの投資は、エンジニアのスキルに豊かな影響を与えた可能性があり、エンジニアが次世代の成功するテクノロジーを作成できるようになった可能性があります。
TL; DR：1/Itaniumの失敗には、コンパイラーの問題以外にもさまざまな側面があり、それらはそれを説明するには十分かもしれません。 2 /バイトコードはコンパイラの問題を解決しなかったでしょう。
革命的なEPIC命令セットは、優れたコンパイラを作成することが非常に困難であったため、IntelのItanium 64ビットプロセッサアーキテクチャが失敗したと一般的に言われています
まあ、彼らも遅れていて（98年に計画され、2001年に最初の出荷）、最終的にハードウェアを提供したとき、それが以前の日付で約束されたものを提供したかどうかさえわかりません（IIRC、彼らは少なくとも当初計画されていたx86エミュレーション）なので、コンパイルの問題が解決された（そしてAFAIKはまだ解決されていない）場合でも、それらが成功したかどうかはわかりません。過度に野心的だったのはコンパイラの側面だけではありませんでした。
Intelが「単純なItaniumバイトコード」言語を指定せず、このバイトコードを最適化されたEPICコードに変換するツールを提供して、システムを最初に設計した人々の専門知識を活用した理由はありますか？
ツールをどこに配置するかわかりません。
プロセッサ内にある場合は、別のマイクロアーキテクチャがあり、x86をpublicとして使用しない理由はありませんISA（少なくともIntelの場合、非互換性は何よりもコストが高くなります。よりクリーンなパブリックISAをご用意ください）。
外部の場合、バイトコードから開始すると、高レベルの言語から開始するよりもさらに困難になります。 EPICの問題は、コンパイラーが検出できる並列処理しか使用できず、その並列処理を抽出することが難しいことです。言語ルールを知ることは、すでにスケジュールされたものに制約されている場合よりも多くの可能性を与えます。私（信頼できず、遠くからフォローした人から認められた）の思い出は、コンパイラーのフロントでHP（*）とIntelが達成できなかったのは、並列処理の言語レベルの抽出であり、バイトに存在する低レベルではないということです。コード。
現在のプロセッサがパフォーマンスを達成するコストを過小評価している可能性があります。 OOOは他の可能性よりも効果的ですが、確かに効率的ではありません。 EPICは、OOOの実装で使用されるエリアバジェットを使用して、コンパイラーがそれを利用できることを期待して、より生のコンピューティングを提供したいと考えていました。上記のように、理論的にはAFAIKとしても、その機能を備えたコンパイラを作成することができないだけでなく、Itaniumは他の実装が困難な機能を十分に備えていたため、遅れて、その本来の能力が十分ではなかったファブから出たとき、他のハイエンドプロセッサと競合する（おそらくFP計算）が多いニッチ市場を除く）。
（*）また、EPICにおけるHPの役割を過小評価しているようです。
いくつかのこと。
たとえば、IPFは秩序だった。これは、キャッシュミスや他の長時間実行されるイベントが発生した場合に、リオーダーに頼って保存することができなかったことを意味します。その結果、投機的な機能、つまり投機的なロード（失敗を許可されたロード-ロード結果が必要かどうかわからなかった場合に役立つ）と高度なロード（可能性のあるロード）に依存する必要が生じました。危険が発生した場合は、回復コードを使用して再実行します。）これらを正しく行うのは困難で、特に高度な負荷です！また、通常は従来のコンパイラーではなく、アセンブリプログラマーによって、またはプロファイルに基づく最適化を使用してのみインテリジェントに使用できる、ブランチとキャッシュのプリフェッチヒントもありました。
当時、他のマシン、つまりUltraSPARCは正常でしたが、IPFには他の考慮事項もありました。 1つはスペースのエンコードでした。 Itanium命令は本来、特に密度が高くありませんでした。128ビットバンドルには3つの操作と5ビットのテンプレートフィールドが含まれており、バンドル内の操作と、それらすべてを一緒に発行できるかどうかが記述されていました。これにより、効果的な42.6ビットの操作サイズが実現しました。当時の商用RISCのほとんどの操作では32ビットと比較してください。 （これはThumb2などの前でした-RISCは固定長の剛性を意味していました。）さらに悪いことに、使用しているテンプレートに適合するだけの十分なILPが常になかったため、NOPパッドで記入する必要がありました。テンプレートまたはバンドル。これは、既存の比較的低い密度と相まって、まともなiキャッシュヒット率を得ることがa）本当に重要であり、b）難しいことを意味しました-特に、I2は16KBのL1Iしか持っていなかったためです（かなり高速でしたが）。
「コンパイラーが唯一の問題である」という議論は誇張されているといつも感じていましたが、正当なマイクロアーキテクチャーの問題があり、実際にI2は汎用コードを支持していませんでした。その日の狭くてクロックの高いOoOマシンに。多くの場合、PGOまたは手動コーディングのいずれかを伴う本当に適切に埋めることができたとき、それは素晴らしいことでしたが、多くの場合、コンパイラーのパフォーマンスは本当に刺激を与えませんでした。 IPFは優れたコードの生成を容易にするものではありませんでした。
しかし、なぜコンパイラーはそれほど難しい技術的な問題を抱えていたのでしょうか？ EPICでの明示的な並列処理がコンパイラベンダーにとって実装が困難であると思われる場合、なぜ最初にそれらに負担をかけるのでしょうか。これは、この問題に対する優れた、よく理解されたソリューションがまだ存在していなかったようなものではありません。代わりにその負担をIntelに課し、コンパイラライターにシンプルなターゲットを与えてください。
あなたが説明しているのは Transmeta がコードモーフィングソフトウェア（x86の「バイトコード」をTransmetaの内部マシンコードに動的に変換していた）でやろうとしたことです。
IntelがIA64用の十分なコンパイラーを作成できなかった理由については...私はそれらが十分なコンパイラーの専門知識を持っていなかったhouse（もちろん、内部にsome非常に優れたコンパイラのエキスパートがいたとしても、おそらくクリティカルマスを作成するには十分ではありません）。彼らの経営陣はコンパイラーを作るのに必要な努力を過小評価していたと思います。
AFAIK、Intel EPICは、EPICのコンパイルが非常に難しいため、また、コンパイラテクノロジーがゆっくりと徐々に改善されたときに、他の競合他社（AMD64など）でもコンパイラを改善できるため、コンパイラのノウハウを共有して失敗しました。
ところで、私はAMD64がRISCy命令セットになることを望みました。 POWERPC64 だった可能性があります（ただし、特許の問題や、当時のMicrosoftの要求などが原因であったとは言えません）。 x86-64命令セットアーキテクチャは、実際にはコンパイラライターにとって「非常に優れた」アーキテクチャではありません（しかし、なんらかの理由で「十分に優れています」）。
また、IA64アーキテクチャにはいくつかの強力な制限が組み込まれています。プロセッサが3つの機能ユニットを処理する限り、3つの命令/ワードは問題ありませんでしたが、インテルが新しいIA64チップに移行すると、機能ユニットが追加され、命令レベルの並列処理が再び困難になりました。
おそらく RISC-V （これはオープンソースのISAです）は徐々に成功し、他のプロセッサと競合できるようになります。
Robert Munnが指摘したように、Itanium（および他の多くの「新しい」テクノロジー）を殺したのは、下位互換性の欠如でした。
新しいコンパイラを書くのは大変だったかもしれませんが、必要なのはそのうちのいくつかだけです。最適化されたコードを生成するCコンパイラは必須です。そうしないと、使用可能なオペレーティングシステムがありません。 C++コンパイラJavaが必要であり、メインユーザーベースがWindowsのある種のVisual Basicであるとすると、これは実際には問題ではありませんでした。適切なオペレーティングシステム（NT）があり、良いCコンパイラが利用可能です。
ソフトウェア製品を提供している会社にとっては些細な努力のように思えます-Cコードベースを再コンパイルして再テストします（当時は、ほとんどが純粋なCで記述されていたでしょう）はそれほど単純ではありませんでした。 32ビット整数を想定し、32ビットアドレッシングを想定したCプログラムの大規模なセットをネイティブ64ビットアーキテクチャに変換することには、多くの落とし穴がありました。 IA64が支配的なチップになった場合（または人気のあるチップにさえなった場合）、ほとんどのソフトウェア会社は弾丸をかじって努力したでしょう。
妥当なOSを備えた非常に高速なチップですが、利用可能なソフトウェアのセットは非常に限られているため、それを購入する人は多くなく、したがって、製品を提供するソフトウェア会社は多くありません。
Itaniumを殺したのは、ソフトウェアベンダーが64ビットアプリのIA64への移行を約束する前に、AMD64が介入する扉を開く出荷遅延でした。
最適化をコンパイラに任せるのは良い考えでした。多くのことは静的に行うことができますが、そうしないとハードウェアでは効率が悪くなります。特にPGOプロファイリングを使用している場合、コンパイラーはかなりうまくなりました（私はHPで働いていたため、HPのコンパイラーはIntelのコンパイラーよりも優れていました）。 PGOは売れ筋でしたが、プロダクションコードでは難しいプロセスです。
IPFは下位互換性を保つためのものでしたが、AMD64がリリースされると問題が発生し、戦いは失われ、CPUのX86ハードウェアがサーバーCPUとしてリターゲットするために取り除かれたと思います。 Itaniumはアーキテクチャとしては悪くありませんでした。Wordあたり3つの命令は問題ではありませんでした。問題は、メモリ中にスタックをスワップすることによるハイパースレッディングの実装です。IOは、モンテシトなどが競合するか、アウトオブPowerPC CPUを注文します。コンパイラーは、CPU実装の欠陥を検出するために遅くパッチを適用する必要があり、パフォーマンスエッジの一部は、間違いを予測するのが難しいために失われました。
アーキテクチャーにより、Itaniumは比較的シンプルになり、コンパイラーがItaniumからパフォーマンスを引き出すためのツールが提供されました。プラットフォームが存続していた場合、CPUはより複雑になり、最終的にはx86のようにスレッド化され、順序が狂うなどになります。ただし、コンパイラは多くの難しいものを処理したため、最初の世代は他のパフォーマンススキームにトランジスタ数を集中させました。
IPFプラットフォームはコンパイラとツールに賭けており、非常に完全で強力なパフォーマンスモニタリングユニット（PMU）設計を公開した最初のアーキテクチャであり、後でIntel x86に移植されました。そのため、強力なツール開発者は、コードをプロファイリングするための完全な機能をまだ使用していません。
ISA成功を見ると、多くの場合、サイコロを振るのは技術的な側面ではありません。それは、時間と市場の力でのその場所です。SGIMips、DEC Alphaを見てください... Itaniumはサポートされたばかりですより緩やかなSGIおよびHPサーバー、戦略的ビジネスミスを積み重ねた経営者の企業によるものです。Microsoftは完全に機能することはなく、AMD64を採用して、Intelだけをプレーヤーとしてボックス化しないようにしました。IntelはAMDで正しく機能しませんでした。彼らがAMDを嗅ぎつけるつもりであったので、彼らにエコシステムで生きる方法を与えるため。
現在の状況を見ると、X86の複雑なハードウェアによって、これまでのところ進化の行き止まりになっています。 3 GHz以上でスタックし、十分な使用率のないコアをダンプしています。 Itaniumのよりシンプルなデザインは、コンパイラー（拡張の余地）により多くのものをプッシュし、より薄く、より高速なパイプラインを構築できるようにします。同じ世代とファブテクノロジーでは、それはより速く実行され、すべて同じで少し高いが、プッシュムーアの法則に他の扉が開く可能性があったでしょう。
まあ、少なくとも上記は私の信念です:)
メモリはあいまいになっています... Itaniumには、優れたコンパイラサポートを必要とする素晴らしいアイデアがいくつかありました。問題は、それが1つの機能ではなく、多くの機能だったということです。それぞれが大したことではなかった、すべて一緒だった。
たとえば、ループの1つの反復が異なる反復のレジスタを操作するループ機能がありました。 x86は、順不同の大容量機能によって同じ問題を処理します。
当時JavaとJVMは流行りでした。IBMが言ったのは、PowerPCを使用すると、バイトコードをすばやくコンパイルでき、CPUがそれを高速にできるということです。Itaniumではできません。