x32とは、現在規格制定や開発が進められている、新しいABIである。これは、32bit ABIのx86と、64bit ABIのx86_64のいいとこ取りを狙ったABIである。
x86_64の利点は多数ある。まず、汎用レジスタが増える。CPUによるレジスタリネーミングだとかなんだとかいって、CPU側でこっそり隠しレジスタを用意して差し替える仕組みもあったが、やはり汎用レジスタの増加は、わかりやすいパフォーマンスアップに繋がる。もちろん、レジスタが増えるという事は、それだけプロセス切り替えのコストもかかるのだが、それを差し引いても、一部の純粋な数値演算のパフォーマンス向上は得られる。
また、仮想アドレス空間が大幅に広くなるのもすばらしい。実際、一部のソフトウェアでは、仮想アドレス空間が足りないという問題はすでに起きていた。確かに、PAEを使えば36bitのアドレス空間が得られるが、やはり一つのプロセスから直接見えるのは32bitアドレスであり、使いづらい。x86_64では、48bitものアドレス空間により、とりあえず仮想アドレス空間の枯渇の問題を、しばらく先送りできる。
しかし、問題もこのアドレス長にある。確かに、一部のソフトウェアは広い仮想アドレス空間を必要とするが、大多数のソフトウェアは、そんなに広い仮想アドレス空間を必要としない。無駄に広いアドレス長は、むしろオーバーヘッドになる。
しかし、そのようなソフトウェアでも、汎用レジスタの増加によりパフォーマンスが増加する場合もある。
そのような需要のために、アドレス長だけ32bitの64bitコードという、なんとも都合のいいABIが提案された。これが、x32である。ベンチマークの結果、一部のソフトウェアは、x86とx86_64の両方を上回るパフォーマンスが得られたという。
x32を使うには、ハードとソフトの両方のサポートが必要である。まず、ハードとしては、x86_64をサポートしているCPUでなければならない。ソフトは、多岐に渡る。
OSには、最低でも、Linux Kernel 3.4 x86_64が必要となる。コンパイラーには、今の所、gccが対応している。もちろん、gccもx32アーキテクチャをサポートする設定でビルドされていなければならない。x32に対応したデバッガーも必要だ。GDBが対応している。もちろん、x32に設定したビルドが必要だ。glibcを含めたライブラリも、当然x32に対応し、もちろんx32向けにコンパイルされていなければならない。ビルドツールにも特別な対応が必要だ。
と、このように、x32への対応は結構面倒である。すでにx86とx86_64両方でコンパイル、実行できるソフトウェアならば、コード自体には、よほど特殊なことをしていない限り、それほど変更は必要ないだろう。しかし、現時点ではビルド環境を整えるだけでも一苦労だ。もちろん、x32が普及すれば、構築済みのビルド環境を、よくメンテされたディストロのパッケージとしてインストールするだけで済むのであろうが。
x32は流行るだろうか。それとも、過渡期の実験的なABIで終わるだろうか。
詳しい内容やビルド環境の構築、ビルド方法については、以下のホームページ等で熟知すべし。
No comments:
Post a Comment