java - PyStone でテストすると、Jython の動作に一貫性がないのはなぜですか?

Question

私は最近 Jython で遊んでいましたが、pystone を使って簡単で汚いベンチマークを行うことにしました。リファレンスを得るために、最初にループ数を増やして cPython 2.6 をテストしました (Jython はしばらくしてから JIT から利益を得るようになるはずなので、これは適切であると考えました)。

(richard garibaldi):/usr/local/src/pybench% python ~/tmp/pystone.py 
Pystone(1.1) time for 50000 passes = 1.04
This machine benchmarks at 48076.9 pystones/second

(richard garibaldi):/usr/local/src/pybench% python ~/tmp/pystone.py 500000 
Pystone(1.1) time for 500000 passes = 10.33
This machine benchmarks at 48402.7 pystones/second

(richard garibaldi):/usr/local/src/pybench% python ~/tmp/pystone.py 1000000 
Pystone(1.1) time for 1000000 passes = 19.6
This machine benchmarks at 51020.4 pystones/second

ご覧のとおり、cPython は一貫して動作します。テストを完了するのにかかる時間は、ループの数に比例して増加します。これを知って、Jython のテストを開始しました。

(richard garibaldi):/usr/local/src/pybench% jython ~/tmp/pystone.py 
Pystone(1.1) time for 50000 passes = 2.29807
This machine benchmarks at 21757.4 pystones/second

(richard garibaldi):/usr/local/src/pybench% jython ~/tmp/pystone.py 500000 
Pystone(1.1) time for 500000 passes = 10.931
This machine benchmarks at 45741.4 pystones/second


(richard garibaldi):/usr/local/src/pybench% jython ~/tmp/pystone.py 1000000
Pystone(1.1) time for 1000000 passes = 107.183
This machine benchmarks at 9329.86 pystones/second

最初の実行中、Jython は C の兄弟に比べてかなりお粗末に実行されます。ループの数を増やすと、私の最初の仮説が予測したように、cPython に近づき、気分が良くなり始めました。ループの数は 10 倍に増えましたが、Jython がそれらを完了するのに約 5 倍の時間しかかからなかったことに注意してください。ですから、ご想像のとおり、Jython が最終テストで本当にうまくいくことを期待していました。しかし、非常に残念なことに、最初の実行よりも 2 倍以上遅くなりました。

あなたの仮説は何ですか: Jython がこれほど一貫性のない動作をするのはなぜですか? ある時点で GC が開始され、多くの時間がかかっている可能性がありますか? PyStone のコードを調べたところ、ガベージ コレクションがオフになっていないように見えますが、Java の GC は少なくとも Python と同じくらい優れていると思います...この速度低下は永続的だと思いますか、それともなくなると思いますか?ループ数を増やした後のある時点で？Jython は、非常に長時間実行されるプロセスでどのように動作しますか?

EDIT：残念ながら、java.lang.OutOfMemoryErrorループ数を200万に増やすと...

(もちろん、Jython はまだベータ版なので、最終リリースでは改善されるはずです。)

Jython 2.5b1 (トランク:5903:5905、2009 年 1 月 9 日、16:01:29)、Java(TM) SE ランタイム環境 (ビルド 1.6.0_07-b06-153)、および Java HotSpot(TM) 64 ビットを使用しています。 MacOS X 10.5 上のサーバー VM (ビルド 1.6.0_07-b06-57、混合モード)。

回答ありがとうございます。

Answer 1

JVM と同じくらい複雑なランタイム環境のベンチマークは困難です。JIT と GC を除外しても、実行ごとに大きなヒープ、メモリ レイアウト、およびキャッシュの変動があります。

Jython で役立つことの 1 つは、単一の VM セッションで単純にベンチマークを複数回実行することです。1 回は JIT をウォームアップし、1 回以上は個別に測定します。私は多くの Jython ベンチマークを行ってきましたが、残念ながら、妥当な時間を達成するには 10 ～ 50 回の試行が必要になることがよくあります。

いくつかの JVM フラグを使用して GC と JIT の動作を観察し、ウォームアップ期間の長さをある程度把握できますが、明らかにデバッグ フラグをオンにしてベンチマークを行うべきではありません。例えば：

