Elvisは何人いる?:
[]?.size?:[].@size?:[]*.size?:[].&size?':[].size?':[]
Sunday, July 3, 2011
Saturday, July 2, 2011
Poison for Groovy Part 2
生成には3つの工程があります:
1. GroovyがインストールされているWindowsマシンを手に入れます。これは大変難しいミッションです。
2. ダブルクォートされ、スペースを含んだ文字列をJAVA_OPTS環境変数へセットします:
----
> set JAVA_OPTS=-Daprop="a value"
----
3. groovyを実行します:
----
> groovy -h
----
すると次のエラーが起こります:
----
value"" was unexpected at this time.
----
既にこのバグに関連する2つの問題を報告しパッチも提供しています (GROOVY-4910とGANT-126を参照)。これらの問題がすぐに解決することを望みます、Windows固有の問題はパッチがあってもいつも未解決のままですけどね。
Groovyは仮想マシン上で動くクロスプラットフォーム言語、でしょ?
Saturday, June 25, 2011
GBench = @Benchmark Annotation + BenchmarkBuilder
Groovy 用のベンチマーク・フレームワーク、 GBench をリリースしました。GBench は2つの機能、 @Benchmark Annotation と BenchmarkBuilder を持っています。 @Benchmark Annotation はプロダクトのコードをいじらずに実行時間を計測することを可能にするアノテーションで、既に公開されています。より詳しい情報については以前のポストを読んでください。 BenchmarkBuilder はベンチマーク・コードを簡単に書くための便利なビルダで、今回初めて登場します。
次のコードは文字列連結を1000回繰り返してベンチマークを採るものです:
----
def strings = ['GBench', ' = ', '@Benchmark Annotation', ' + ', 'BenchmarkBuilder']
def benchmark = new BenchmarkBuilder()
benchmark.run times: 1000, {
with '+=', {
def s = ''
for (string in strings) {
s += string
}
}
with 'concat', {
def s = ''
for (string in strings) {
s.concat string
}
}
with 'string builder', {
def sb = new StringBuilder()
for (string in strings) {
sb << string
}
sb.toString()
}
with 'join', {
strings.join()
}
}
println benchmark
----
出力はこのようになります:
----
time
+= 18197705
concat 7669621
string builder 9420539
join 5248348
----
もちろん結果はソートできます:
----
println benchmark.sort({ lhs, rhs -> lhs.time <=> rhs.time })
----
----
time
join 5248348
concat 7669621
string builder 9420539
+= 18197705
----
結果を好きなように処理することもできます:
----
new File('benchmark.csv').withWriter { file ->
file.writeLine 'label,time(ms)'
benchmark.sort().each { bm ->
file.writeLine "${bm.label},${bm.time / 1000000}"
}
}
----
----
> cat benchmark.csv
label,time(ms)
join,5.248348
concat,7.669621
string builder,9.420539
+=,18.197705
----
いまのところ、GBench は wall-clock time しか計測できませんが、将来のリリースでは CPU time や user time もサポートする予定です。
GBench はこちらからダウンロードできます。ぜひ試してフィードバックしてください!
Saturday, June 11, 2011
@Benchmark annotation for Groovy が大幅に更新!
@Benchmark annotation for Groovy v11.06.11 をリリースしました。このリリースはいくつかの大きな変更と大きなバグの修正を含んでいます。
- 変更
- ベンチマーク結果へのクラス/メソッド情報の追加
- ベンチマーク結果処理をカスタマイズする新オプション
- クラスアノテーションのサポート
- バグ修正
- クラス内のメソッドで動かない問題を修正
ベンチマーク結果へのクラス/メソッド情報の追加
ベンチマーク結果として、ベンチマークされたメソッドとそのクラス上方を取得できます。例えば次のコードでは、
----
package foo
class Foo {
@Benchmark
def foo() {
}
}
----
出力はこうなります:
----
foo.Foo java.lang.Object foo(): xxx ns
----
ベンチマーク結果処理をカスタマイズする新オプション
貧弱なオプション、"prefix" と "suffix" の代わりに ベンチマーク結果の処理をカスタマイズする "value" オプションが追加されました。値の設定方法は3つあります:
- ハンドラクラスを使う
- クロージャを使う
- システムプロパティを使う
ハンドラクラスを使う場合、Benchmark.BenchmarkHandler インターフェイスを実装したクラスを作り2つのメソッド、 handle() と getInstance() をそれらへ追加します:
----
class MyHandler implements Benchmark.BenchmarkHandler {
static def instance = new MyHandler()
static MyHandler getInstance() {
instance
}
void handle(klass, method, time) {
println("${method} of ${klass}: ${(time/1000000) as long} ms")
}
}
----
そうですね、上の例のようなシングルトンクラスは @Singleton アノテーションを使えば短く書けます :-)
----
@Singleton
class MyHandler implements Benchmark.BenchmarkHandler {
void handle(klass, method, time) {
println("${method} of ${klass}: ${(time/1000000) as long} ms")
}
}
----
最後にハンドラクラスを @Benchmark に設定します:
----
@Benchmark(MyHandler.class)
def foo() {
}
----
Groovy 1.8 からはハンドラクラスの代わりにクロージャも使えます。クロージャであれば、ベンチマーク結果を処理するクロージャを設定するだけです:
----
@Benchmark({println("${method} of ${klass}: ${(time/1000000) as long} ms")})
def foo() {
}
----
またシステムプロパティ、 "groovybenchmark.sf.net.defaulthandle" でデフォルトの処理を置き換えられます:
----
> groovy -cp groovybenchmark-11.06.11.jar
-Dgroovybenchmark.sf.net.defaulthandle="println(method + ' of ' + klass + ': ' + ((time/1000000) as long) + ' ms')" foo\Foo.groovy
----
これらの例の場合、出力はこうなります:
----
java.lang.Object foo() of foo.Foo: xxx ms
----
クラスアノテーションのサポート
クラスにアノテートすることで、そのクラスの全てのメソッドのベンチマーク結果を取得できます:
----
package foo
@Benchmark
class Foo {
def foo() {
}
def bar() {
}
}
----
この例の場合、 foo() と bar() メソッドのベンチマーク結果を取得できます:
----
foo.Foo java.lang.Object foo(): xxxx ns
foo.Foo java.lang.Object bar(): xxxx ns
----
そしてこれはつまり、あなたがコードの変更やプロファイリングツールなしにプログラムの全てのメソッドをベンチマークできる力を手に入れたことを意味します。なぜなら Groovy 1.8 は全てのクラスにアノテーションを適用する compilation customizer を提供しているからです:
----
// BenchmarkGroovyc.groovy
import groovybenchmark.sf.net.Benchmark
import org.codehaus.groovy.control.CompilerConfiguration
import org.codehaus.groovy.control.customizers.ASTTransformationCustomizer
import org.codehaus.groovy.tools.FileSystemCompiler
def cc = new CompilerConfiguration()
cc.addCompilationCustomizers(new ASTTransformationCustomizer(Benchmark))
new FileSystemCompiler(cc).commandLineCompile(args)
----
----
> groovy -cp groovybenchmark-11.06.11.jar BenchmarkGroovyc.groovy MyApp.groovy
> java -cp .;%GROOVY_HOME%\embeddable\groovy-all-1.8.0.jar;groovybenchmark-11.06.11.jar MyApp
----
----
Xxx xxxx foo(): xxx ns
Xxx xxxx bar(): xxx ns
Xxx xxxx baz(): xxx ns
MyApp java.lang.Object main(java.lang.Object): xxx ns
----
ぜひ試してフィードバックしてください!
- 変更
- ベンチマーク結果へのクラス/メソッド情報の追加
- ベンチマーク結果処理をカスタマイズする新オプション
- クラスアノテーションのサポート
- バグ修正
- クラス内のメソッドで動かない問題を修正
ベンチマーク結果へのクラス/メソッド情報の追加
ベンチマーク結果として、ベンチマークされたメソッドとそのクラス上方を取得できます。例えば次のコードでは、
----
package foo
class Foo {
@Benchmark
def foo() {
}
}
----
出力はこうなります:
----
foo.Foo java.lang.Object foo(): xxx ns
----
ベンチマーク結果処理をカスタマイズする新オプション
貧弱なオプション、"prefix" と "suffix" の代わりに ベンチマーク結果の処理をカスタマイズする "value" オプションが追加されました。値の設定方法は3つあります:
- ハンドラクラスを使う
- クロージャを使う
- システムプロパティを使う
ハンドラクラスを使う場合、Benchmark.BenchmarkHandler インターフェイスを実装したクラスを作り2つのメソッド、 handle() と getInstance() をそれらへ追加します:
----
class MyHandler implements Benchmark.BenchmarkHandler {
static def instance = new MyHandler()
static MyHandler getInstance() {
instance
}
void handle(klass, method, time) {
println("${method} of ${klass}: ${(time/1000000) as long} ms")
}
}
----
そうですね、上の例のようなシングルトンクラスは @Singleton アノテーションを使えば短く書けます :-)
----
@Singleton
class MyHandler implements Benchmark.BenchmarkHandler {
void handle(klass, method, time) {
println("${method} of ${klass}: ${(time/1000000) as long} ms")
}
}
----
最後にハンドラクラスを @Benchmark に設定します:
----
@Benchmark(MyHandler.class)
def foo() {
}
----
Groovy 1.8 からはハンドラクラスの代わりにクロージャも使えます。クロージャであれば、ベンチマーク結果を処理するクロージャを設定するだけです:
----
@Benchmark({println("${method} of ${klass}: ${(time/1000000) as long} ms")})
def foo() {
}
----
またシステムプロパティ、 "groovybenchmark.sf.net.defaulthandle" でデフォルトの処理を置き換えられます:
----
> groovy -cp groovybenchmark-11.06.11.jar
-Dgroovybenchmark.sf.net.defaulthandle="println(method + ' of ' + klass + ': ' + ((time/1000000) as long) + ' ms')" foo\Foo.groovy
----
これらの例の場合、出力はこうなります:
----
java.lang.Object foo() of foo.Foo: xxx ms
----
クラスアノテーションのサポート
クラスにアノテートすることで、そのクラスの全てのメソッドのベンチマーク結果を取得できます:
----
package foo
@Benchmark
class Foo {
def foo() {
}
def bar() {
}
}
----
この例の場合、 foo() と bar() メソッドのベンチマーク結果を取得できます:
----
foo.Foo java.lang.Object foo(): xxxx ns
foo.Foo java.lang.Object bar(): xxxx ns
----
そしてこれはつまり、あなたがコードの変更やプロファイリングツールなしにプログラムの全てのメソッドをベンチマークできる力を手に入れたことを意味します。なぜなら Groovy 1.8 は全てのクラスにアノテーションを適用する compilation customizer を提供しているからです:
----
// BenchmarkGroovyc.groovy
import groovybenchmark.sf.net.Benchmark
import org.codehaus.groovy.control.CompilerConfiguration
import org.codehaus.groovy.control.customizers.ASTTransformationCustomizer
import org.codehaus.groovy.tools.FileSystemCompiler
def cc = new CompilerConfiguration()
cc.addCompilationCustomizers(new ASTTransformationCustomizer(Benchmark))
new FileSystemCompiler(cc).commandLineCompile(args)
----
----
> groovy -cp groovybenchmark-11.06.11.jar BenchmarkGroovyc.groovy MyApp.groovy
> java -cp .;%GROOVY_HOME%\embeddable\groovy-all-1.8.0.jar;groovybenchmark-11.06.11.jar MyApp
----
----
Xxx xxxx foo(): xxx ns
Xxx xxxx bar(): xxx ns
Xxx xxxx baz(): xxx ns
MyApp java.lang.Object main(java.lang.Object): xxx ns
----
ぜひ試してフィードバックしてください!
Tuesday, May 31, 2011
@Benchmark annotation for Groovy がバグ修正の為に更新されています
今日以下の(恥ずかしい)バグの修正の為に @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 は初めてという方は前回のポストを読んでください。
- Groovy 1.7 で java.lang.VerifyError が起きる
- JVM 1.5 で java.lang.UnsupportedClassVersionError が起きる
現在 @Benchmark が Groovy 1.7/1.8 と JVM 1.5/1.6 で動作することは確認しています。
@Benchmark は初めてという方は前回のポストを読んでください。
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)
}
----
Subscribe to:
Posts (Atom)