BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Javaでのベンチマークの課題

Javaでのベンチマークの課題

ブックマーク

Elliptic GroupのプログラマであるBrent Boyer氏は健常なJavaベンチマーク(リンク)という2部からなる記事をIBMのDeveloperWorks上で発表した。これは実用性のあるJavaベンチマークの測定における課題について探ったものだ。彼はさまざまなJVMの特異性と現行のコンパイラの最適化についての議論から始める。これらはパフォーマンステストにおいて好ましくない影響をあたえる可能性がある。たとえば使われることのない値を計算する複雑なコードがあったとすると、あるコンパイラではそのコードを除外する最適化をおこない、よってベンチマークテストでもその部分は含まれないことになる。これを示すように、彼のコンピュータで繰り返し実行すると4.9秒かかるコードから、結果を表示するprintInメソッドを除いて同様に実行すると0.08秒しかかからなかった。また彼は時間計測の粒度はOSごとに異なり、ベンチマークの結果を解釈する時にはこのことに留意する必要があるとも指摘する。実例として、Windows XPでは15ミリ秒しか精度のないSystem.currentTimeMillis()(2.6系カーネルのLinuxでは1ミリ秒の精度がある)は時間経過を測る良い手段ではない(System.nanoTime()と比べて)ことを示している。

このような結果が変わる振る舞いについて述べた後で、Boyer氏はより影響の大きい、しかし一般的にベンチマークでは考慮されないJVMのキャッシングやリソース再利用(たとえばガベージコレクションやオブジェクトのファイナライズ)について論評している。この問題を効果的に回避する唯一の方法として彼が提案するのが、ある安定した状態になるまでコードを「ウォーミングアップ」させることだ。JVMの中には1万回実行するまでメソッドをコンパイルしない(それまではインタプリタ型で実行される)ものもあるので、ウォーミングアップは時間がかかるし簡単なことではない。そのウォーミングアップで一度コードが安定状態になった後で、コードを何度も実行して結果を統計的に分析するベンチマークがおこなわれることになる。 

この問題の説明に加えて、Boyer氏は自分が書いたベンチマークフレームワークを採用することを提案している。その彼のフレームワークを使って、さまざまに要素を格納したいくつかのデータ構造(プリミティブな配列やArrayList、Vector、HashMap、TreeMapなど)へのデータアクセスでの違いが示されている。そのBoyer氏の分析から興味深い2つのことがわかる。

  1. 彼のベンチマークフレームワークでは数ナノ秒しかかからないアクセスについては、その平均時間をレポートすることができる
  2. いくつかのデータ構造では処理の負荷が意外なほど異なる。

ひとつ不思議なのは CncurrentHashMapの振る舞いをTreeMapと比較した結果だ。要素数が1024以内であればConcurrentHashMapは TreeMapよりはるかによいパフォーマンスをあげる。しかし1024x1024の要素ではかろうじて上回る程度だ。木構造での検索はlog(n)の計算量となるのに対してハッシュマップでのオーダーはO(1)にしかならないことからすると、これは予想外のことだ。しかしそういう予想外のことはあるにしても、この記事は読む価値のあるもので、Boyer氏の懸念することはJavaのコードをベンチマーク測定で考慮するに値するものだ。

原文はこちらです:http://www.infoq.com/news/2008/08/java-benchmarking

この記事に星をつける

おすすめ度
スタイル

BT