グラフィックス

Transcription

1 WOW64 Win32 アプリケーションを実行する WOW64 WOW64:32bit コードを実行する為の仕組み WOW64(Windows 32bit emulation on Windows 64bit) は 64bit Windows OS 上で 32bit Windows アプリケーションの実行環境をエミュレーションする為のシステムで有る 64bit 版 Windows OS のカーネルは 元々 Win64 と謂うネイティブな API セットしかサポートして居らず 32bit や 16bit の API (Win32 や Win16) は持って居ない 併し 此れでは従来のアプリケーションを利用出来ないので Win32 アプリケーションを実行する為の仕組みが用意されて居る 此れが WOW64 で有る WOW64 の仕組みを図にすると 次の様に成る WOW64 の構成 Win64(64bit) アプリケーションの API 呼び出しは其の儘 64bit Windows OS のカーネルへ渡される 此れに対して Win32(32bit) アプリケーションの API 呼び出しはエミュレーション用の特別な DLL を経由してパラメータが変換され 其の後 64bit Windows OS のカーネルへ渡される 64bit Windows 向けに作られたアプリケーションを実行する場合は 夫々のアプリケーション毎に独立した 1 つの 64bit プロセス空間が作成され 其の中で実行される 此れに対して Win32 アプリケーションを実行しようとすると 32bit 版の Windows OS をエミュレー -1-

2 ションする為の環境 (32bit プロセス空間 ) が作成され 其の中で Win32 アプリケーションが実行される Win32 アプリケーションが発行する API はエミュレーション用に用意された特別な DLL を経由して 64bit の OS カーネルへ渡される DLL WOW64.DLL WOW64WIN.DLL WOW64CPU.DLL NTDLL.DLL 用途 WOW64 を構成するコア コンポーネント NTOSKRNL.EXE への中継を行うサンク ( 呼び出し ) が含まれて居る ファイル システム リダイレクションやレジストリ リフレクションなどの処理も行う GUI 関連の API(WIN32K.SYS) への中継を行うサンクが含まれて居る ホスト CPU の抽象化を行う為のライブラリ 32bit モードと 64bit モードの切り替えや WOW64 内に於ける 32bit CPU のスレッド コンテキストの切り替え等を行う Win32 から NTDLL.DLL を呼び出すと Win64 用に変換され 64bit の NTDLL.DLL が呼び出される USER32.DLL や GDI32.DLL 等も同様 WOW64 を構成する基本 DLL Win32 アプリケーションが発行する API の内 ポインタ データを含む物や特別な処理が必要な物は此等の DLL で対処したり 変換したりしてネイティブの OS カーネルへ渡される 他の DLL は 32bit 版の Windows OS と同じ物が用意されて居り 其れが利用される Win32 と Win64 API ではポインタのサイズは異なるが 其れ以外のデータ型は互換性が有る ( 次ページで述べる様に int 等のデータ型は 64bit 環境でもサイズは同じで有る ) WOW64 では Win32 API 呼び出しのパラメータ中に有るポインタを 64bit アドレスに変換して OS カーネルを呼び出す 戻り値にポインタ データが含まれて居る場合は其の逆の変換をして 呼び出し元の関数へ戻す Win32 アプリケーションから利用するライブラリ (DLL) は此れ以外にも多数有るが 其等は 32bit 版 Windows OS に含まれて居る物が其の儘利用される %windir% SysWOW64 フォルダの内容を見ると解るが ( 次の画面参照 ) 此処には 32bit 版 Windows OS の %windir% SYSTEM32 フォルダの内容が粗其の儘入って居る -2-

