私も、節電協力のためマシンを稼動しっぱなしにすることができず、3つの話題の大型連載予定だった記事を書けずにおります。
省エネPCでの再考になるかと思いますが、ご理解のほどどうぞよろしくお願いいたします。

まずはスクリーンショットをざーっと並べてみました。メモリ使用量が減っているのがおわかりいただけるでしょうか？
また、Windows Server 2008 と Windows Server 2008 R2 で CPU の使い方が微妙に変わっています。

実はこれらの数字の読み方にもコツがあるんです。次回からなぜ軽くなったのか、コツとは何かについて取り上げたいと思います。

(って、今回はなにもなし？)

Windows Server 2008 Enterprise Edition x64 (Server Core)

Windows Server 2008 R2 Enterprise Edition (Server Core)

Windows 7 Enterprise Edition x86 (Forefront Client Security など一通り入れています)

Network and Sharing Center の Windows Firewall → Advanced Settings → Inbound Rules を確認したところ、

Remote Desktop - RemoteFX (TCP-In) の項目が増えていました。既定では無効にされているようです。
接続に失敗するようでしたら、一旦 RemoteFX 3D Video Adapter を削除し、設定を確認してみてはいかがでしょうか。

実は Windows 7 RTM, Windows 2008 R2 RTM における UMS (User Mode Scheduler) には yield時にリソースリークが起きる可能性があり、そのことが Microsoft Visual Studio 10.0/VC/crt/src/UMSFreeVirtualProcessorRoot.cpp にも書かれています。

関連する事項として “Visual Studio 2010 SP1 Interim Fix List - Jason Zander's WebLog - Site Home - MSDN Blogs” でも触れられている通り、
https://blogs.msdn.com/b/jasonz/archive/2010/12/20/visual-studio-2010-service-pack-1-beta-feedback.aspx

Visual Studio 2010 VC++ Concurrent Runtime libraries leak memory
https://connect.microsoft.com/VisualStudio/feedback/details/560544

も解消される見込みとなりました。これで安心して UMS を活用できるようになったわけです。

また、素晴らしいタイミングで AMD の E-350, E-240, C-50 そして、C-30 (DirectX 11 対応、シェーダー数 80) が発表されました。これは RADEON HD5450 に相当するものらしいのですが、RADEON HD4850 を購入してファンの騒音が許せず、HD3450 を使い続けていた私としては複雑な気分でもありますが…。
あれだけ CPU の周波数の向上は鈍化傾向にあると言い続けておきながら、TDP の限界に挑むとは思いもよらず。2011年のパフォーマンスデスクトップは 4物理コアまたは、4論理コア (SMT) + CPU 内蔵グラフィックスといった傾向になるのでしょうか。

さておき、ついに内蔵グラフィックスでも DirectCompute を利用したり、CPU側でも UMS による軽量な並列化が可能になったりと、ネイティブもまだ捨てたものじゃないな～？といった状態がようやく実現されつつあります。
MSDN Magazine Jan.2011 「データ処理: 並列処理とパフォーマンス」に思うこと (1) も、ちまちまと進めて参りますが、CPU と GPU が 1つの石に載るこの時代も取り上げないわけにはいきませんよね。

お財布が厳しいところですが、E-350 あたりを入手して、CPU + APU の可能性について探っていこうと思います。

私もこっそり自腹で Extra Small (XS) Instance に VM Role を上げて Remote Desktop で運用していたりしますが、なんと Windows Azure Platform 導入特別プランが Extra Small Instance 750時間、ストレージ 500MB、SQL Azure 1GB (3か月) が 6月末まで無料！
https://www.microsoft.com/windowsazure/offers/popup/popup.aspx?lang=ja&locale=ja-JP&offer=MS-AZR-0001P

NoSQL について一言言いたい今日この頃なのですが、このお試し期間を逃す手はありません、ぜひお試しを。
https://mocp.microsoftonline.com/site/default.aspx

お手元に SQL Server の管理コンソールも Visual Studio もない場合には SQL Server 2008 R2 評価版を導入するというのも一つの手です。
https://msdn.microsoft.com/ja-jp/evalcenter/ff459612

Windows Azure に必要な情報は MSDN から。
https://msdn.microsoft.com/ja-jp/ff380142 

この記事においては UTF-8 でエンコードされた非常に巨大なタブ区切りファイル (906,055,326 Bytes, 7,582,271行) に記された、山の名前と標高、国名から特定の条件で抽出を行う処理を C#, Native において比較しています。しかし、結論やベンチマークの結果にはいささか疑問が残ります。今回はこの例を用いて、並列化における問題点について考えてみたいと思います。

