Itaniumプロセッサがコンパイラを書くのが難しいのはなぜですか？

よく知られているように、IntelのItanium 64ビットプロセッサアーキテクチャは、革新的なEPIC命令セットが優れたコンパイラを書くのが非常に難しく、IA64の優れた開発者ツールが不足しており、そのアーキテクチャ用のプログラムを作成する開発者が不足していたために失敗した、だから誰もハードウェアをあまりソフトウェアなしで使いたくなかったので、プラットフォームは失敗しました。馬蹄形の爪 優れたコンパイラ。

しかし、なぜコンパイラはそんなに難しい技術的な問題だったのでしょうか？コンパイラベンダーがEPICの明示的な並列処理を実装するのが難しいとしたら、そもそもなぜそれらに負担をかけるのでしょうか。この問題に対する優れた、十分に理解された解決策がまだ存在していなかったようではありません。代わりにその負担をインテルに負わせ、コンパイラ作成者にもっと簡単なターゲットを与えます。

Itaniumは1997年に登場しました。この時点までに、UCSD P-Codeバイトコードシステムは20年近く近く、Z-machineはわずかに若く、JVMはプログラミング言語の世界でホットな新星となりました。Intelが「単純なItaniumバイトコード」言語を指定せず、このバイトコードを最適化されたEPICコードに変換し、そもそもシステムを設計した人々としての専門知識を活用するツールを提供しなかった理由はありますか？

当時思い出したように、問題はIA64の詳細だけではなく、AMDのx86-64命令セットとの競合でした。アーキテクチャをx86命令セットと下位互換にすることで、AMDは既存のツールと開発者のスキルセットを活用できました。AMDの移行は非常に成功したため、Intel（およびVia）は本質的にx86-64アーキテクチャの採用を余儀なくされました。

当時の大きな障壁は、デスクトップPCで4 GBのRAMでした（より現実的には、Windowsで最大3.4 GB使用可能）。x86-64はその障壁を打ち破り、より強力なコンピューティングをすべての人に開放しました。AMDがx86-64を思いつかなかったなら、Intelは4GB以上のRAMにジャンプしたいすべての人にその特権のために多額のプレミアムを何年も払って喜んでいたと確信しています。市場の動きがいかに遅いかを示すため、アプリケーションが最大64ビットのマルチスレッドプログラミングをキャッチするのに何年もかかり、現在でもローエンドPCでは4GB RAMが標準です。

要するに、IntelはIA64アーキテクチャで革命的な飛躍を試み、AMDはx86-64で革新的な一歩を踏み出しました。確立された市場では、ナレッジワーカーが既存のスキルを活用できるようにする進化的なステップが、誰もが新しいスキルを学ぶ必要がある革新的なステップに勝ちます。アーキテクチャ間の質的な違いに関係なく、IA64は、AMDがx86-64拡張機能を追加すると、独自のx86プラットフォームの勢いを克服できませんでした。

IA64はプログラミングが難しすぎるという説明は買わない。選択肢に比べて難しいだけでした。低レベルのIRについての@delnanの主張は軽smされており、違いを生むとは思わない。

インテルがその負担を背負わなかった理由については、誰が知っていますか？彼らは当時の市場の力でした。AMDは脅威のようなものでしたが、Intelは丘の王様でした。IA64は他のどの製品よりもはるかに優れているため、市場全体を動かすことができると考えたのかもしれません。たぶん、彼らはプレミアムティアを作って、AMD、VIAなどを低マージンのコモディティハードウェアと戦う第2ティアに残そうとしていた-IntelとAppleの両方が非常にうまく利用している戦略。

Itaniumは、プレミアムプラットフォームを作成し、AMD、VIAなどからラグを引き出すための意図的な試みでしたか？もちろん、それがビジネスの仕組みです。

EPIC上のWikipediaの記事はすでにVLIWとEPICに共通する多くの危険を概説しました。