3 WOW64 の為のシステム フォルダ 32bit Windows 環境をエミュレーションする為のファイルは SYSWOW64 フォルダに格納されて居る 此れは 64bit 版の Windows 7 Ultimate Edition での画面例 1.Windows フォルダ内に有る SYSWOW64 を開いて観る 2. 此のフォルダを開く 3. 此処に有るファイルは 32bit 版の Windows 7 Ultimate Edition の %windir% SYSTEM32 フォルダに有る物と粗同じ 前述の幾つかの DLL ファイル而巳が異なる WOW64 では此の様に 32bit 版の Windows コンポーネントを使う事に依り Win32 アプリケーションを実行して居る 詰まりエミュレーションと謂うよりは 32bit 版の Windows OS が粗其の儘入って居て 其の上で Win32 アプリケーションを実行して居ると謂う事に成る 例えば 此の SYSWOW64 フォルダの中に有るメモ帳 (notepad.exe) をダブルクリックして実行して観よう [ スタート ] メニューからメモ帳を起動すると通常は 64bit 版のメモ帳が起動するが SYSWOW64 フォルダの中に有る notepad.exe を実行すると 32bit 版のメモ帳が実行される 此の様子はタスク マネージャの [ プロセス ] タブで確認出来る 32bit 版メモ帳を起動する SYSWOW64 フォルダの中に有るメモ帳 (notepad.exe) を起動した場合の例 1. 此のタブを選択する 2. 末尾に *32 と付いて居る事から 32bit 版のメモ帳で有る事が解る 此の様な仕組みの為 Win32 アプリケーションの実行速度は 32bit 版の Windows OS 上で実行して居る場合と比較しても 殆ど変わらない -3-

4 ファイル システムやレジストリのリダイレクション / リフレクション 今述べた様に WOW64 環境では SYSWOW64 フォルダに有る DLL 等を使って Win32 アプリケーションを実行して居る 然うすると 若しアプリケーションがデータやファイルを プログラムの実行ファイルが有る場所 ( 起動した場所 ) に保存しようとすると何う成るだろうか? 本来ならば ( 純粋な 32bit 版の Windows OS の場合は ) %windir% SYSTEM32% フォルダに保存する事に成るだろうが ( 注 : Windows 7 や Windows Vista 等では デフォルトのアクセス権設定の儘では此のフォルダへは保存出来ない ) WOW64 上の場合は SYSWOW64 フォルダに保存する事に成る 例えば設定ファイルを実行ファイルと同じ場所に保存するようなアプリケーションがあったとすると 此れは問題と成る可能性が有る %windir% SYSTEM32% フォルダに書き込んだ積りなのに 別の場所に保存されて了って居るからだ 次回起動時にアプリケーションが設定ファイルを %windir% SYSTEM32% フォルダから読み出そうしても見付からず エラーと成るだろう 此の様な問題を避ける為 WOW64 では ファイル システムやレジストリに対してリダイレクションやリフレクションをする為の機能が用意されて居る ファイル システムのリダイレクト 此れは 特定のフォルダやファイル名に対して 別の場所へ誘導したり 置き換えたりする機能で有る (WOW64.DLL で実装されて居る ) Win32 から呼び出したファイル システム関連のパラメータに此等のパス名が含まれて居ると 其れを上書きして別の場所やファイルへ誘導する 具体的には 次の様なパスが対象と成る パス %windir% System32 %windir% lastgood %windir% regedit.exe %windir% system32 catroot %windir% system32 catroot2 %windir% system32 driversstore %windir% system32 drivers etc %windir% system32 logfiles %windir% system32 spool %windir% Sysnative リダイレクトの内容 Win32 アプリケーションから此のパスへアクセスすると 実際には %windir% SYSWOW64 フォルダへリダイレクトされる %windir% lastgood SYSWOW64 にリダイレクトされる %windir% SysWOW64 regedit.exe にリダイレクトされる regedit は常に SYSWOW64 フォルダの物を使う様にする為の措置 此等は %windir% SYSWOW64 ディレクトリにリダイレクトされない 同じファイルを 2 カ所に作らせない為の措置 注 : 但し Windows Server 2008 Windows Vista Windows Server 2003 及び Windows XP の 64bit 版では %windir% system32 driversstore フォルダはリダイレクトされる 此れは仮想的なフォルダ名 此れを利用すると リダイレクトされずに ( リダイレクト機能をパスして ) 直接 %windir% system32 フォルダへアクセス出来る 此の仮想的なフォルダは Windows Vista 以降で追加された 但し仮想フォルダなので 64bit のネイティブ アプリケーションからは利用出来ない 以下にフォルダがリダイレクトされる例を示して置く -4-