並列化を行う際に最も重要なことは、何がボトルネックになっているか、並列化可能な個所の調査です。表題の記事では最終節「確認していない問題」において

・プロファイリング ツールや Visual Studio 2010 ツールを使用して、パフォーマンスのボトルネックを特定および削除できるかどうか。

と記載されているので、まずは記事の図3, 4 のコードをプロファイリングしてどのような問題があるのか調査してみたいと思います。

なお、環境は Phenom II X4 940 (3.0GHz), RAM 12GB, Windows Server 2008 R2, .NET Framework 4.0 (特に指定のない場合、既定のの Workstation, Concurrent GC) Any CPU (x64) です。実行時間の計測には Stopwatch とProcess.GetCurrentProcess().TotalProcessorTime を用いています。Workstation GC では既定のスレッドプールのサイズが十分な量ではない (初期値 4) のでスレッドプールの最小値を 16 に指定してあります。 

図1 記事のコードの実行時間

まずは実行時間を見てみましょう。左軸が、WithDegreeOfParallelism() に指定している最大並列度、左縦軸がプログラムの実行時間 (ms)、右縦軸がプロセッサ実行時間 (ms) です。AsParallel() を指定せずに通常の LINQ として実行したものを便宜的に DOP = 0 としてプロットしています。計測は各最大並列度毎に 5回行い、最も実行時間の短かったものをプロットしています。5度の計測における差は実行時間の 1% 程度でした。また、対象となるファイルは約 900MBもの容量がありますが、全てキャッシュに載った状態での実行結果となります。

さて、図1から読み取れるように、期待に反して並列度を上げても実行時間は変わらないどころか、純粋に直列のクエリとして実行した結果が最も速いという結果が得られました。一方で並列度を上げると総CPU使用時間はマシンに搭載されている 4コア分、およそ 3.7倍にまで膨れ上がっています。これは何故でしょうか？

プログラムを単純な部分に分解して問題を調べてみましょう。まずは入力部分に着目してみたいと思います。

Parallel.ForEach(
    File.ReadLines(inFile),
    new ParallelOptions() { MaxDegreeOfParallelism = dop },
    _ => { });

図2 単純な行の読み出し (並列) 

foreach (var line in File.ReadLines(inFile))
    ;

図3 単純な行の読み出し (直列)

図2、3 のプログラムを実行した結果を図1と同様にプロットしてみます。

図4 単純な行の読み出しの結果

図1 と同様の傾向が図4 から読み取れることがわかります。元のプログラムの実行時間の 7割以上が図2に示すコードで占められていることから、今回の並列化における最大の問題点は読み出しにあると推定することが可能でしょう。

ここで、Visual Studio 2010 の強力なプロファイラーの出番です。全体像を把握するために、まずは同時実行プロファイリングにより動作の様子を調べ、サンプリングでどの箇所にボトルネックが生じているのか調べてみます。

オリジナルのコードを最大並列度 16 で実行した様子を図5 に示します。

図5 同時実行プロファイリングの結果

これではわけがわからないので拡大表示してみます。

図6 の表示されているタイムライン プロファイルの結果から、実行が占める割合から 16並列の 24% である 4コア分は消費されていることがわかります。実際、図5 の様子からも並列にプログラムは実行されているようです。しかし、プログラムの実行時間は冒頭で述べたとおり、全く高速化されていません。

これは、改行位置が前回の取得結果に依存するため、ReadLines() を並列に実行することができないためです。したがって実行状態は 1/16 になってもおかしくないはずですが、どうやら行いたい処理の他に重たい何かが走っているようです。そこで、サンプリング プロファイリングによって問題を特定してみたいと思います。

図7 サンプリング プロファイルの結果

この結果より、最も CPU 時間を消費している関数は DynamicPartitionerForIEnumerable.InternalPartitionEnumerator.GrabNextChunk(int) が呼び出している JITutil_MonContention, File.<InternalReadLines>.MoveNext() であることがわかります。

GrabNextChunk(int) をクリックして関数の詳細を表示してみましょう。

図8 関数の詳細

File.ReadLines() が返す IEnumerable<string> に対して、動的な負荷分散のため複数の結果を格納した新しい IEnumerable<string> を生成しようと試みていることがわかります。しかし、関数の中身をよく見ると、GrabNextChunk() の占める割合 98.4% の内訳として File.<InternalReadLines>.MoveNext() が占める割合は22.6%、つまりプログラム全体のたった 22.2% であり、競合の調停のための関数である JITutil_MonContention, JIT_MonenterWorker_InlineGetThread_PatchLevel の2つの関数によってプログラム全体の 73.7% の時間が費やされていることがわかります。これが、並列度を上げることによって CPU 消費時間が増加する一方で実行時間はほとんど変わらない原因です。

