XML Mark 1.1 on .NET2.0 RTM

.NET Java

時間が出来たのでもう一度、今度は予め仕様が用意されていた全てのテストを実行してみた。(今回、.NETに関して.NET1.1用にはVisual Studio 2003でビルドしたアセンブリ、.NET2.0用にはVisual Studion 2005でビルドしたアセンブリを使用している)


SAX系のテストではJavaと.NET1.1との差が縮まるのが面白い。後でロジックを調べてみよう。
それにしても.NET2.0はダントツ。同じハードウェアなのに、どうしてこんなに差が出るんだろう。さすがに結果に3倍近くの差が付くと「何か変だ」と思ってしまうんだけど、ここまで劇的に改善された理由は何だったのだろう。
(※.NET2.0が速いのではなく.NET1.1が遅かったのだ、という指摘もあるみたい。.NET1.1の時代にDatasetのリモート渡しが遅くて使い物にならない、という話を良く聞いたが、それはXMLフォーマッタが遅い=XML処理が遅い、ということだったのかな)

ちなみに、全てのテストは4つのスレッドを使用しており、並行にテストを実行している。(INIファイルのAgentsパラメタで並行実行数の制御をしているようだ) テストに使用したサーバは2つのプロセッサを搭載し、HyperThreadingを有効にしているが、タスクマネジャで見ると4基のCPUの使用率はテスト中、常時100%に張りついたままだった。

Microsoftが用意したドキュメント中には、リファレンスのテストプラットホームが紹介されている

ドキュメントにはこの環境で行ったテスト結果も掲載されているのだが、.NET2.0(β2)を使用したDOM系のテストで大体100TPS程度の差を付けられている。Opteron恐るべしなのか、Windows Server 2003恐るべしなのか、J2SE1.5恐るべしなのか。今度、時間があったらこれも調べてみよう。

あと、是非試してみたいのはx64プラットホーム上でのテストだな。

追記
昨日の日記ではテスト環境中のJavaの環境に関して

Sun J2SE1.4 (Hotspot Client VM build 1.4.2_09-b05

と書いたが、これは誤り。実際にはServer-VMを使用するようにJVMパラメタが設定されていた。ちなみにテストに使用されているJVMパラメタは以下の通り

-server -XX:CompileThreshold=100 -XX:+AggressiveHeap -Xms1024M -Xmx1024M

凄まじい設定ではあるなぁ。-XX:+AggressiveHeapはメモリを限界まで使用するオプション。SMP構成、つまり現在出まわっている普通のマルチプロセッサ構成のマシンで非常に効果的なパラメタと言われている。でもチューニングパラメタを解説している文献の中にはこのパラメタと、-Xmsオプションまたは-Xmxオプションを併用してはいけない、と書いているものもあって、どうなんだろう。あと、実際このパラメタを使用するとクラッシュするVMのバージョンもあるらしいす。