「Microsoft が Itanium 向け開発終了を宣言」記事へのコメント

アーキテクチャとしてのメリット

[yohata (11299)]

ところで、今までこの手の話題が出てきた場合

「アーキテクチャ的には素晴らしかったが、商売としては失敗したね」

……と言った声が、多少は出るものなのですが。
Itaniumに関しては、アーキテクチャ的に惜しむ声を余り(と言うか全く)聞きませんね。

かなり今更な話になるのですが、純粋に技術面から見たItaniumってどうだったのでしょうか？

Re:アーキテクチャとしてのメリット

[nminoru (5013)]

他の人からはクソみそに言われるでしょうから、5年ぐらい IA-64 と付き合った者として餞別代りに Itanium を擁護してみます。

個人的な感想としては IA-64 は「はまったコードは非常に速いが、外れたコードは非常に遅い」アーキです。
ただ「はまったコード」」を生成するには icc のような最適化コンパイラが必須です。
また最適化コンパイラがあっても、「はまったコード」にコンパイルできないアプリも多いです。gcc とか perl のようなのが特に苦手。

命令アーキテクチャとしては、尖った機構がふんだんに存在しています。

• IA-64 は VLIW 的な 3 命令組の「バンドル」を持つが、このバンドルを前後に組み合わせて「命令グループ」が実行単位になる。ハード資源が許せば1命令グループは最大1サイクルで実行可能で、命令グループ内のバンドル数に制限はない。理論上は何十命令でも並列実行可能。ただし Itanium2 は最大2バンドル6命令まで。
• 整数レジスタと浮動小数点レジスタが約 128 本使える。レジスタが不足することはまずない。
• 整数・浮動小数点レジスタのうち 96 本(r32-r127) は stack-register で、これは関数呼び出しの前後のレジスタスピルコードをほとんど不用にしてくれる。C 関数で言うと第一引数が r32 に割り付けられ、関数の call/return に応じて配置が変わる。
  SPARC の register-window に似ているがあちらは物理レジスタが不足した時にソフト割り込みが懸って OS が処理する必要がある。IA-64 は CPU 内の Register-Stack-Engine が stack-register をメモリに自動的にロード・ストアしてくれる。そのため関数呼び出しが非常に高速。
• Register rotation と呼ばれる機構があり、ソフトウェアパイプライニングをハードサポートしてくれる。数値計算系は高速実行可能。
• プレディケートがある。実質全ての命令がプレディケート修飾可能で、コンパイラ最適化の IF-変換が効率よく実現できる。そのため条件分岐を極限まで減らすことが可能。
• 条件分岐命令毎に動的分岐予測を使う否かの指定が可能。分岐方向ヒントも埋め込める。分岐予測の精度が上がる。
• ループ専用分岐命令があり、効率よく使うと分岐ミスペナルティがなくなる。
• 投機ロード(load.s)や先行ロード(load.a)によって制御投機やデータ投機をソフト的に記述可能。例えば先行ロードは、本来ロードの位置より先行して発行し、真のロード位置に専用のチェック命令を実行する。CPU が先行ロードからチェックの間にメモリ内容に変更がないことを監視しており、書き替えがなければそのまま実行が続く。大胆にメモリレイテンシを縮小可能。
• ビット操作が得意。
• 多方向に分岐が可能。Itanium2 なら1サイクルで 4 方向(taken:3, not-taken:1) に飛べる。switch 文みたいなのがうまくコンパイルできる。
• 仮想記憶機構が素晴らしくリッチで、他の CPU の特徴をほとんど包含している。エミュレーターを書くには便利。

あと Itanium2 としての特徴ですが、

• 分岐履歴情報なしの間接分岐予測を持っている。うまくコードを書くと分岐予測ミスペナルティを 0 にできる。
• メモリアクセス能力が高い。1サイクルにロード2回、ストア2回を同時発行可能。

良いのか悪いのか分からない点としては、

• メモリアクセスのオーダーリングが著しく緩い。通常のロード・ストア命令は実行順序に制約がない(release-consistency)。メモリアクセスの順序を付けるには特殊なロード・ストア命令を使う必要がある。

  CPU から見ると高速化が可能。プログラマーとしては非常に困った性質で、C 言語だと volatile を付けないと通常のロード・ストア命令が生成されるので、他のアーキ用に書かれたマルチプロセッサ用のソースコードが容赦なく異常動作する。

悪い点は、やっぱり Out-of-Order 実行がない点ですね。命令グループに命令をそんなに詰め込めないし、ロード命令がウェイトすると後続命令は実行できないので、結局性能が上がりません。OoO を導入するには論理レジスタ数が多すぎることがネックになると思います。

--
コンタミは発見の母

Re:

[Anonymous Coward]

> OoO を導入するには論理レジスタ数が多すぎることがネックになると思います。

レジスタリネーミングでないOoOも、まさにそのイリノイ大を含めていろいろ提案されてますぅ。
ランアヘッド、スカウトスレッド(Rock;_;)、フリーフリッカーなど。
アイデアとしてはどれも、ストールした命令の推移閉包以外を先に仮コミットするものです。OoOコミットってやつ。
互換性のため、ストール地点のレジスタ内容はどこかに保存します。
スカウト方式なら本スレッドが止まり、レジスタ内容を超高速でコピーしてスカウトが先に進みます。
別の方式では、投機実行用に小さなフルアソシアティブなレジスタファイルあるいはコミットキューを用意します。

Re:

[Anonymous Coward]

> OoO を導入するには論理レジスタ数が多すぎることがネックになると思います。

インオーダーであるPOWER6にも限定的にOoOが実装されています。

一つは、ロードミス後も値を無視して走り続けるモード。これはプリフェッチのよい近似になりますが計算結果はデタラメですので再実行します。
もう一つは、SMTの相手方を利用したスカウト風。これは通常時はSMTになりません。

OoOで性能が向上する主要な要因はプリフェッチ効果ですから、IA-64ではあまり改善の余地は残っていない可能性はあります。
今日のプロセッサはレジスタファイルよりもROBのほうがクリティカルな面がありますから、IA-64のOoO化はそちらでも不利ですね。