Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP- UX Developer Edge

Itaniumの「底力」を引き出すHPのコンパイラ技術・前編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Itaniumの「底力」を引き出すHPのコンパイラ技術・前編
「Itaniumの卓越したパフォーマンスは、それを支えるコンパイラ技術を抜きには語れない」と説明するのは、米国HPでコンパイラ開発を統括するアレックス・マケール氏だ。命令のスケジューリングのほとんどをコンパイラが担当するインテル® Itanium® プロセッサー(以下、Itanium)では、「コンパイラ技術が発展するにしたがいプロセッサーのパフォーマンスも上昇し続ける」(同氏)という。つまりItanium対応コンパイラは、「進化し続けるItaniumの一部分」と言っても過言ではないのだ。ここでは、HP Cコンパイラの最適化機能によって引き出されるItaniumの「底力」とはどのようなものかレポートする。
Itaniumの「底力」を引き出すHPのコンパイラ技術・前編
コンパイラあってのItanium
「HP Cコンパイラの最適化機能
2005年4月
テクニカルライター  吉川和巳
アレックス・マケール氏
アレックス・マケール氏

コンパイラあってのインテル®Itanium®プロセッサ


「Itaniumの卓越したパフォーマンスは、それを支えるコンパイラ技術を抜きには語れない」と説明するのは、米国HPでコンパイラ開発を統括するアレックス・マケール氏だ。以前の特集「ItaniumでOracleは速くなるか?」でも説明したとおり、ItaniumではEPIC(Explicitly Parallel Instruction Computing)と呼ばれるユニークなプロセッサー・アーキテクチャを採用している。このEPICの能力をフルに引き出せるかどうかはコンパイラの最適化能力しだい、というのが同氏の主張である。これを裏付けるのが、図1のグラフだ。
 
HP Cコンパイラによる性能向上の経過
図1:HP Cコンパイラによる性能向上の経過
 
このグラフは、HPが開発したItanium対応コンパイラ「HP Cコンパイラ」を用いて計測された、SPECやTPC-Cなどの4種類のベンチマーク結果である。注目していただきたい点は、いずれも同一のItanium上で計測されたにもかかわらず、年を追うごとにパフォーマンスが向上していることだ。例えば浮動小数点演算の性能を測るSPECfp2000では、2002年5月の値に比較して、2004年の値は40%近い性能向上が達成されている。

これは、一般的なプロセッサーでは見られない現象だ。なぜなら他のプロセッサーでは、命令のスケジューリング(命令の実行順序の決定)をプロセッサー内部のロジックで実装しているため、並列性を高めたり新たな最適化技法を導入したりするにはプロセッサーを交換するしかない。よってコンパイラ側で改善できる余地は限られている。これに対し、命令のスケジューリングのほとんどをコンパイラが担当するItaniumでは、「コンパイラ技術が発展するに従いプロセッサーのパフォーマンスも上昇し続ける」(同氏)という。つまりItanium対応コンパイラは、「進化し続けるItaniumの一部分」と言っても過言ではないのだ。

では、Itanium対応コンパイラは具体的にどのような役割を担っているのだろうか。コンパイラが重要な意味を持つItaniumの最適化機能としては、おもに以下の3つがある。
  • テンプレート
  • 投機実行
  • プレディケーション

テンプレート


テンプレートとは何かを理解するには、まずItaniumの特殊な命令フォーマットを知る必要がある。
 
Itaniumの「バンドル」
図2:Itaniumの「バンドル」
   
  例えばx86プロセッサーでは、可変長命令(8〜120ビット)を1単位として処理が進む。これに対しItaniumでは、3つの固定長命令(41ビット)をまとめた「バンドル」と呼ばれる128ビットの命令フォーマットを1単位としている。このバンドルを2つまで同時に実行できるため、合計で最大6命令を1クロックで処理可能だ。

もちろんx86やRISCでも、複数命令の同時実行は以前からサポートされている。しかしその実現には、「命令間の依存性」という大きな障壁がある。例えば「a = b」と「c = a」というコードの場合は順番どおり実行するしかない。こうした依存性を検出して処理順序を入れ替えたりする複雑なスケジューリングのロジック(アウトオブオーダー実行)をプロセッサー内部で実装せねばならず、性能向上の足かせとなっている。

一方Itaniumでは、この依存性チェックとスケジューリングをすべてコンパイラが担当しており、その結果がバンドル内のテンプレートと呼ばれる5ビットの領域に格納される。このテンプレートには、バンドル内の3命令をそれぞれどの演算ユニットで実行すべきか、そしてどれを順不同に処理してよいかが指示されている。そのため、アウトオブオーダー実行の複雑なロジックをプロセッサー側で実装する必要がない。さらに、ソフトウェアであるコンパイラは、より広範囲のコードを対象にじっくり時間をかけて解析できるので、1クロック6命令という高度な並列性のポテンシャルをより多く引き出せるのである。

投機実行


周知のとおり、今日のプロセッサーとメモリの間には、動作速度に大幅なギャップがある。例えばキャッシュメモリの読み込みには数クロック分、メインメモリは数100クロック分の時間がかかり、その間プロセッサーは空回りし続ける。そこでコンパイラの多くは、メモリからのロード命令を見つけると、それをできるだけコードの先頭部分に移動しようとする。

ただし、この方法にも限界がある。その一つが、「分岐命令より前にはロードを移動できない」という制限だ。例えば、ロードしたいデータが仮想メモリによってディスク上にページ・アウトされている状況を想定しよう。このデータをロードすると、ページ・フォルトによって処理が長時間ストップする。こうした例外の発生を考慮すると、分岐の結果次第ではムダになるかもしれない投機的なロードは逆効果になる(図3)。また、もしロードしておいたメモリ内容が使う前に更新されてしまったら、ロードをやり直さなくてはならない。通常のプロセッサーでは、これらの問題によりコードを移動できる範囲がかなり制限されている。
 
ロード移動の制約
図3:ロード移動の制約
   
  Itaniumでは、これらの問題をクリアするユニークな投機実行(speculation)のメカニズムを実装している。例えば、投機的なロードにより例外が発生すると、例外処理は実施せずに「ロードに失敗した」という意味のフラグ(NaTビット)が各レジスタにセットされる。そのため、分岐命令にとらわれずにロードを自由に移動できる。また同様に、ロード済みのメモリ内容が書き換えられると、ALAT(Advanced Load Address Table)レジスタを通じてロードが無効化される。一方、Itanium対応コンパイラは、このNaTビットやALATを随時チェックするコードと、ロードが無効な時にはロードをやり直すリカバリ・コードを挿入する。こうしたプロセッサーとコンパイラの連携によって、分岐やデータ依存の垣根を超えたより広い範囲でのコード最適化を実現している。
トップへ   次のページへ

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

HPEサポートセンター
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項