Concurrent Clean : String2 : 速度調査

適当なテストプログラムを書いて、速度調査してみた。
結果は次の通り。
組み込み文字列

$ ./bench_string 10000
"tabcdeabcdeqwertabcdeabcdertabcdeabcdeqwertabcdeabcdedeqwertabcdeabcdeqwertabcdeabcdeqwertabcdeabcdetabcdeabcdeqwertabcdeabcdertabcdeab"
Execution: 0.13  Garbage collection: 0.01  Total: 0.14

String2

$ ./bench_string2 10000
"tabcdeabcdeqwertabcdeabcdertabcdeabcdeqwertabcdeabcdedeqwertabcdeabcdeqwertabcdeabcdeqwertabcdeabcdetabcdertabcdeabcdeqwertabcdeabcdeqw"
Execution: 0.66  Garbage collection: 0.20  Total: 0.86

おそらく、メモリ領域の再利用を行いやすいプログラムだったため、単純な配列でも効率がよかったのではないかと推測する。長大文字列のコピーが多発するようなケースでは逆転すると思う。
このテストプログラムの妥当性がどの程度のものかもよくわからない。

以下、テストプログラム

続きを読む

Concurrent Clean : Finger trees : String2

テストプログラムを書いてベンチマークを取ってみているのだけれど、組み込みの方が速い。それどころか、String2の方には見えてはいけない文字列が表示されているような気が・・・

組み込みの方が速いのは、メモリの再利用をしやすいプログラムになっているからで、そうでなくすれば違いが出てくると思うのだけれど、どうかけばよいものか？

      • -

どう見てもバッファーオーバーフローだなー。
シンプルな再現プログラムが書けないかな。

      • -

書けた。
Windows版だと、デフォルトでインデックスチェックが有効になっているけれど、Linux版だと -ci オプションを付けなければ有効にならない。
加えて、-ci オプションを付けた上で、モジュールをリコンパイルしなければ、そのモジュールについてインデックスチェックが有効にならないが、-ci オプションを付けても自動的にはモジュールはリコンパイルされないので、一度コンパイルされたモジュールは、インデックスチェックが無効のままである。
まあ、そんなわけで、String2のバグを１つ発見した。

Concurrent Clean : Finger trees : 65536

65536個を越える要素を追加すると、measure関数が返ってこなくなる。

      • -

Cleanのバグ臭い。

module Test5

import StdBase, Test5Add

Start = foldl add 0 (take 65536 (repeat 1))

implementation module Test5Add

import StdInt

add :: Int Int -> Int
add a b = a + b

というプログラムを作ると、65536ならば結果はすぐに返ってくるが、65537だと結果が全然返ってこない。

      • -

とりあえず、問い合わせておいた。