このようにプロファイラーを用いることで非常に簡単に問題を特定することが可能になります。

次回は並列にファイルを読み込む方法について検討し、元記事の結論について検討したいと思います。10倍速くらいにはできるでしょう。

※ 追記) 踏み込んだ内容になるため、全5部程度の構成でお送りしたいと思います。
もしよろしければ RSS での購読をお勧めいたします。 

https://blogs.msdn.com/b/masaki/rss.aspx

先日アナウンスされた Windows Server 2008 R2 SP1 が MSDN Subscriber 向けに配布開始されました！
一般向けにも配布開始されています。 

これで Windows Server 2008 R2 の新機能、Dynamic Memory, RemoteFX が正式に使えるようになりますね。
クライアントである Windows 7 と共通の Service Pack となりますが、Service Pack なしでも十分に安定しているため、新機能を活用されたい方以外は今すぐ適用する必要はないかと思います。

Service Pack 1 に含まれる Hotfix などの一覧は https://www.microsoft.com/downloads/details.aspx?FamilyID=61924cea-83fe-46e9-96d8-027ae59ddc11&displayLang=ja から。

Windows Update での自動更新を一時的に避けたい方は Windows Service Pack ブロック ツールキット をご検討ください。

※ 一般配布開始に合わせて内容を修正しました。

・CLR/H (Community for Learning and Research) 第47回勉強会の資料について
https://clr-h.jp/forums/p/473/3500.aspx