5 C: Windows system32>prompt [%PROCESSOR_ARCHITECTURE%]$p$g プロンプトを変更 [AMD64]C: Windows system32> 現在は Win64 上 [AMD64]C: Windows system32>mkdir TMP C: Windows SysWOW64 TMP TMP フォルダを作成 [AMD64]C: Windows system32>dir > TMP THIS_IS_WIN64.TXT Win64 上でファイル作成 [AMD64]C: Windows system32>dir TMP 確認ドライブ C のボリュームラベルは WIN7X64 ですボリュームシリアル番号は 9C7C-5B6B です C: Windows system32 TMP のディレクトリ 2010/06/29 12:43 <DIR>. 2010/06/29 12:43 <DIR> /06/29 12:43 143,058 THIS_IS_WIN64.TXT 作成したファイル 1 個のファイル 143,058 バイト 2 個のディレクトリ 825,908,105,216 バイトの空き領域 [AMD64]C: Windows system32>c: Windows SysWOW64 cmd WOW64 上で cmd を起動 Microsoft Windows [Version ] Copyright (c) 2009 Microsoft Corporation. All rights reserved. [AMD64]C: Windows system32>prompt [%PROCESSOR_ARCHITECTURE%]$p$g プロンプトの変更 [x86]c: Windows system32> WOW64 上で実行中 (x86 と成って居る ) [x86]c: Windows system32>dir > TMP THIS_IS_x86.TXT WOW64 上でファイル作成 [x86]c: Windows system32>dir tmp 確認ドライブ C のボリュームラベルは WIN7X64 ですボリュームシリアル番号は 9C7C-5B6B です C: Windows system32 tmp のディレクトリ 2010/06/29 12:45 <DIR>. 2010/06/29 12:45 <DIR> /06/29 12:45 120,126 THIS_IS_x86.TXT 作成したファイル 最初に作成したフ ァイルは此処にはない 1 個のファイル 120,126 バイト 2 個のディレクトリ 825,907,982,336 バイトの空き領域 [x86]c: Windows system32>exit WOW64 を終了 [AMD64]C: Windows system32>dir TMP C: Windows SysWOW64 TMP 再確認ドライブ C のボリュームラベルは WIN7X64 です -5-

6 ボリュームシリアル番号は 9C7C-5B6B です C: Windows system32 TMP のディレクトリ Win64 上の TMP 2010/06/29 12:43 <DIR>. 2010/06/29 12:43 <DIR> /06/29 12:43 143,058 THIS_IS_WIN64.TXT Win64 上で作成したファイル 1 個のファイル 143,058 バイト C: Windows SysWOW64 TMP のディレクトリ WOW64 上の TMP 2010/06/29 12:45 <DIR>. 2010/06/29 12:45 <DIR> /06/29 12:45 120,126 THIS_IS_x86.TXT WOW64 上で作成したファイル 1 個のファイル 120,126 バイト 2 個のディレクトリ 825,907,458,048 バイトの空き領域 [AMD64]C: Windows system32> レジストリのリダイレクションとリフレクション ファイル システムのリダイレクションと同様に レジストリのエントリにも幾つかリダイレクトされる物が有る (HKLM Software や HKCU 等 ) 此れは 32bit アプリケーションと 64bit アプリケーションで異なる設定を ( 同じキーの場所等に ) 保存したいと謂った要求に応える物で有る 実行して居る環境に応じて 32bit 用と 64bit 用で異なるレジストリ キーが作られ 参照や更新等が自動的に振り分けられる様に成って居る 此の機能は非常に解り辛く 主にプログラマが対応する可き事なので 此処では詳細は述べない 以下の Web ページ等を参照して欲しい レジストリリダイレクタ ( マイクロソフト MSDN サイト ) 更に レジストリ リフレクション と謂う機能も用意され 一方を更新すると 自動的に対応するキーが更新される ( 反映される ) 機能も用意されて居る 完全に分けて了うと 先程のフォルダのリダイレクトの様に 保存した筈の値が読み出せない ( 例 :32bit アプリケーションで保存した物が 64bit アプリケーションで読み出せない等 ) と謂う事が起こる可能性も有るので 自動的に反映する様にする為だ 併し 非常に使い辛かったのか Windows 7 及び Windows Server 2008 R2 以降では廃止されて居る アプリケーションを開発 / 改修する場合は注意して欲しい WOW64 の制限 以上 WOW64 に付いて解説して来たが 幾つか制限事項も有る 最後に其れに付いて述べて置く WOW64 を使った場合のプロセス アドレス空間はデフォルトでは 2Gbytes に制限されて居る Windows OS のバージョンに依っては 32bit プロセスでもトータルで 4Gbytes 以上のメモリが利用出来る物が有るが WOW64 では利用出来ない 猶 32bit プロセスを 1 つ起動する毎に 対応する WOW64 が 1 つ起動する 夫々の WOW64 毎に 2Gbytes のメモリ空間 ( を使用する 32bit プロセス ) が実行出来るので 例えば 16Gbytes の物理メモリを持つシステムなら 理論的には 2Gbytes の 32bit プロセスを最大で 7 個程度起動出来る (Windows OS や WOW64 自身が利用するメモリが必要なので 実際には此処迄利用出来ない ) 此 -6-

