今日以下の(恥ずかしい)バグの修正の為に @Benchmark annotation for Groovy を更新しました。
- Groovy 1.7 で java.lang.VerifyError が起きる
- JVM 1.5 で java.lang.UnsupportedClassVersionError が起きる
現在 @Benchmark が Groovy 1.7/1.8 と JVM 1.5/1.6 で動作することは確認しています。
@Benchmark は初めてという方は前回のポストを読んでください。
Tuesday, May 31, 2011
Saturday, May 28, 2011
@Benchmark annotation for Groovyをリリース!
@Benchmarkアノテーションはメソッドの実行時間をコードの追加なしで計測できるようにしてくれます。次の例は@Benchmarkの基本的な使用例です:
----
@Benchmark
def method() {
// an operation takes 1 ms
}
method()
----
この場合標準出力に"1000000"が出力されます. @Benchmarkは時間をナノ秒で表します。
出力形式に手を加える為のオプションが2つあります:
----
@Benchmark(prefix = 'execution time of method(): ', suffix = ' ns')
def method() {
// an operation takes 1 ms
}
method()
----
こうすると出力は"execution time of method(): 1000000 ns"となります。
@Benchmarkは出力にthis.println(value)を使います。なので目的に沿ったwriterを"out"プロパティにセットすることで出力をリダイレクトできます:
@Benchmark
def method() {
// an operation takes 1 ms
}
method()
----
この場合標準出力に"1000000"が出力されます. @Benchmarkは時間をナノ秒で表します。
出力形式に手を加える為のオプションが2つあります:
----
@Benchmark(prefix = 'execution time of method(): ', suffix = ' ns')
def method() {
// an operation takes 1 ms
}
method()
----
こうすると出力は"execution time of method(): 1000000 ns"となります。
@Benchmarkは出力にthis.println(value)を使います。なので目的に沿ったwriterを"out"プロパティにセットすることで出力をリダイレクトできます:
----
def results = new StringBuffer()
this.setProperty("out", new StringBufferWriter(results))
// method calls
this.setProperty("out", null)
results.toString().eachLine { result ->
println "${result.asType(int.class) / 1000000} ms"
}
----
ダウンロードはこちらから。
def results = new StringBuffer()
this.setProperty("out", new StringBufferWriter(results))
// method calls
this.setProperty("out", null)
results.toString().eachLine { result ->
println "${result.asType(int.class) / 1000000} ms"
}
----
ダウンロードはこちらから。
Sunday, May 22, 2011
Exploring Groovy 1.8 Part 1 - そのコード、本当に最適化されてますか?
Groovy目下の課題であるパフォーマンス向上の為、1.8では整数演算とメソッド直接呼び出しへの最適化が行われるようになりました。どちらの最適化も考え方は同じで、簡単にいってしまえば"出来る限り書かれた通りにコンパイルする"というものです。これはこれまでGroovyコンパイラが構文を正しく解析してくれなかった、という意味ではありません。Groovyでは柔軟なメタプログラミングを可能にする為にコンパイル時に劇的な変換が施されるのです(このあたりは以前のポスト、インサイドGDKでも触れています)。問題は例外がなかったことです。この後の話の都合上、フィボナッチ数の計算メソッドを例としてあげます:
----
int fib(int n) {
if (n < 2) return n
return fib(n - 1) + fib(n - 2)
}
----
このコードは全くメタプログラミングの恩恵を受ける必要のないコードですが、v1.7以前では次のように変換されます（実際はGroovyのAPIが登場しますし行っていることももう少し複雑なのですが、今回の話では重要ではない為省略します)。全ての演算/メソッド呼び出しはリフレクションへ置き換えられ、整数に対してせわしなくボクシングとアンボクシングが繰り返されます:
----
int fib(int n) {
// Get the Method objects
if (lessThanMethod.invoke(Integer.valueOf(n), Integer.valueOf(2)))
return Integer.valueOf(n).intValue();
return
((Integer) plusMethod.invoke(
fibMethod.invoke(
minusMethod.invoke(Integer.valueOf(n), Integer.valueOf(1)
),
fibMethod.invoke(
minusMethod.invoke(Integer.valueOf(n), Integer.valueOf(2)
)
)).intValue();
);
----
これがv1.8では次のように最適化されます。これが冒頭での言った"出来る限り書かれた通りにコンパイルする"の意味です:
----
int fib(int n) {
if (n < 2) return n;
return fib(n - 1) + fib(n - 2);
}
----
さて、話はこれで終わりません。というのも、どうやらこの最適化の恩恵を受ける条件は我々が想像しているよりずっと厳しいものだということです。リリースノートに書かれている次の注意事項を忠実に守るだけでは充分ではありません:
1. 整数の最適化を求めるのであれば1つの式の中でint型とInteger型を混ぜないこと
2. メソッド呼び出しの最適化を求めるのであれば"this"上で実行でき、引数の型がprimitiveかfinalであること
次の表を見てください。これはフィボナッチ数を求めるメソッドをいくつかの方法で実装し、それらの実行速度をv1.8.0とv1.7.10で比較したものです:
この結果は次の3つのことを示しています:
1. 反復版はパフォーマンスが少し劣化した
2. 再帰版はパフォーマンスが大幅に向上した
3. コーディングスタイルによるパフォーマンスの差が広がった
理由は簡単です。結果が芳しくないものは両方、あるいはいずれかの最適化に失敗しているのです。この表で言えば、先に例にあげた再帰 + if + return版以外は全て何らかの形で最適化に失敗しています。例えば再帰を使った中で最も悪い結果となった再帰 + if + else版はこうです:
(今回計測に使ったコード一覧)
反復 + Groovyスタイル for loop:
----
int fib(int n) {
int a = 0
int b = 1
int c
for (int i in 2..n) {
c = a + b
a = b
b = c
}
b
}
----
反復 + Java/Cスタイル for loop:
----
int fib(int n) {
int a = 0
int b = 1
int c
for (int i = 2; i <= n; i++) {
c = a + b
a = b
b = c
}
b
}
----
再帰 + if + return:
----
再帰 + 三項演算子:
----
int fib(int n) {
n < 2 ? n : fib(n - 1) + fib(n - 2)
}
----
再帰 + if-else:
----
int fib(int n) {
----
int fib(int n) {
if (n < 2) return n
return fib(n - 1) + fib(n - 2)
}
----
このコードは全くメタプログラミングの恩恵を受ける必要のないコードですが、v1.7以前では次のように変換されます（実際はGroovyのAPIが登場しますし行っていることももう少し複雑なのですが、今回の話では重要ではない為省略します)。全ての演算/メソッド呼び出しはリフレクションへ置き換えられ、整数に対してせわしなくボクシングとアンボクシングが繰り返されます:
----
int fib(int n) {
// Get the Method objects
if (lessThanMethod.invoke(Integer.valueOf(n), Integer.valueOf(2)))
return Integer.valueOf(n).intValue();
return
((Integer) plusMethod.invoke(
fibMethod.invoke(
minusMethod.invoke(Integer.valueOf(n), Integer.valueOf(1)
),
fibMethod.invoke(
minusMethod.invoke(Integer.valueOf(n), Integer.valueOf(2)
)
)).intValue();
);
----
これがv1.8では次のように最適化されます。これが冒頭での言った"出来る限り書かれた通りにコンパイルする"の意味です:
----
int fib(int n) {
if (n < 2) return n;
return fib(n - 1) + fib(n - 2);
}
----
さて、話はこれで終わりません。というのも、どうやらこの最適化の恩恵を受ける条件は我々が想像しているよりずっと厳しいものだということです。リリースノートに書かれている次の注意事項を忠実に守るだけでは充分ではありません:
1. 整数の最適化を求めるのであれば1つの式の中でint型とInteger型を混ぜないこと
2. メソッド呼び出しの最適化を求めるのであれば"this"上で実行でき、引数の型がprimitiveかfinalであること
次の表を見てください。これはフィボナッチ数を求めるメソッドをいくつかの方法で実装し、それらの実行速度をv1.8.0とv1.7.10で比較したものです:
フィボナッチ(30)の実行時間(単位はナノ秒) | |||||
ランク | アルゴリズム / スタイル | v1.8 | v1.7 | 改善 | |
1 | 反復 + Groovyスタイル for loop | 49720 | 46276 | -6.93% | Down :-( |
2 | 反復 + Java/Cスタイル for loop | 129360 | 77824 | -39.84% | Down :-( |
3 | 再帰 + if + return | 45080820 | 548522821 | +1116.75% | Up :-) |
4 | 再帰+ 三項演算子 | 120489259 | 538476119 | +346.91% | Up :-) |
5 | 再帰 + if-else | 259945537 | 546381516 | +110.19% | Up :-) |
この結果は次の3つのことを示しています:
1. 反復版はパフォーマンスが少し劣化した
2. 再帰版はパフォーマンスが大幅に向上した
3. コーディングスタイルによるパフォーマンスの差が広がった
理由は簡単です。結果が芳しくないものは両方、あるいはいずれかの最適化に失敗しているのです。この表で言えば、先に例にあげた再帰 + if + return版以外は全て何らかの形で最適化に失敗しています。例えば再帰を使った中で最も悪い結果となった再帰 + if + else版はこうです:
----
int fib(int n) {
if (n < 2) n
else fib(n - 1) + fib(n - 2)
}
----
これは次のように変換されます(繰り返しになりますが正確には実際のものとは違います):
----
int fib(int n) {
if (n < 2) return n;
else return
((Integer) plusMethod.invoke(
fibMethod.invoke(Integer.valueOf(n - 1)),
fibMethod.invoke(Integer.valueOf(n - 2))
)).intValue();
);
}
----
たったこれだけのスタイルの違いが最適化が成功するかを左右し、パフォーマンスに5倍の差を作るのです。こういった問題はこれから改善されていくでしょうが、少なくとも現時点では諸手を上げて喜べる段階ではないようです。
さてさて、そのコード、本当に最適化されてますか?
さてさて、そのコード、本当に最適化されてますか?
(今回計測に使ったコード一覧)
反復 + Groovyスタイル for loop:
----
int fib(int n) {
int a = 0
int b = 1
int c
for (int i in 2..n) {
c = a + b
a = b
b = c
}
b
}
----
反復 + Java/Cスタイル for loop:
----
int fib(int n) {
int a = 0
int b = 1
int c
for (int i = 2; i <= n; i++) {
c = a + b
a = b
b = c
}
b
}
----
再帰 + if + return:
----
int fib(int n) {
if (n < 2) return n
return fib(n - 1) + fib(n - 2)
}
----再帰 + 三項演算子:
----
int fib(int n) {
n < 2 ? n : fib(n - 1) + fib(n - 2)
}
----
再帰 + if-else:
----
int fib(int n) {
if (n < 2) n
else fib(n - 1) + fib(n - 2)
}
----Wednesday, May 4, 2011
Gjが更新されました!
更新内容は以下です:
1. Groovyをバンドルするオプション
-bg/--bundlegroovy オプションが追加されました。Groovyのライブラリを直接指定する代わりにこのオプションを使うことができます。
----
> cat src\PrintHello.groovy
println 'hello'
> groovy Gj.groovy -bg -s src -m PrintHello printhello.jar
> java -jar printhello.jar
hello
----
2. javac用のデフォルトのjavaバージョン
javac用のデフォルトのjavaバージョンがシステムと同じバージョンになるよう変更されています。
3. Gjのバージョンを出力するオプション
-ver/--version オプションが追加されました。このオプションを使ってGjのバージョンを確認することができます。
----
> groovy Gj.groovy -ver
Gj version: 11.05.05
----
新しいバージョンはこちらからダウンロードできます。使ってみてください ;-)
Monday, May 2, 2011
Poison for Groovy
昨夜、Gjスクリプトのテスト中にgroovy.batのバグにぶち当たりました (Gjスクリプトは実行可能なjarファイルを簡単に作るために僕が書いたものです。詳しくは以前のポストを見てください)。groovy.batが * (アスタリスク)を含んだコマンドライン引数を扱えないのです。
例えば、次のコマンドを入力するとgroovy.batは応答しなくなります。
----
groovy Foo.groovy "*"
----
あるいは
----
groovy -e "println '*'"
----
GroovyMainに直接渡した時は動作します。
----
java -cp "%GROOVY_HOME%\embeddable\groovy-all-1.8.0.jar" groovy.ui.GroovyMain -e "println '*'"
*
----
既知バグかどうか探したら、GROOVY-3043を見つけました。幸運なことにこのバグは2年前に修正されていました。よしよし、そういうことなら... って修正済み? いやちょっと、まだバグってますよ。
奇妙なことに修正済みの (不確か、とりあえず動いてるように見える) startGroovy.bat (groovy.batから呼ばれ、コマンドライン引数をパースする)はGROOVY-3043に添付されています。なぜこれがいまだに提供されていないのかはわかりません。
このバグをGROOVY-4805に新しい問題として報告しました。僕が書いたパッチも提供したのでWindows NT系のユーザの方はそれを当てるのもよいと思います。いずれにせよ、できるだけ早くこのバグが修正されることを望みます。
Subscribe to:
Posts (Atom)