今日のコンピューターのほとんどは64ビット版のWindowsを搭載しており、RAMは最小限であることが多いです。このため、これらのシステムのパフォーマンスがどの程度なのかという疑問が生じます。これは特に、ユーザーがこれらの新しいコンピューターで従来の32ビットソフトウェアを実行したい場合に顕著です。
興味深い疑問があります。64ビット版のWindowsで32ビットアプリケーションを実行するには、より多くのRAMが必要ですか、それともより少ないRAMが必要ですか?今週、Bruce Epperが調べてくれました。
読者からの質問:
64ビットWindowsシステムで32ビットアプリを実行すると、32ビットWindowsオペレーティングシステムで32ビットアプリを実行する場合と比較して、1.5倍のメモリを消費するのは本当ですか?
Bruceの回答:
以前、すべてを64ビットで維持することの利点と欠点、および「混合とマッチング」の影響について説明しました。今日は、32ビットアプリケーションが64ビット版のWindowsでどのように実行されるかを調べます。
64ビットWindowsオペレーティングシステムは、追加のサポートなしでは32ビットWindowsプログラムを実行できません。これらはあまりにも異なります。ポインターやデータ型から、システムコール(プログラムが基礎となるオペレーティングシステムのリソースを使用する方法)まで。それらを互換性のあるものにする方法が必要です。
WoW64について
Windowsは、WoW64 (Windows32 on Windows64)サブシステムを使用して、その違いを補います。これは、x64システムでは32ビットWindowsのミニエミュレーターとして、Itanium (IA64)システムでは本格的なエミュレーターとして機能します。
IA64システムでは、プロセッサの命令とメモリページサイズの違い(x86とx64では4K、IA64では8K)があるため、完全なエミュレーターが必要です。x64プロセッサはx86プロセッサの命令をすべて備えており、同じメモリページサイズを使用しているため、完全なエミュレーターは必要ありません。
どちらの場合も、WoW64は64ビットWindowsカーネルと32ビット版のntdll.dll (これにはWindowsカーネルのコア機能のリストが含まれています)との間のインターフェイスを提供し、カーネルコールを傍受して、Windowsカーネルによって提供されるネイティブの64ビット機能で処理できるように変更します。
これを実現するために、x64/IA64システムでは3つのDLLファイルが使用されます。wow64cpu.dll、wow64win.dll、wow64.dllです。それらの機能は、プロセッサの特性を抽象化し、後に説明するサンクをwin32k.sys (「ウィンドウ」機能を提供)とntoskrnl.exe (エグゼクティブ、カーネル、メモリマネージャー、プロセススケジューラー(コントロールパネルからアクセスできるタスクスケジューラーとは異なる)、およびオペレーティングシステムの他のコア要素を含む)に提供することです。
サンクは、プログラムがシステム内の共通サブルーチンまたは関数を実行できるようにするサブルーチン(単一のタスクを実行する一連の命令と考えてください)です。
この場合、32ビットプログラムのコールスタックから引数を抽出し、それらを64ビットの対応物に変換し、64ビットのシステムコールを行います。コールから戻ると、64ビットの結果を32ビットに戻し、呼び出し元が使用できるようにプログラムのコールスタックにプッシュバックします。
すべてのサンクは、ユーザーモード(権限が制限されている)で行われます。その理由は2つあります。第一に、カーネルモードで実行した場合、セキュリティホール、データ破損、システムクラッシュにつながる可能性のあるコードのバグの影響を最小限に抑えます。
第二に、ユーザーモードとカーネルモードとの間で切り替える際に発生するオーバーヘッドにより、カーネルモード(オペレーティングシステムの重要な部分で使用されるモード)で実行した場合に発生するパフォーマンスへの影響を軽減します。
Itaniumシステムに戻ると、他に重要な違いがいくつかあります。IA64システムでは、2つの追加ファイルを使用します。IA32exec.binはx86ソフトウェアエミュレーターであり、Wowia32x.dllはWoW64とソフトウェアエミュレーターとの間のインターフェイスを提供します。
32ビットプロセスは、これらのファイルと64ビット版のntdll.dllをロードします。これらは、Windows 7より前の32ビットプロセスにロードされる可能性のある唯一の64ビットバイナリです。Windows 7以降には、すべてのプロセスにロードされる別のDLL、apisetschema.dllもあります。
32ビットプロセスが開始されると、Wow64.dllがロードされ、続いて32ビット版のntdll.dllと、%systemroot%\SysWOW64から必要な32ビットDLLがロードされます。これらのファイルのほとんどは32ビットシステムのバイナリと同一ですが、一部のファイルはWOW64で動作が異なるように書き換えられています。
ロードされたDLLのリストを見ると、Win64でプロセスにロードされたDLLが9つあり、Win32システムには存在しないことがわかります。
ここで、ファイルサイズを見て、それらを合計して追加でどのくらいのメモリが使用されているかを判断したくなるかもしれませんが、不正確な結果が得られます。これらのファイルは本質的に共有コンポーネントとして設計されており、その結果、DLLを必要とする最初のファイルがそれをメモリにロードします。
同じDLLを必要とする後続のプログラムは、コンポーネント全体をメモリにロードしません。それらは、すでにロードされているコンポーネントへのポインターを取得し、プロセスにロードされる追加の要素用のRAMを割り当てます。
テストのセットアップ
何が起こっているかを確認するために、Windows 7 Ultimateを実行する仮想マシンを2つ設定し、それぞれに2 GBのRAMを割り当てました。そのうちの1つは32ビット版で、もう1つは64ビット版です。どちらもまったく同じインストールとパッチ適用プロセスを経ました。
両方のシステムにパッチを適用した後、両方のスワップファイルを無効にして、RAMをディスクにページングできないようにすることで、メモリ使用状況をより正確に把握できるようにしました。それが完了すると、LibreOffice 5.0.3.2がインストールされました。
Sysinternals Process Explorerのコピーも両方のマシンに配置されました。これは、メモリ使用状況情報を収集するために使用したツールです。デフォルトの列のセットアップが変更されたので、ワーキングセットとWSプライベートの使用状況を確認できました。
これらのワーキングセットの数は、プログラムによって使用されているRAMの量を反映しています。すでに別のプロセスによってロードされている場合でも、共有ライブラリによって使用されるメモリ量を反映することで、さらに複雑になります。このため、列全体を追加すると、インストールされているRAMよりも合計が大きくなる可能性があります。ワーキングセットは、プロセスに必要なメモリ量を正確に把握するための最良の基準です。
調査しているプロセスは、単独で実行されているわけではありません。さまざまなLibreOfficeプログラムは、別のプロセスであるsoffice.exeを起動し、さらに別のプロセスであるsoffice.binを実行します。各プログラムの効果的なメモリ使用量を確認するには、3つのプロセスの合計を確認する必要があります。
最初のテストでは、Writer、Calc、Impressを個別に開き、データがロードされていない状態でどの程度のメモリを消費するかを確認し、Process Explorerからデータをエクスポートしました。CalcとImpressでは、それぞれ3.7 MBの.xlsファイルと3.9 MBの.pptxファイルを開き、新しいメモリ使用量を記録しました。結果は下の表に示されています。すべてのデータはKB単位です。
大きな驚きがImpressで起こりました。ドキュメントがなければ、64ビットシステムでは4.1%多くのRAMを使用し、ドキュメントがロードされると9.9%少ないRAMを使用しました。他のプレゼンテーションをいくつか見つけましたが、すべてで同様の結果が得られました。64ビットシステムは、32ビットシステムよりも少ないRAMを使用することになりました。
では、64ビット版のWindowsは、32ビットアプリを実行する際に32ビット版よりも多くのRAMを必要とするのでしょうか?一般的には、そうです。
しかし、RAMをアップグレードする必要がありますか?おそらくそうではありません。その差はそれほど大きくありません。1.5倍違うということはありません。
コメントする