推測するする

元RYOKOせんせの「Photoshopのメモリ節約技術を推測する」シリーズを受けて．
id:ryoko_komachi:20051012:1129160173
id:ryoko_komachi:20051015:1129472787
うちで使ってる Photoshop CS でもちょこっと見てみました．メモリ管理アルゴリズムについては元記事の方で解説が行われそうなので，OS の仮想メモリとの付き合い方という観点に注目していくつか．以下の情報は全て Process Explorer から読み取れます．

1. 起動時にアドレス空間を大量に予約*1．起動時にはその一部のみが Commit される．
2. 必要に応じてコミット済みメモリが増加*2．ただしファイルを閉じても一度増えたコミット済みメモリは減少せず．メニューを色々漁ってみましたが，このコミット済みメモリの開放方法は分かりませんでした．ただしその後の作業でこのコミット済み領域を再利用しているようなので，いわゆる「メモリリーク」とは区別すべきでしょう．
3. 最小化でワーキングセットが激減するところを見ると，特にワーキングセットの保護*3は行っていない模様．
4. 100MB 程度の BMP ファイルで試した限りでは，ファイルの読み書きにメモリマップは使わない．

何のことやらわけ分からんという人には，まずはこの一冊．

インサイド Microsoft Windows 第4版〈上〉 (マイクロソフト公式解説書)

上巻はもうもっているという人も下巻が出ますよと．

インサイドMicrosoft Windows第4版〈下〉 (マイクロソフト公式解説書)

*1:環境設定の「Photoshop の最大使用メモリ」に応じて変化する模様

*2:元RYOKOせんせのところにあるように，省メモリを意識したアルゴリズムになっているようですね

*3:例えば id:NyaRuRu:20050607:p1 で紹介した SC_MINIMIZE のトラップなど．他にも SetProcessWorkingSetSize や VirtualLock を使えばワークエリアを実メモリ上に残しやすくなりますが，そういうこともしていないようです．

MVP Global Summit 2005 : Windows Workflow Foundation

http://msdn.microsoft.com/windowsvista/building/workflow/
某ななしさんお気に入りの Windows Workflow Foundation (WWF) ですが，Don Box 氏の講演が面白かったのでちょいと覗いてみることに．帰りにシアトル市街の本屋で見つけましたよこれ．

Presenting Windows Workflow Foundation

WWF について書き出すとこれまたきりがないぐらい面白く，また無数の応用先が思い浮かぶわけですが*1，身近な例をひとつふたつ挙げてみましょう．
多人数でのゲーム制作では，デザイナさんが更新したデータをゲーム用に自動コンバートしたり，変換に成功したか否かでその後のプロセスを変更したり，結果を必要な人に通知したりする「Workflow」がしばしば必要となります．WWF の世界では，Visual Studio 上で主に視覚的ダイアグラムによって「Workflow」のひな形を作り，必要に応じて C# などの言語で具体的な処理を記述できます*2．スクリーンショットを含んだ紹介が以下にありますので参照してみてください．
http://msdn.microsoft.com/windowsvista/building/workflow/default.aspx?pull=/library/en-us/dnlong/html/WWFIntro.asp
また，日本語資料としてはディベロッパー製品開発統括部 Blog の以下のエントリが参考になります．
http://www.exconn.net/Blogs/team01/archive/2005/09/22/3356.aspx
さて，DirectX 向けのチーム開発を目指す XNA が当初から WWF の存在を前提としていたかどうかはタイミング的にかなり疑問ですが，WWF は XNA の即戦力となる可能性を秘めているように見えます．というのを XNA の偉い人に聞き忘れたのですが，まあ元々 Visual C# チームの方だそうですのでその辺はぬかりなくやってくれるでしょう．

*1:既に Office 12 や BizTalk Server などが対応予定となっています

*2:いわゆる Workflow だけでなく，DirectX のデバイスロストやそれからの復帰のロジックなども WWF のステートマシンで実装する方が恐らく直感的でミスが少ないでしょう．教育的のみならず実用的です

C# と C++ : Memory Allocation (6)

ここでは標準のメモリアロケータのカスタマイズ性について考えてみます．
まず C++ では実装自由度が大きいかわりに，環境全体のメモリアロケータを実行時に置き換えるための共通の枠組みは基本的に存在しません．一般的にはコンパイル時にソースコードレベルでの対応を行います．

