PAE（PhysicalAddressExtension）

早速ですが間違を恐れずに書いてみます。

PAEは日本語で物理アドレス拡張と言います。
32bitOSで扱える4GB以上の実メモリを実装したときに
もったいないお化けが出ないように4GB以上の領域も
有効利用しようとする手法のことです。

プロセッサは情報処理のためにメモリーを利用しますが、
まずは仮想アドレスを使い、その後物理アドレスに変換します。
実際の物理アドレスでは不連続な領域を、仮想アドレスを使うと
プログラムは連続した領域にアクセスできるとか、ページングを
利用できるなどのご利益があります。

仮想アドレスと物理アドレスは別物なので、OSによって決定する
仮想アドレスの上限を越えて物理アドレスを利用することは
できないということです。
つまりアドレス1つが1バイトを識別という原則から、32bitである限り
どぉあがいても仮想アドレスには4GBの壁が立ちはだかります。
（２の32乗＝4294967296　←4GB）
たとえ物理的なメモリを8GBや16GB搭載しても、そのままでは
4GBまでしか利用できません。
しかも実際に使えるのはPCIデバイス等がリマップする
などにより3GB程度となってしまいます。
（先頭にDOS互換と末尾にデバイス等が使用する領域が存在する。）

メモリも安くなり、大容量のメモリ搭載マシーンも少なくないのが
最近の現状であります。
拙宅でもノート以外のクライアントマシーンは16GBとか、少なくとも
8GBを搭載させています。
このようなマシーンに32bitOSをインストールすると、前述のとおり
4GB以下しか利用できなくなってしまいます。

PAEは32bitOSでも最大36bit（64GB)まで物理メモリを
利用できる領域を拡張する手法です。
ではメモリ64GB搭載の64bitOSと同じ？
いえいえ、まったく違います。
PAEは単純に利用できるメモリが増えるわけではありません。
32bitOSでは他の縛りもあるのです。

ではPAEについて拙生の語りうる少ない知識をご披露します。（笑
用語の使用法や間違い勘違いなどがありましたらご指摘いただければ幸です。

PAEが有効でないと・・

32bit仮想メモリ4GBの時の振る舞いをWindows（32bitOS）を
例に取ってみます。
ディフォルトでは1プロセスごとの4GBのアドレス空間のうち、
カーネルが2GBを予約してしまうので、アプリケーションが
利用可能なのは残りの2GBという縛りがあります。
特にSQLサーバーなどではプロセスがボコボコ立ち上げられ
メモリー消費が激しいため、ページングが発生しパフォーマンスの
低下は免れられません。

PAEの実装については昨日のポストを参照してください。

PAEのご利益

仮想アドレスを32から36bitに拡張することで、最大64GB以上の
物理アドレスにアクセスできるようになります。
つまり32bitOSで4GB以上の実メモリを搭載した場合でも
無駄にならないということです。
ただしアプリケーションアドレスの1プロセスにつき2GBという壁が
なくなる訳ではありません。
このへんは　ココ　を読むと面白いです。

　拡張などの技術は日々進歩しているため情報は古いかも。
　36bit以上の拡張になるような話もありましたけど。。

ちょっとだけ64bitのお話

ちなみに64bitOSだと論理アドレスは16EB＝172億GB。（大笑
仮想アドレスとしては現在48ビットで256TB。
実際にはOSのライセッシングなどの関係で、実メモリの認識範囲は
Windows7HPで16GB、Windows8ProやEnterpriseなどのハイエンドの
ものは512GB、ハイエンドなサーバーでも数TBほどです。
ちなみにアプリケーションアドレスの上限は8TBとなっています。
そんな実メモリ積んでないって！（笑

大量にメモリを食うプロセスがいくつも立ち上げるようなサーバー
（SQLサーバーなど）などであれば、32bitOSでPAEを利用しても
2GBの壁などでパフォーマンスは落ちてしまいますので、64bitOS
導入は必須でしょう。

64bitOSを語るときにメモリ量だけではなく、CPUやメモリ、
グラフィックスやストレージディバイスへのアクセス時などの
パフォーマンスが重要になってきます。

よく32も64も変わらないよ、って言う方がいらっしゃいますが
多分64bitOSで32bitアプリを利用しているのでしょう。
同じハード条件でのベンチマークを実施されたことのある方なら
絶対に言わない言葉ですね。

CPUに絞って理屈を考えても、32bitで制御するのか64bitなのかでは、
一気に扱える量が32bitで4,294,967,295、64bitでは
18,446,744,073,709,551,615であり、4,294,967,295倍の差が
あるのですから違わないわけはありません。
もちろんCPUだけ早くてもどこかにボトルネックがあれば
パフォーマンスは下がってしまいますが、拙生の行ったベンチマークでは
cpuで3８%、メモリアクセスで３６％、HDDアクセスは15%、
グラフィックス関連は3%ほどの違いがありました。
グラフィックスがそうでもないのはドライバーの関係でしょう。
（Q9550　DDR2-４GB　GeForce GTX750　SATA2-500GB）
ちなみにi73770Kマシーンのcpuでは40％以上でした。

＊　ベンチマークソフトにより違いはあるが傾向は一緒

つまりクライアントマシーンにおいても使用アプリのプログラムが
64bit対応で書かれていれば当然高速に処理されます。
32bitアプリ使用時の互換性も、16bit-32bitの時よりは飛躍的に
改善されていて、多少のオーバーヘッドは生じるものの
体感できるようなパフォーマンス低下は見られないことから、
特別な理由がない限り64btiOSとアプリを使用するほうが得策です。

では32bitアプリしか使用しなければ64bitOSは不要・・・？
はい、そのとおりです。（笑

＊注　64bitOS条で32bitアプリを走らせるときは、2GBではなく
　　　4GBの縛りとなるので、環境によっては必要ありですね。

話はPAEの戻ります。

PAEという手法上の注意

PAEで拡張すると最大64GBまで認識させることができますが
OSの管理外領域なので、メモリーが増えるほどパフォーマンスが
若干（数％）落ちてしまます。（理由を書くと長いので割愛）
体感できるほどではありませんがベンチマークでは分かります。
気にされる方もいそうなので一応・・・

最近のCPU（LGA775から）はPAEに対応していますが、CeleronMなど
一部のCPUは対応していません。
UbuntuのディフォルトではPAE対応は必須となっているため
インストールすらできないので注意が必要です。

これらのことを調べたのは32bit版OSご使用のクライアント様が
まだ多くを占めていることと、拙宅環境でも32bitのWindows7に
後から64bitのUbuntuなどをインストールし、マルチブートと
して、その時にメモリを４GB以上に足し増ししたマシーンが
残っているためです。

＊　◯◯GBと略式表記していますがSI基準ではありません。
　　正規には2進接頭辞の◯◯GiBとなります。

HOME