% ./jython -J-XX:+PrintCompilation -J-verbose:gc
  1       java.lang.String::hashCode (60 bytes)
  2       java.lang.String::charAt (33 bytes)
  3       java.lang.String::lastIndexOf (156 bytes)
  4       java.lang.String::indexOf (151 bytes)
[GC 1984K->286K(7616K), 0.0031513 secs]

これらすべてを実行し、HotSpot Server VM を使用すると、Jython が pystone 上の CPython よりもわずかに高速であることがわかりますが、これは一般的な Jython のパフォーマンスを表すものではありません。Jython 開発者は、2.5 リリースのパフォーマンスよりも正確性に注意を払っています。2.6/2.7/3.0 のリリースに伴い、今後 1 年程度でパフォーマンスがより重視されるようになります。私が実行したいくつかのマイクロベンチマーク(元々は PyPy から派生したもの) を見ると、いくつかの問題点がわかります。

Answer 2

JRE 1.6.0_12-b04 を使用して Ubuntu Jaunty を実行しているラップトップでも同じ結果が得られます。

nathell@breeze:/usr/lib/python2.5/test$ python pystone.py 500000
500000 パスの Pystone(1.1) 時間 = 12.98
このマシンのベンチマークは 38520.8 pystones/秒です

nathell@breeze:/usr/lib/python2.5/test$ python pystone.py 1000000
1000000 パスの Pystone(1.1) 時間 = 26.05
このマシンのベンチマークは 38387.7 pystones/秒です

nathell@breeze:/usr/lib/python2.5/test$ ~/jython/jython pystone.py
50000 パスの Pystone(1.1) 時間 = 2.47788
このマシンのベンチマークは 20178.6 pystones/秒です

nathell@breeze:/usr/lib/python2.5/test$ ~/jython/jython pystone.py 500000
500000 パスの Pystone(1.1) 時間 = 19.7294
このマシンのベンチマークは 25342.9 pystones/秒です

nathell@breeze:/usr/lib/python2.5/test$ ~/jython/jython pystone.py 1000000
1000000 パスの Pystone(1.1) 時間 = 38.9272
このマシンのベンチマークは 25689 pystones/秒です

結局のところ、これは Jython バージョンではなく JRE に関連している可能性があります。Armed Bear Common Lisp プロジェクトが JRE 1.6 の初期バージョンで抱えていた問題も、これを示唆している可能性があります。

Answer 3

XP_Win32_PC の私のベンチ:

C:\jython\jython2.5b1>bench "50000"

C:\jython\jython2.5b1>jython Lib\test\pystone.py "50000"
Pystone(1.1) time for 50000 passes = 1.73489
This machine benchmarks at 28820.2 pystones/second

C:\jython\jython2.5b1>bench "100000"

C:\jython\jython2.5b1>jython Lib\test\pystone.py "100000"
Pystone(1.1) time for 100000 passes = 3.36223
This machine benchmarks at 29742.2 pystones/second

C:\jython\jython2.5b1>bench "500000"

C:\jython\jython2.5b1>jython Lib\test\pystone.py "500000"
Pystone(1.1) time for 500000 passes = 15.8116
This machine benchmarks at 31622.3 pystones/second

C:\jython\jython2.5b1>bench "1000000"

C:\jython\jython2.5b1>jython Lib\test\pystone.py "1000000"
Pystone(1.1) time for 1000000 passes = 30.9763
This machine benchmarks at 32282.8 pystones/second

C:\jython\jython2.5b1>jython
Jython 2.5b1 (trunk:5903:5905, Jan 9 2009, 16:01:29)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.5.0_17

そんなに速くはないですが...

「特殊効果」なし

それは java-vm '問題' ですか?

この古い Win32-PC での私のベンチマークにさらに情報が必要な場合は、コメントを追加してください

Answer 4

JVM 構成を微調整することで結果を改善できると確信しており (JRuby はそれを行うためにかなりの数の興味深いフラグを使用しています)、ガベージ コレクションを調整できることも確信しています。このベンチマークに非常に興味がある場合は、VM を構成するための優れたリソースであるTuning Garbage Collectionを参照してください。JRuby の設定も見てみたいと思います。

./アレックス