7 れは 32bit 版の Windows OS と比べると 大きな利点で有る 例えば 32bit 版の Windows 7 では 最大 4Gbytes の物理メモリしか利用出来ないからで有る 32bit プロセスは 64bit の DLL をロード出来ない ( リソース而巳の DLL ならロード可能 ) 16bit アプリケーション (Win16 アプリケーション ) を呼び出す事は出来ない Win32 や Win64 API で利用されるハンドル情報は 16bit 幅には格納出来ないので 16bit アプリケーションに渡したり 結果を受け取ったり出来ない 其の為 WOW64 では Win16 アプリケーションを実行出来ない Virtual DOS Machine (VDM 所謂 DOS 窓 ) 用の特別な API はサポートされて居ない 64bit CPU とは何か? 64bit OS を利用する為には AMD64 や Intel 64 と謂った 64bit CPU が必須で有る 具体的には インテルの Intel 64 か AMD の AMD64 と謂う機能を備えた CPU が必要と成る ローエンドの CPU を除き 最近では此等 64bit 命令セットをサポートした CPU が多く出荷されて居るし 既に使って居るユーザーも多いかも知れない 64bit CPU とは一般的に 汎用レジスタ ( 数値データやポインタ等を格納して置く為の一時的な領域 ) のデータ幅が 64bit に成って居る CPU の事を指す 32bit の x86 アーキテクチャを拡張して設計された x64 アーキテクチャの場合は 次の様に成って居る -7-

8 64bit CPU(x64 アーキテクチャ ) のレジスタ セット x64 アーキテクチャの CPU をプログラマの視点から見た場合のモデル 64bit 幅の汎用レジスタが 16 本利用出来る (x86 では 32bit 幅のレジスタが 8 本しか無かった ) 汎用レジスタにはポインタや整数データを格納出来る ポインタとして利用する場合は 64bit 全体を利用するが 数値データを格納する場合は 8bit や 16bit 32bit 丈を利用する事も可能 猶悪名高きセグメント レジスタも未だに残って居るが 64bit モードで使用して居る場合は其の役割は非常に限定的で有る SIMD レジスタは浮動小数点データやパック形式の整数データを格納し マルチメディア データや 3D グラフィックス等の SIMD データ処理で利用される 但し SIMD 用レジスタや SIMD 命令は x86 や x64 と謂う基本的なアーキテクチャとは関係なく CPU の進化に合わせて 随時機能強化されて居る 以下 x64 アーキテクチャに於ける強化点等に付いて観て行こう 拡張された汎用レジスタ群 32bit の x86 アーキテクチャと比較した場合の一番の違いは 各レジスタのデータ幅が 32bit から 64bit に拡大され 更にレジスタの本数も 8 本から 16 本に増えて居るところに有る (R8~R15 は 64bit モードで而巳利用可能 ) レジスタ幅が 64bit に成って居る為 ポインタとして利用すると 理論的には 2 の 64 乗 bytes (16Exabytes) のアドレス空間を 1 つのレジスタで指し示す事が出来るし 数値データを格納すれば 64bit 幅のデータを 1 つの命令で処理 ( 四則演算や論理演算等が ) 出来る 4Gbytes 以上のメモリをアクセスする為には 64bit 幅のポインタは必須だし 32bit を超えるデータ (64bit のデータ ) でも 1 つの命令で処理出来る 但し必要に応じてレジスタを 8bit や 16bit 32bit にも分割して利用出来る様に成って居る 図中に記述されて居る AL や AX EAX は 64bit の RAX レジスタを分割して利用する場合の呼び名で有る ( 場合に依っては AX レジスタの上位 8bit 丈を使うと謂った事も可能 ) 亦レジスタの本数が増えて居る為 外部メモリを使わずにレジスタ内丈で処理出来るケースが増え 其の分パフォーマンスの向上が期待出来る 従来の x86 アーキテクチャでは汎用レジスタは 8 本しか無い為 関数内で尐し複雑な処理を行おうとすると (C 言語で謂えば 関数内の処理コードが長く成ると ) 何うしても処理中に幾つかのレジスタの内容をメモリに退避しなければなら無かった CPU には高速なキャッシュ メモリが装備されて居るとは謂え メモリに対して読み書きを行うと 結局は ( キャッシュと比較すると ) 低速なメイン メモリへのアクセスを引き起こすし マルチコア システムで有れば CPU やコア間でのアクセスの調停等のオーバーヘッドが必要に成る レジスタが多ければ メモリへのアクセスを抑える事で 同じ処理で有っても x86 の場合よりも高速に実行出来る可能性が高く成る 強化された命令セット x64 アーキテクチャは 32bit で主流で有った x86 アーキテクチャをベースにして 64bit レジスタの追加や 64bit 演算が可能な様に拡張したアーキテクチャで有る 元の x86 の命令セットを其の儘にして 64bit 処理命令等を付け加えて居る為 煩雑な命令コード体系等は粗其の儘だが アドレッシング モードを整理する等して尐し改良されて居る 尤も 現在では手動でアセンブリ言語のコードを書く事も無い為 余り気にする必要は無いが 64bit 版 Windows OS に於けるデータ モデル 64bit CPU だからと謂って総てのデータを 64bit 幅として扱う必要は無い 例えば C/C++ 言語の char 型は 8bit で構わないし int 型も 32bit で十分な事が多い int や long 型を無理に 64bit 幅に拡大して -8-