誰かがその記事から運命論の感覚をつかまないならば、これを強調させてください：

CPUキャッシュとDRAMを含むメモリ階層からの負荷応答には、確定的な遅延はありません。

言い換えれば、メモリアクセスからの非決定的レイテンシに対処できないハードウェア設計は、すべて大きな障害になります。

（*）「cope with」では、かなり良好な実行パフォーマンス（つまり、「コスト競争力のある」）を達成する必要があります。これにより、CPUを数十から数百サイクルも頻繁にアイドル状態にしないことが必要になります。

EPICが採用している対処戦略（上記のWikipediaの記事に記載）が実際に問題を解決するわけではないことに注意してください。これは、データの依存関係を示す負担がコンパイラにかかっていると言っているだけです。それはいいです; コンパイラはすでにその情報を持っているため、コンパイラが準拠するのは簡単です。問題は、CPUがメモリアクセスで数十から数百サイクルもアイドル状態になることです。言い換えれば、それは二次責任を外部化する一方で、依然として一次責任に対処できない。

質問を言い換えると、「失敗する運命にあるハードウェアプラットフォームを考えると、なぜ（1）コンパイラーライターはそれを償うために英雄的な努力をすることができなかったのですか？」

言い換えることで、その質問に対する答えが明らかになることを願っています。

また、致命的な障害の2番目の側面があります。

対処方法（同じ記事で説明）は、ソフトウェアベースのプリフェッチを使用して、メモリアクセスからの非決定的なレイテンシによるパフォーマンスの低下の少なくとも一部を回復できると想定しています。

実際には、プリフェッチは、ストリーミング操作（メモリをシーケンシャルに、または高度に予測可能な方法で読み取る）を実行している場合にのみ有益です。

（つまり、コードがローカライズされたメモリ領域に頻繁にアクセスする場合、キャッシングが役立ちます。）

ただし、ほとんどの汎用ソフトウェアは、大量のランダムメモリアクセスを行う必要があります。次の手順を検討する場合：

• 住所を計算してから、
• 値を読んでから、
• いくつかの計算で使用する

ほとんどの汎用ソフトウェアでは、これらの3つをすばやく連続して実行する必要があります。つまり、（ソフトウェアロジックの範囲内で）事前にアドレスを計算したり、これら3つのステップの間のストールを埋めるのに十分な作業を見つけることが常に可能とは限りません。

なぜ屋台を埋めるのに十分な仕事を見つけることが常に可能とは限らないのかを説明するために、それを視覚化する方法を以下に示します。

• 失速を効果的に隠すために、メモリに依存しない100個の命令を埋める必要があるとしましょう（したがって、追加のレイテンシの影響を受けません）。
• さて、プログラマーとして、選択したソフトウェアを逆アセンブラーにロードしてください。分析用のランダム関数を選択します。
• メモリアクセスのみのない100命令（*）のシーケンスをどこでも識別できますか？

（*）NOP役に立つ仕事をすることができたら...

現代のCPUは、動的な情報を使用して、パイプラインを循環する各命令の進行を同時に追跡することで、同じ問題に対処しようとします。上で述べたように、その動的情報の一部は、非決定論的なメモリレイテンシによるものであるため、コンパイラによって正確に予測することはできません。一般に、コンパイル時に利用可能な情報が十分にないため、これらのストールがいっぱいになる可能性があります。

AProgrammerの回答に応えて

「コンパイラー...並列化の抽出が難しい」ということではありません。

最新のコンパイラによるメモリおよび算術命令の並べ替えは、独立して、したがって同時に実行可能な操作を識別するのに問題がないという証拠です。

主な問題は、VLIW / EPICプロセッサ用にエンコードされた「命令ペアリング」がメモリアクセスによってストールされることを、非決定的メモリレイテンシが意味することです。

ストールしない命令（レジスタのみ、算術）を最適化しても、ストールする可能性が非常に高い命令（メモリアクセス）によって引き起こされるパフォーマンスの問題は解決しません。

