アカウント名:
パスワード:
128GBもメモリがあるなら、まじめにLarge Pageの利用による高速化も考えたい。もっとも、アタリ/ハズレがあるし、効果があった場合でも1割ぐらいの性能向上だと聞く。
グループポリシーでSeLockMemoryPrivilege(メモリ内のページのロック)権限をユーザに割り当てておく必要がある。
実行コードのLarge Page対応ならば、レジストリ操作かSDKにあるgflags.exeで+lpgオプション添加で、実行コードが可能であればLarge Pageに配置される。
データページについては、VirtualAlloc() に MEM_LARGE_PAGESフラグを付けて、明示的にアロケーションするんだったかな。
ドライバのLargePage配置がレジストリの[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]のLargePageDriversに指定する。
ユーザが後付けでできるのは、gflags.exeで指定する実行コードのLarge Page対応と、ドライバのLargePage配置ぐらいだけれど、効果なんて5%もあればいい方だから、やめとけ。
CPUのキャッシュのヒットなんか期待できない2MBを超える大規模配列操作などでLargePageをアロケーションして使えば効果は大きいけれど、ユーザが後付けで設定できる実行コードのLargePage配置はたかが知れている。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
Large Page Support (スコア:0)
128GBもメモリがあるなら、まじめにLarge Pageの利用による高速化も考えたい。
もっとも、アタリ/ハズレがあるし、効果があった場合でも1割ぐらいの性能向上だと聞く。
Re:Large Page Support (スコア:0)
グループポリシーでSeLockMemoryPrivilege(メモリ内のページのロック)権限をユーザに割り当てておく必要がある。
実行コードのLarge Page対応ならば、レジストリ操作かSDKにあるgflags.exeで+lpgオプション添加で、実行コードが可能であればLarge Pageに配置される。
データページについては、VirtualAlloc() に MEM_LARGE_PAGESフラグを付けて、明示的にアロケーションするんだったかな。
ドライバのLargePage配置がレジストリの[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]のLargePageDriversに指定する。
ユーザが後付けでできるのは、gflags.exeで指定する実行コードのLarge Page対応と、ドライバのLargePage配置ぐらいだけれど、効果なんて5%もあればいい方だから、やめとけ。
CPUのキャッシュのヒットなんか期待できない2MBを超える大規模配列操作などでLargePageをアロケーションして使えば効果は大きいけれど、ユーザが後付けで設定できる実行コードのLargePage配置はたかが知れている。