9 了うと データを格納するのに必要なメモリ領域も増えるし メモリ アクセス時のデータ転送量も増え 結果的にパフォーマンスの低下を招く可能性が有る 其処で 64bit 版の Windows OS(Win64) では 所謂 LLP64 と謂うデータ モデルを採用して居る モデル short int long long long ポインタ OS 16bit 32bit 32bit 64bit 32bit Win32 LLP64 16bit 32bit 32bit 64bit 64bit Win64 LP64 16bit 32bit 64bit 64bit 64bit UNIX 等 ILP64 16bit 64bit 64bit 64bit 64bit UNIX 等 64bit CPU に於けるデータ モデルの種類 32bit アーキテクチャから 64bit アーキテクチャへの移行に当たって利用されるデータ モデル 64bit CPU への移行は Windows OS 丈で無く UNIX や Linux 等 他の OS でも直面する問題で有る 64bit CPU なのだから int 型や long 型も 64bit にするのは自然な発想で有り UNIX や Linux 等では此のモデルを採用して居る事が多い 此れに対して Windows OS の場合は過去との互換性を最大限重視して int/long 型を 32bit 幅の儘にして居る I は int P はポインタ L は long LL は long long の略 例えば LLP64 とは long long とポインタが 64bit と謂う意味 LLP64 とは long long 型 (Visual C++ で謂うと int64 型 ) と ポインタは 64bit にするが int 型と long 型は 32bit 版の Windows OS(Win32) の場合と同様に 32bit の儘にすると謂うデータ モデルで有る 64bit プログラムで有っても int は 32bit で充分な事が多いので 此の様なモデルが使われる事が有る Windows OS の場合は 32bit のプログラム (Win32 アプリケーション ) との互換性を重視して LLP64 モデルが採用されて居る LLP64 モデルでは int 型も long 型も 32bit の場合と同じで有る 其の為ソース コードに対して殆ど修正を加える事なく 粗其の儘利用出来る 特に Win64 の API 呼び出しのパラメータも其の儘利用出来るので 移植性が高く成る ( 但しポインタは 64bit に拡大されて居るので ポインタをバイナリ データとして取り扱う場合等は修正が必要 ) Windows OS に於ける関数の呼び出し規約 関数の呼び出し規約とは アプリケーション内の関数呼び出しや DLL 呼び出し等に於いて パラメータ ( 引数データ ) を何の様にして渡すか 結果を何の様にして返すか等を決めた規定で有る 此れが異成って居るとプログラムを相互に呼び出す事が出来ないし 外部のライブラリを呼び出す事も出来なく成る 64bit 版の Windows OS では x64 アーキテクチャで増加したレジスタを活用し パラメータを成る可くレジスタ経由で受け渡す事にして居る 32bit 版の Windows OS の場合はスタック ( メモリ ) を使ってパラメータや結果を受け渡しして居たので 何うしてもメイン メモリへのアクセスを避ける事が出来なかった 此の様な呼び出し規約の改善の結果 若干だが 64bit 版の方がパフォーマンスが向上する可能性が有る 項目 32bit Windows OS 64bit Windows OS 関数内で保存しなくてもよいレジスタ 関数内で保存すべきレジスタ eax ecx edx ebx esi edi ebp rax rcx rdx r8 r9 r10 r11 rbx rsi rdi rbp r12 r13 r14 r15-9-