80-20の最適化ルールを適用できない場合の例です。すでに高速なものを最適化しても、低速なものも最適化されない限り、全体的なパフォーマンスが大幅に向上することはありません。

Basile Starynkevitchの回答に応えて

「（どんなに）難しい」ということではなく、EPICはレイテンシの高いダイナミズムに対処しなければならないプラットフォームには適していないということです。

たとえば、プロセッサに次のすべてがある場合：

• 直接メモリアクセスなし;
  • メモリアクセス（読み取りまたは書き込み）は、DMA転送によってスケジュールする必要があります。
• すべての命令の実行レイテンシは同じです。
• 順番実行;
• ワイド/ベクトル化された実行ユニット。

その場合、VLIW / EPICが最適です。

そのようなプロセッサはどこにありますか？DSP。そして、これはVLIWが栄えた場所です。

後から考えると、Itaniumの失敗（および明白な証拠にもかかわらず、R＆Dの努力の継続的な失敗）は、組織の失敗の例であり、徹底的に研究する価値があります。

確かに、ハイパースレッディング、SIMDなど、ベンダーの他のベンチャーは非常に成功しているようです。Itaniumへの投資がエンジニアのスキルに豊かな影響を与えた可能性があり、それによって次世代の成功したテクノロジーを作成できるようになった可能性があります。

TL; DR：1 / Itaniumの障害には、コンパイラーの問題以外の側面があり、それを説明するのに十分かもしれません。2 /バイトコードはコンパイラの問題を解決しませんでした。

IntelのItanium 64ビットプロセッサアーキテクチャは失敗したと一般的に言われています

まあ、彼らは遅れていた（98年に計画され、2001年に最初の出荷）、そして最終的にハードウェアを納品したとき、それが以前の日付に約束されたものを納品したかどうかさえわかりません（IIRC、彼らは少なくとも最初に計画されていたx86エミュレーション）であるため、コンパイルの問題が解決されたとしても（そして、まだ知られていないとしても）、それらが成功したかどうかはわかりません。過度に野心的な側面は、コンパイラの側面だけではありませんでした。

Intelが「単純なItaniumバイトコード」言語を指定せず、このバイトコードを最適化されたEPICコードに変換し、そもそもシステムを設計した人々としての専門知識を活用するツールを提供しなかった理由はありますか？

ツールをどこに配置するかわかりません。

プロセッサ内にある場合、もう1つのマイクロアーキテクチャがあり、x86をパブリックISAとして使用しない理由はありません（少なくともIntelの場合、非互換性は、よりクリーンなパブリックISAをもたらす可能性があるものよりもコストが高くなります）。

外部の場合、バイトコードから開始すると、高レベルの言語から開始するよりもさらに困難になります。EPICの問題は、コンパイラが検出できる並列処理しか使用できないことであり、その並列処理を抽出するのは困難です。言語規則を知っていると、すでにスケジュールされているものに制約されている場合よりも多くの可能性が得られます。私（信頼性が低いと認められており、遠くからそれを追った人から）の思い出は、HP（*）とIntelがコンパイラの面で​​達成できなかったのは、バイトに存在する低レベルではなく、並列性の言語レベルの抽出であるということですコード。

おそらく、現在のプロセッサがパフォーマンスを達成するコストを過小評価しています。OOOは他の可能性よりも効果的ですが、確かに効率的ではありません。EPICは、コンパイラーがそれを利用できることを期待して、OOOの実装で使用される領域予算を使用して、より生のコンピューティングを提供したいと考えました。上で書いたように、理論的にはAFAIKのようにその能力を備えたコンパイラを作成することはまだできないだけでなく、Itaniumには実装が困難な十分な機能が追加されており、遅れてその力が発揮されませんでした他のハイエンドプロセッサがファブから出ると、競争力があります（おそらく、FP計算が多いニッチ市場を除く）。

（*）EPICでのHPの役割も過小評価しているようです。