• マクロ置換 (Visual C++ の DEBUG_NEW による new の置換など)
• new operator のオーバーロード (GDI+ for C++)
• Bridge パターンによるアロケータの差し替え
  • std::allocator (STL コンテナ)
  • その他 (例えば &o さんのところで紹介されていた Open Dynamics Engine (id:gamesyokunin:20050221#p1) の memory.cpp など)

また C/C++ のライブラリはしばしばメモリ確保/解放処理を一元化するための独自の仕組みを持ちます．例えば ZIP ライブラリとして有名な zlib は，zalloc, zfree という関数ポインタがこの役目を果たしますし，C++ 版の GDI+ はクラスの new 演算子とデストラクタによって独自のメモリ管理を行っています．長い年月を経て，多くの C/C++ のライブラリがお互いに互換性を持たないメモリ管理スキームをそれぞれ発達させてしまっています．もしライブラリを 10 個持ち寄れば，あなたは 10 通りの異なるメモリ管理のシンタックスを使い分けることになるかもしれません．
一方 C# では，およそメモリの割付作業は全てダイレクトに CLR に丸投げされています．またメモリの回収処理も CLR が独自に行います．メモリ管理が CLR レベルで共通化されたことで，従来のようなメモリに関するライブラリごとの約束事といったものは不要になりました．例外は P/Invoke や COM 相互運用といった場面で，ここでは再び相手ごとに適切な方法で適切なメモリ管理を行う必要があります．

Customizing the Microsoft® .NET Framework Common Language Runtime (Pro Developer)

『Customizing the Microsoft.NET Framework Common Language Runtime』によれば，CLR 2.0 はいくつかの重要な基本動作をユーザコードで置き換えることを許しています．もっとも，さすがにマネージドヒープ上に個々のオブジェクトを配置するような部分に関しては介入の余地はないようです．以下の 3 つの interface によって，ユーザは自由に自分の実装を CLR に組み込み，マネージドヒープのサイズを決定したり GC タイミングに関する影響を与たりすることが可能です．またこれは，もし置き換えられるならば環境全体のメモリポリシーが変更されることを意味します．

• IHostMemoryManager
  • IHostMemoryManager::VirtualAlloc
  • IHostMemoryManager::VirtualFree
  • IHostMemoryManager::VirtualQuery
  • IHostMemoryManager::VirtualProtect
  • IHostMemoryManager::CreateMalloc
  • IHostMemoryManager::GetMemoryLoad
  • IHostMemoryManager::RegisterMemoryNorificationCallback
  • IHostMemoryManager::NeedsVirtualAddressSpace
  • IHostMemoryManager::AcquiredVirtualAddressSpace
  • IHostMemoryManager::ReleasedVirtualAddressSpace
• IHostMalloc
  • IHostMalloc::Alloc
  • IHostMalloc::DebugAlloc
  • IHostMalloc::Free
• IHostGCManager
  • IHostGCManager::SuspensionEnding
  • IHostGCManager::SuspensionStarting
  • IHostGCManager::ThreadIsBlockingForSuspension

(訂正:SetGCStartupLimits 等は ICLRGCManager のメソッドでした)

同書によれば，SQL Server 2005 はこれらの拡張性を利用してアンマネージドプロセスの占めるメモリだけでなく SQLCLR のメモリ使用量も考慮に入れた総メモリ使用量が設定値以下に納めることを実現しているそうです．

万物理論

万物理論 (創元SF文庫)

読了．評判通り面白かったです．おかげで徹夜．
全然関係ないけど"Keystone" と「基石」の語感的対応で "A Human" と「亜人類」のそれを思い出した．

Beginning 3D Game Programming (2)

Beginning 3D Game Programming

先日 Beginning 3D Game Programming (id:NyaRuRu:20041226#p1) が届いたのでざっと読んでみました．
付属のサンプルゲームのソースコードを追う形で，3D ゲームを作るための環境設定，描画，入力，サウンド，通信といった一通りの流れについて説明するという流れになっています．また，プログラマブルシェーダや HLSL，テクスチャレンダリング，アプリケーション構成ファイルなどについても触れられています．とは言っても内容はあくまで初学者向けということになっています．掘り下げた内容についてはより専門性の高い書籍や資料に求めた方が良いでしょう．
なおサンプルゲームですが，ソースコードのみの提供なので実行するには各自コンパイルする必要があります．また X ファイルのロードに関して Microsoft.DirectX.Direct3DX はバージョン 1.0.2902.0 用に書かれています．Microsoft DirectX 9.0 SDK Update (December 2004) 付属のバージョン 1.0.2903.0 を使用するとランタイムエラーが発生しますのでご注意を．
Tankers サンプルですが，Debug Runtime で実行していてバグに気付きました．Tankers サンプルの gameEngine.cs は以下のように修正しておくと良いでしょう．
正

// Then minify
if (caps.TextureFilterCaps.SupportsMinifyAnisotropic)
{
    e.Device.SamplerState[0].MinFilter = TextureFilter.Anisotropic;
}
else if (caps.TextureFilterCaps.SupportsMinifyLinear)
{
    e.Device.SamplerState[0].MinFilter = TextureFilter.Linear;
}

誤

// Then minify
if (caps.TextureFilterCaps.SupportsMinifyAnisotropic)
{
    e.Device.SamplerState[0].MagFilter = TextureFilter.Anisotropic;
}
else if (caps.TextureFilterCaps.SupportsMinifyLinear)
{
    e.Device.SamplerState[0].MagFilter = TextureFilter.Linear;
}

Beginning 3D Game Programming

Beginning 3D Game Programming

Tom Miller 氏の MDX 本第二弾です．
12 月末で期限が切れる Amazon のギフト券の使い道を探していたところで，ちょうどいいタイミングでした．
ちなみに書影を拡大してみると "DirectX Summer 2004 SDK Update" とありますね．

Just Like A Present

研究室に行ったら川西さんから宅急便が届いていて，開けてみると Game Programming Gems 3 日本語版 でした．ありがたやありがたや．

Game Programming Gems 3 日本語版