10 項目 32bit Windows OS 64bit Windows OS cdecl 呼び出し Win32( stdcall) 呼び出し 引数は右から左へ評価して ス 最初の 4 つのパラメータは rcx rdx r8 タックへプッシュ r9 で渡す 呼び出し側がスタックを戻す 最初の 4 つの浮動小数点数は xmm0~xmm3 引数は右から左へ評価して スタックへプッシュ 呼び出された側がスタックを戻す 結果の戻し方 eax 若しくは edx:eax rax 若しくは xmm0 で渡す 最初の 4 つのパラメータ分のスタックは呼び出し側で予約して置く 5 つ目以降はスタックへプッシュ 呼び出し規約は 1 種類而巳 32bit と 64bit の Windows プログラムに於ける関数の呼び出し規約関数呼び出しに於ける引数や結果の渡し方 及び関数内で保存するべきレジスタは OS や環境に依って決まって居る 此の規約の御蔭で 関数や DLL 言語に依らず相互に呼び出しが可能に成って居る 64bit 版の Windows OS では引数や結果は成る可くレジスタを使って受け渡す事に依り メモリへのアクセスを抑え パフォーマンスの向上を図って居る 64bit コードの例 64bit プログラムでは実際に何の様なコードが利用されて居るのか 其の一部を観てみよう 此れはデバッガでメモ帳 (notepad.exe) のコードを表示させたところで有る 32bit 版コードの例 64bit 版コードの例 32bit と 64bit のコードの例此れは 32bit 版と 64bit 版のメモ帳のコード例 デバッガで (Debugging Tools for Windows Windows の開発者向けツールに含まれて居る ) Windows 7 の 32bit 版と 64bit 版のメモ帳の一部を逆アセンブルして居る 尐々解り辛いかも知れないが 32bit 版の方はメモリへのアクセスが多いが ( 関数呼び出しの call 命令の前に 引数渡しの為に push 命令が多く使われて居る ) 64bit 版の方はレジスタを多く使い メモリへのアクセスは尐なく成って居る メモ帳の様なインタラクティブなアプリケーションでは差は殆どないが x64 CPU で増加したレジスタを旨く使う事に依り CPU バウンドな計算処理ならパフォーマンスが大きく向上する可能性が有る 64bit プログラムは 32bit プログラムよりも速いのか? 扨て大幅に機能強化されて居る 64bit CPU と 高速化を考慮して居る Windows OS の 64bit 呼び出し規約で有るが 64bit ネイティブのアプリケーションを実行すると何の程度高速化されるのか 気に成る処で有る 其処で CINEBENCH R11.5 と謂うベンチマーク プログラムを実行して観た 項目 32bit 64bit 64bit 32bit CINEBENCH R11.5 OpenGL ベンチ 57.42fps 60.10fps +4.7% CINEBENCH R11.5 CPU ベンチ 3.72pts 4.04pts +8.6% -10-