いくつかのこと。

1つは、IPFが正常でした。これは、キャッシュミスやその他の長時間にわたるイベントが発生した場合に、再注文に頼ってあなたを救うことができなかったことを意味します。その結果、投機的な機能、つまり投機的なロード（失敗することを許可されたロード-ロード結果が必要かどうかわからない場合に便利）と高度なロード（可能なロード）に依存する必要がありました。ハザードが発生した場合、リカバリコードを使用して再実行します。）これらを正しく実行することは難しく、特に高度な負荷でした。また、通常は従来のコンパイラではなく、アセンブリプログラマーまたはプロファイルガイドによる最適化を使用することでのみインテリジェントに使用できるブランチおよびキャッシュプリフェッチヒントもありました。

当時の他のマシン、つまりUltraSPARCは正常でしたが、IPFには他の考慮事項もありました。1つはエンコードスペースです。Itanium命令は、本質的には特に高密度ではありませんでした。128ビットバンドルには、3つの操作と、バンドル内の操作とそれらがすべて一緒に発行できるかどうかを記述する5ビットテンプレートフィールドが含まれていました。これにより、効果的な42.6ビットの操作サイズが実現しました-当時のほとんどの商用RISCの操作の32ビットと比較してください。（これはThumb2などの前でした-RISCはまだ固定長の剛性を意味していました。）さらに悪いことに、使用しているテンプレートに適合するILPが常に十分ではなかったため、NOPパッドで記入する必要がありますテンプレートまたはバンドル。これは、既存の比較的低い密度と相まって、まともなiキャッシュヒット率を得ることが非常に重要だったことを意味しました。

「コンパイラは唯一の問題である」という議論は誇張されているといつも感じていましたが、I2が汎用コードに好意的ではなかった正当なマイクロアーキテクチャの問題がありました-比較のためにコードを生成することは特に面白くありませんでしたその日の狭い、高クロックのOoOマシンに。多くの場合PGOまたはハンドコーディングのいずれかを必要とする、本当に適切に埋めることができたとき、それは素晴らしかった-しかし、多くの場合、コンパイラからのパフォーマンスは本当に魅力的ではありませんでした。IPFは優れたコードの生成を容易にしませんでした。また、コードが優れていなかったときは容赦しませんでした。

しかし、なぜコンパイラはそんなに難しい技術的な問題だったのでしょうか？コンパイラベンダーがEPICの明示的な並列処理を実装するのが難しいとしたら、そもそもなぜそれらに負担をかけるのでしょうか。この問題に対する優れた、十分に理解された解決策がまだ存在していなかったようではありません。代わりにその負担をインテルに負わせ、コンパイラ作成者にもっと簡単なターゲットを与えます。

あなたが説明するのは、Transmetaがコードモーフィングソフトウェア（x86の「バイトコード」をTransmeta内部マシンコードに動的に変換していた）でやろうとしたことです。

インテルは、IA64のための良い十分なコンパイラを作るために失敗しなかった理由については...私は推測、彼らが持っていなかったということです十分なコンパイラの専門知識を家の中はもちろん、彼らが持っていた場合でも、（いくつかの内部の非常に良いコンパイラの専門家を、おそらく十分ではないにクリティカルマスを作成します）。私は彼らの管理がコンパイラを作るのに必要な努力を過小評価していたと思います。

私の知る限り、Intel EPICは失敗しました。なぜならEPICのコンパイルは本当に難しいからです。また、コンパイラテクノロジがゆっくりと徐々に改善されると、コンパイラ（AMD64など）を改善できる他の競合他社も、コンパイラのノウハウを共有します。

ところで、AMD64がもっとRISCyの命令セットになることを望みました。POWERPC64である可能性があります（ただし、特許問題や、当時のMicrosoftの要求などが原因ではなかったと思われます）。x86-64命令セットアーキテクチャは、実際にはコンパイラライタにとって「非常に優れた」アーキテクチャではありません（しかし、それは何らかの形で「十分な」ものです）。

