連載 .NET＆Windows Vistaへ広がるDirectXの世界 第6回 .NETアプリを軽快にするためのガベージ・コレクション講座 NyaRuRu Microsoft MVP Windows - DirectX（Jan 2004 - Dec 2007） 2007/02/13

Page1 Page2 Page3 Page4

Back Issue

1 DirectXの真実 2 DirectXマスターを目指すあなたが持つべき視点 3 .NET開発者のためのDirectX連携手法 4 XNA Game Studio Expressを触ってみよう！ 5 ゲーム開発者にとってのビルド作業とは？

　マウスやコントローラなどのデバイス入力から、映像や音声の出力までを限りなく実時間に近いタイミングで処理しつづけなければならないアプリケーションがある。身近なところではゲームをその筆頭に挙げることができるだろう。また、近年は様々なジャンルのアプリケーションでコモディティ化が起こっており、機能面での差別化が困難になってきたことから、非機能要求である応答性の良さで製品を選ぶという人も増えているのではなかろうか。その意味では、デスクトップ上で動くアプリケーションはほとんどすべてリアルタイム性が求められているといえる。

　従来、ガベージ・コレクション（以下GC）により非同期的にスレッドが停止する.NETアプリケーションは、応答性が重視される分野には不向きだと言われてきた。これはある意味では事実であるものの、実際には工夫次第でGCの影響をかなり軽減することが可能である。何より、「XNA Field」や「XNA Racer」といったXNAのデモ・ゲームが軽快に動いている以上、同等のレスポンスは何らかの方法で実現可能であると認めなければならない。

　そこで今回は、XNAやWPF（Windows Presentation Foundation）アプリケーションを差別化するポイントとして、GCの影響を軽減することによる応答性の改善について取り上げてみたい。

■はじめに

　GCについて議論するうえで、そもそも何が問題になるのかを整理しておこう。

　まずはパフォーマンスに関してだが、これは第1回で強調したように、大まかにはスループットとレスポンス・タイムの問題に分けることができる。GCに関する議論で、この区別は非常に重要だ。

　スループットはGCの採用により改善が期待できる部分である。例えば、GCを採用しようがしまいが、一定回数のメモリ解放処理は必要だと仮定しよう。もしその仮定が成り立つなら、解放処理をハード・コーディングしたプログラムを不特定多数の環境で動かすより、環境に合わせて解放処理のタイミングを変更できた方が効率よく処理できても不思議はない。

　しかしながら、レスポンス・タイムの安定性という面でこのような最適化は悪影響を持つ。技術的な理由からGCによるメモリ解放はすべてのスレッドを停止させて行うことが多い。その場合、アプリケーションの動作が断続的に停止することになるが、問題はそのタイミングが予測できないことだ。常に一定のレスポンス・タイムを維持したいゲームなどのマルチメディア・アプリケーションでGCが問題視される理由の1つが、このレスポンス・タイムの不安定性、非決定性に関するものである。

　もう1つの大きな軸として、ソフトウェア開発のコストを下げるための手段としてのGCという見方がある。実際、XNAやWPFのメリットとして、GCによってプログラミングが容易になる点を挙げる声も多い。ただし、このうたい文句は若干行き過ぎる傾向があるようで、「メモリについて何も心配しなくていい」といった、理解の放棄を容認するようなことがあっては危ないように思う。筆者としては、あくまで本来自動化されてしかるべきことを、開発者の合意のうえで、実際正しく自動化してくれているにすぎないのがGCである、という立場を取りたい。

　最後にもう1つだけ強調しておきたいことがある。それは、実証の重要性だ。

　「GCが起きる.NETはリアルタイム・アプリケーション構築に向かない」という主張を覆す最善・最短の方法は、相手を納得させられるだけのアプリケーションを実際に作ってみせることだと筆者は考える。結局のところ、「〜できる」ということを最も説得力のある形で示すには、実際にそれをやってみせるのが一番なのだ。

　IronPythonがもともと「CLRが動的言語に向かないこと」を示すために始められたプロジェクトだということは有名だろう。ところがIronPythonはオリジナルのCPythonよりも高速に動作した。やってみないと分からないことの中にこそ、本当の宝石が眠っていると筆者は信じている。GCを恐れるあまり、せっかくのアイデアの芽を自ら摘んでしまうことがないよう祈りたい。

【コラム】.NET GCに関して調べるには？ 　限られた紙面で.NETのGCをどのように解説するか迷ったが、今回の記事ではXNAやWPFアプリケーションを念頭に置きたかったため、詳しく取り上げられなかった多くのテーマが残っている。そこで、.NETのGCに関して正しく学べる情報源を紹介しておきたいと思う。何か疑問に思うことがあれば、まずはこれらの資料に目を通していただきたい。たいていのことについてはすでに言及されているはずだ。 　まず、名著『Advanced Windows』で有名なJeffrey Richter氏の解説および書籍である。特に、『プログラミングMicrosoft .NET Framework 第2版』（監訳：吉松史彰氏）はGCに限らず.NET開発／CLRの仕組み一般のバイブルで、.NETで何か疑問があれば真っ先に参照すべき一冊である。 ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part I ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part II 書籍『プログラミングMicrosoft .NET Framework 第2版』第20章「自動メモリ管理（ガベージコレクション）」 　CLR開発者Rico Mariani氏自身の手による解説記事とBlogも、非常に参考になる。Mariani氏のBlogには、クイズ形式など趣向を凝らした記事が多い。 ガベージ コレクタの基本とパフォーマンスのヒント Rico Mariani's Performance Tidbits Taming the CLR: How to Write Real-Time Managed Code 　続いて、「Microsoft Patterns & Practices」解説記事。 第 5 章 「マネージ コード パフォーマンスの向上」 ガベージ コレクションについての説明 ガベージ コレクションに関するガイドライン 値型と参照型 第 15 章 「.NET アプリケーション パフォーマンスの計測」 CLRとマネージ コード Production Debugging for .NET Framework Applications 　CLR Hosting APIに関して書かれた次の書籍で、CLRが提供する低レベルなGCのカスタマイズ機能について解説されている。洋書だが入手しておいて損はない。 書籍『Customizing the Microsoft .NET Framework Common Language Runtime』第13章「Managing How the CLR Uses Memory」 　このほか、MSDN Blogの中には.NET Compact FrameworkとXbox 360 CLRのGCに関してもいくつかの記事を見つけることができる。 Managed Code Performance on Xbox 360 for XNA: Part 2 - GC and Tools Taming the CLR: How to Write Real-Time Managed Code An Overview of the .Net Compact Framework Garbage Collector

　それでは、GCの動作をモニタリングする手法を紹介し、実際にGCがどのようにアプリケーションのパフォーマンスに影響を与えているのかを見ていくことにしよう。

INDEX
	.NET＆Windows Vistaへ広がるDirectXの世界
	第6回 .NETアプリを軽快にするためのガベージ・コレクション講座
	1．GCの影響を軽減する必要性
	2．GCがアプリケーションに与える影響
	3．GCの発生頻度を抑えるための対策
	4．値型でGCヒープの消費を抑える

　

「.NET＆Windows Vistaへ広がるDirectXの世界」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）