11 ベンチマーク結果 Core i GHz(HTT オフ ) メモリ 12Gbytes Radeon HD5770 Windows 7 Ultimate x64 Edition と謂うシステム上で 32bit 版と 64bit 版のプログラム (CINEBENCH) を実行して測定 32bit 版と 64bit 版のアプリケーションの違いを観るのが目的なので 孰れも同じ 64bit 版の Windows 7 上で測定して居る OpenGL ベンチはグラフィックス処理が多く CPU の bit 数は余り関係しない処理で有る 64bit 化に依る速度の向上は 5% 弱しかない CPU ベンチはレイトレーシングに依るグラフィックスの計算を行う処理で有る 1 割弱だが 64bit の方が速く成って居る事が解る 更にメモリを使ったり CPU に依る計算を多用したりするアプリケーションならば此の差はもう尐し開くと思われる 但し 64bit CPU にしたからと謂って 32bit CPU の 2 倍速く成ると謂った事は先ず無い 精々 1 割から 2 割高速化する程度で有る 他にも幾つかベンチマーク等を実行して観たが 抑もクライアント用途向けでは 32bit OS でも充分なプログラムやアプリケーションが多く 64bit OS でなければ実行出来ないと謂ったプログラムは殆ど無い と成ると 現状では矢張りオーバー 4Gbytes のメモリが利用出来る と謂う点が 64bit Windows の一番のメリットと謂えるだろう 猶サーバ用途で既に 64bit 専用アプリケーションが幾つか登場して居るし 大容量のメモリを要求する処理も尐なくないので サーバ環境では 64bit システムの優位性が揺らぐ事はないだろう Win64 で広がるプロセス アドレス空間 次は 64bit Windows 環境に於けるプロセス モデルに付いて観てみよう 前回述べた様に 64bit Windows を利用する大きなメリットの 1 つとして アプリケーションで利用可能なメモリが増加すると謂う点が有る 具体的には 次の様にユーザー プロセス空間が拡大する アドレス空間 32bit 32bit /3GB 64bit ユーザー空間 2Gbytes 3Gbytes 8Tbytes カーネル空間 2Gbytes 1Gbytes 16Ebytes*1 Windows OS で利用可能な最大アドレス空間サイズ ユーザー空間 は 1 プロセス毎に利用可能なメモリ アドレス空間 1 つのプロセス毎に例えば 32bit の Windows OS では最大 2Gbytes のアドレス空間が利用出来る 32bit は 32bit Windows OS (Win32) 64bit は 64bit Windows OS(Win64) に於けるアドレス空間割り当て 32bit /3GB は /3GB オプションを有効した 32bit 版 Windows OS 此のオプションを有効にすると ユーザー空間が 1Gbytes 拡大される 此れは 32bit 版 Windows で而巳指定可能なオプション ( 関連記事の TIPS 参照 ) *1:64bit 版の Windows OS では其の潤沢なアドレス空間を利用して 64bit アドレス空間の末尾に 256Tbytes 程度の領域を確保し ( アドレス 0xffff0800_ 以降 ) 其の中に各種カーネル コンポーネント等を分散して配置して居る 従来の 32bit Windows では 1 プロセス当たりのユーザー空間は最大 2Gbytes であった物が 64bit Windows では 8Tbytes(8192Gbytes) に迄拡大して居る 勿論此れ丈のサイズのプログラム コードやデータを作成する訳では無い 実際にはユーザー プロセス空間には プログラム コードやデータ スタック等が置かれる丈でなく ファイル マッピングや共有メモリ DLL 等 様々な物が配置されるので 広過ぎると謂う事は無い -11-

12 猶 64bit CPU なのだから 最大で 16Ebytes(2 の 64 乗 ) のプロセス空間をサポートする事も不可能ではないだろうが 実装上の理由等に依り 現在では此のサイズに制限されて居る 抑も Windows OS で管理可能な最大物理メモリ サイズは 2Tbytes しか無いし (Windows Server 2008 R2 Enterprise Edition に於ける制限 上述の関連記事参照 ) 現在販売されて居る実際の CPU では 物理アドレス バス幅は最大でも 48bit しか出力されて居らず 256Tbytes(2 の 48 乗 ) 迄しかアドレッシング出来ない 仮想アドレス空間を広くすると ページングの為の管理用メモリ領域 ( 仮想アドレス空間を指し示す為のページ テーブル エントリ等 ) が多く必要に成り メモリの利用効率が悪く成る 其の為 現在の Windows OS では此の様な制限が設けられて居る

13 32bit 版コードの例 -13-

14 64bit 版コードの例 -14-