また、IA64アーキテクチャにはいくつかの強力な制限が組み込まれています。たとえば、プロセッサに処理する機能ユニットが3つある限り3命令/ワードは良好でしたが、Intelが新しいIA64チップに移行すると、より多くの機能ユニットが追加され、レベルの並列処理を実現するのは再び困難でした。

おそらく、RISC-V（オープンソースISA）は、他のプロセッサとの競争力を高めるのに十分なほど徐々に成功するでしょう。

Robert Munnが指摘したように、Itanium（および他の多くの「新しい」テクノロジー）を殺したのは、下位互換性の欠如でした。

新しいコンパイラを書くのは難しいかもしれませんが、必要なのはそのうちのいくつかだけです。最適化されたコードを生成するACコンパイラは必須です。それ以外の場合、使用可能なオペレーティングシステムはありません。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は悪くありませんでした。単語あたり3命令は問題ではありませんでした。問題だったのは、メモリIOがスタックをスワップすることによるハイパースレッディングの実装で、Montecitoなどが競合と異常なPowerPC CPUの競合を妨げるまで、I / Oが遅すぎた（パイプラインを空にしてリロードできなかった）ことです。コンパイラは、CPU実装の検出が遅れる欠陥を修正する必要があり、パフォーマンスエッジの一部が失われ、ミスを予測しにくくなりました。

このアーキテクチャにより、Itaniumは比較的シンプルになりましたが、コンパイラがパフォーマンスを引き出すツールを提供しました。プラットフォームが存続していれば、CPUはより複雑になり、最終的にはx86のようにスレッド化されたり、故障したりすることになります。ただし、コンパイラーは多くの困難なものを処理したため、最初の世代は他のパフォーマンススキームにトランジスタ数を集中させました。

IPFプラットフォームはコンパイラとツールに賭けており、非常に完全で強力なPerformance Monitoring Unit（PMU）設計を公開した最初のアーキテクチャであり、後にIntel x86に移植されました。そのため、強力なツール開発者は、コードをプロファイリングするためにこのツールをまだ使用していません。

ISAの成功を見れば、サイコロを振るのは技術的な側面ではないことがよくあります。それは時間と市場の力でその場所です。SGI Mips、DEC Alphaをご覧ください。Itaniumは、戦略的なビジネス上のミスを積み上げた経営者を抱えるルーサー、SGI＆HPサーバーによってサポートされました。マイクロソフトは完全な形ではなく、AMD64をプレーヤーとしてのIntelのみでボックスインしないように受け入れました。また、IntelはAMDを嗅ぎ落とすことを意図していたので、Intelがエコシステムで生きる方法を与えるためにAMDと正しくプレイしませんでした。

現在の状況を見ると、X86の複雑なハードウェアは、これまでのところ進化の行き止まりにつながっています。私たちは3GHz以上で立ち往生しており、それを十分に使用していないコアをダンプしています。Itaniumのシンプルな設計では、コンパイラに多くの要素が追加され（成長の余地）、より薄く、より高速なパイプラインを構築できました。同じ世代とファブ技術では、ムーアの法則を推進するために他のドアが開かれる可能性があり、より高速で動作し、上限は少し高くなりました。

まあ、少なくとも上記は私の信念です:)

メモリがあいまいになっています... Itaniumには、優れたコンパイラサポートを必要とする素晴らしいアイデアがいくつかありました。問題は、それが1つの機能ではなく、多くの機能だったことです。それぞれが大したことではありませんでした。

たとえば、ループの1つの反復が異なる反復からのレジスタで動作するループ機能がありました。x86は、大規模な異常機能によって同じ問題を処理します。

当時、JavaとJVMは流行っていました。IBMが言ったことは、PowerPCを使用すると、バイトコードをすばやくコンパイルでき、CPUがそれを高速化できるということでした。Itaniumではありません。