また、CodeRecipe のほうでも TPL などのコンテンツが増量されています。(C#, VB のサンプルコードあり)

• 並列プログラミング - TPL によるデータの並列処理
• 並列プログラミング - TPL によるタスクの並列処理
• 並列プログラミング - PLINQ

こちらも参照していただき、CLR/H さんで講演した、今までのデータ並列ではなく、タスク並列の考え方を取り入れてプログラミングしてみてはいかがでしょう？

(slide 11)

(slide 15) # しっかし、UMS 好きだなあ、自分

(slide 32 分割アルゴリズム)

続きは CLR/H さんで！

さておき、1年弱にわたって Windows 7 をネタに松崎と連載を行ってきましたが、連載の総集編として20ページにわたり特集記事を書きました。Windows 7 の機能を使ったプログラミングについて一通り網羅していますので、ぜひお読みいただけたらと思います。(立ち読みじゃなくて買ってね！ちなみに特集1 はAndroidです…。)

日経ソフトウエア

Amazon.co.jp で買っちゃう ->
https://www.amazon.co.jp/dp/B003H2ECHA/

ところで、これらのエラーメッセージ、エラーコードがどのような区分になっているかご存知でしょうか？今回は、よく目にするものと、その見分け方について簡単にご紹介させていただきたいと思います。

エラーを正しく理解することは正確な報告を可能にし、また問題解決にも役立ちます。

1. .NET Framework における例外

こちらは (見た目は) わかりやすいですよね。例えば何か存在しないファイルを開こうとすると…

Unhandled Exception: System.IO.FileNotFoundException: Could not find file 'C:\Demos\ExceptionDemo\bin\Debug\何か。'.
File name: 'C:\Demos\ExceptionDemo\bin\Debug\何か。'
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
…
   at System.IO.StreamReader..ctor(String path, Boolean detectEncodingFromByteOrderMarks)
   at ExceptionDemo.Program.Main(String[] args) in C:\Demos\ExceptionDemo\Program.cs:line 12

このような例外が発生すると思います。全ての例外は System.Exception クラスを継承しなければならないため、System.Exception クラスを通して、

Data …追加情報。この例では空のコレクション
HelpLink …ヘルプへの URN。この例では null
InnerException …この例外を発生させる元となった例外。この例では null
Message …例外の説明。この例では “Could not find file 'C:\Demos\ExceptionDemo\bin\Debug\何か。'.”
Source …例外を投げたアプリケーションやオブジェクト。この例では “mscorlib” つまり、.NET Framework の基本ライブラリ
StackTrace …例外が投げられるまでの呼び出しの流れ。この例では “at System.IO… ~ Program.cs:line 12”
TargetSite …例外を投げたメソッド。この例では {Void WinIOError(Int32, System.String)}

さらに、今回は System.Exception –> … –> System.IO.FileNotFoundException と継承されているので、FileNotFoundException 内の

FileName …ファイル名。この場合は @”C:\Demos\ExceptionDemo\bin\Debug\何か。”

などが利用できます。さて、問題解決には何が重要になるでしょうか？「例外が発生した！」と報告しても誰にも原因はわからないですよね。
例外の場合、例外の種類、StackTrace と引数が重要になります。どの関数を呼んだ事で例外が発生したのかを知り、呼び出した関数への引数に問題がなかったかがわかれば再現させることが容易になります。例えばこの場合ですと、

「Program.cs の 12行目、System.IO.StreamReader..ctor(String path, Boolean detectEncodingFromByteOrderMarks) の呼び出しにおいて System.IO.FileNotFound が発生、引数には “何か。” が与えられていた。」と報告すれば、「”何か。” という存在しないファイルを読み出そうとしたのだな」ということが確実に相手に伝わります。

複雑な問題においては、InnerException にも着目しましょう。根本的な原因がそこに書かれている場合もあります。フォーラムなどで質問する際には例外に含まれる情報を活用いただければと思います。

2. Win32, COM におけるエラーコード

.NET における例外はこのくらいにして Win32, COM (Component Object Model) においてはどのようなエラーが生じるのでしょうか。Native のプログラムを書いていると 0xC0000005 というエラーコードに遭遇することが多いと思いますが、これは Win32 における一般保護例外、つまりアクセスできない領域に対するエラーのコードです。はて、なぜこんなに長いエラーコードになっているのでしょう？実はエラーコードの先頭には意味がついています。エラーコードの 32bit の中身を分解すると以下のようになります。

Win32 の場合

| Severity Code (2bit) | Customer code flag (1bit) | Reserved (1bit) | Facility Code (12bit) | Code (16bit) |

COM の場合

| Severity Code (1bit) | Reserved (4bit) | Facility Code (11bit) | Code (16bit) |

ここで、Severity Code は重要度を表しています。Win32 の場合、00b が成功、01b が情報を含むもの、10b が警告、11b がエラーとなっています。Windows が返すエラーには Customer Code Flag は設定されていないので先頭 4bit …つまり、16進数表記をした際の最初の一文字がエラーコードの重要度となります。0xC0000005 は ‘C’ で始まっているので 0xC = 1100b つまりエラーを示しています。ただ、警告や情報は滅多に見かけないので 0xC0123456 といったエラーコードを目にすることになります。

一般保護例外 0xC0000005 は、Severity = 11b から「エラー」であり、Code = 5 (ERROR_ACCESS_DENIED) から「Access is denied. (アクセスが拒否された)」ことが読み取れるのです。

さて、COM の場合は先頭が少し異なりますよね？ Severity Code が 1bit となっています。なので COM のエラーコード (HRESULT) は 0x80123456 といった形になります。

ここがポイントです！つまり、たいていの場合、0xC で始まっているものは Win32 のエラーコード、0x8 で始まっているものは COM のエラーコードという見分け方ができるのです。もし 10進数でエラーコードが –1073741824 のような負の大きな値で –1 始まりのものは Win32, –2147483648 のような –2 始まりのものは COM のエラーコードである可能性が高いです。

これは電卓をプログラマモード (関数モード) にすることで変換することが可能です。エラーコードを検索しても出てこない場合には、16進数のコードを 10進数に直してみる、あるいはその逆を行うことで解決策が引っかかる可能性が高くなります。

また、下位 16bit にエラーの内容を示すコードが入っているため、そこだけ抜き出して Error Lookup ツールなどを利用すると何かヒントが得られるかも知れません。

3. 一般的なエラーコード

C言語の関数の結果、またイベントログに記載されるエラーコードは、このような長いエラーコード形式ではないのでせいぜい数千までの値を取ることが多いと思います。そのような場合には 16進数で検索せず、10進数で検索するほうがよい結果が得られる可能性が高いと思います。Windows SDK に含まれる、WinError.h を開いて検索するというのも一つの手です。

まとめ。

例外など、型情報が得られるものについては例外の種類を見分ける。

8 で始まっている、または –21… という大きな負の値なら COM のエラーコードであることを疑う。
C で始まっている、または –10… という大きな負の値なら Win32 のエラーコードであることを疑う。
覚えられる範囲の数字なら一般的なエラーコードを疑う。

もしかしたら 10進数で負の値になっているものは 16進数に変換することで解決策が見つかるかも知れません。

このように、ちょっとした見分けかたを覚えておくだけでもエラーコードからより多くの情報、または検索に頼った問題解決のヒントが得られます。

# 訂正しました。mayukiさん、つーささん、ありがとうございます！