プログラムの長さも考慮した言語ベンチマーク 22
ストーリー by hylom
OCamlの結果が興味深い 部門より
OCamlの結果が興味深い 部門より
あるAnonymous Coward 曰く、
Radium Softwareの記事で知ったのだが、The Computer Language Benchmarks Gameにて、プログラムの長さと処理のパフォーマンスを関連付けたベンチマークグラフが公開されている。
具体的なプロットはベンチマークページの上部の "interpret scatter plot shapes" をクリックすると確認できるが、このような試みは珍しいんじゃないだろうか。
おおむねよく言われている印象を裏付ける結果が出ていると思うが、似た傾向の言語同士の比較も面白いかもしれない。あなたのお気に入りの言語はありましたか？
一覧ページではCやC++は速いが複雑、RubyやPython、Perlは簡潔だが速くない、という結果が確認できる。また、OCamlがそこそこ速く、そこそこ簡潔という結果を示している点も興味深い。
これはちょっと如何なものか (スコア:3, 興味深い)
(並列)binary-trees
二分木をもりもり作る。メモリアロケーションが主。
CのみOMPで並列化。
(並列)chameneous-redux
プレイヤー二人が交互に手を打つゲーム。ゲームの中身は非常に軽い。
Cのみスレッドを二つフォークしている。(同期はcompare and swap)
(並列)fannkuch
http://www.haskell.org/haskellwiki/Shootout/Fannkuch
メモリアクセスが多い。
問題サイズ(C)またはプロセッサ台数(Java)だけのスレッドを作成している。
(逐次)fasta
与えられた塩基の配列を繰り返す、塩基の存在確率に応じて配列を生成する、の二つの関数。
最内ループで乱数ルーチンを呼んでいるが、C版は自前の合同乗算法のルーチンを用意している。
k-nucleotide
(並列)mandelbrot
マンデルブロ集合の計算。浮動小数点演算とビット演算がほとんど。
Cではスレッド数は8に固定、Javaではプロセッサ台数だけ用意する。
(これはベンチマークではありません)meteor-contest
パズル。
整数とメモリアクセス。
(逐次)n-body
N体問題。浮動小数点が主。
C版はx86のSSEを直接使っている。
(逐次)pidigits
円周率の計算。
任意精度演算ライブラリを使用。
(逐次)regex-dna
塩基配列の置換。
CもJavaも正規表現ライブラリを呼んでいるだけ。
(逐次)reverse-complement
塩基配列の逆相補配列。メモリアクセスが主。
配列を前後ひっくり返しつつ、各塩基を相補的なものに置き換える。
(並列)spectral-norm
数値演算。
C版はSSEを直接使用。OMPで並列化。
Java版はプロセッサ台数分のスレッドを用意する。
thread-ring
各スレッドは、起きたら隣のスレッドを起こして終了するだけ。
Re: (スコア:0)
Re:これはちょっと如何なものか (スコア:2, 興味深い)
>N体問題。浮動小数点が主。
>C版はx86のSSEを直接使っている。
C版はSSEを使ったもの(C GNU gcc #5, 20.74sec)
よりもSSEを使っていないもの(C GNU gcc, 20.37sec)
の方が速いという不可解な結果ですね．
言語仕様や処理系の能力の差がベンチマークの順位に表れているというのはちょっと危険だと思います．
結局はソースを書いた人のコーディング能力の差が表れているに過ぎないと思います．
如何でしょう？
Re: (スコア:0)
> よりもSSEを使っていないもの(C GNU gcc, 20.37sec)
> の方が速いという不可解な結果ですね．
gccはx87 FPUは使わず、浮動小数点演算はSSEコードを吐きますから、そんなものかも。
カリカリチューン (スコア:1)
血のにじむ思いで1Byteを削ったアセンブラプログラムはどんな評価になるんでしょうね？
Re: (スコア:0)
混ぜるな危険 (スコア:1, フレームのもと)
Re: (スコア:0)
リンク先は見たの？
言語を代表する処理系(言語によっては事実上由一の処理系)が揃ってるわけで
形式的な反論に何の意味があるのでしょうか
あ、笑う所ですか？
Re:混ぜるな危険 (スコア:1, フレームのもと)
Re: (スコア:0)
はい、リンク先ちゃんと見てないこと確定。
Ruby：Ruby1.8, 1.9, JRuby
Python：Python 2, 3
Javascript：TraceMonkey, V8
Lua：Lua, LuaJIT
処理系の比較もおりまぜてますよ？
速度やメモリ効率の比較を処理系間だけでしか比較しちゃいけないなんて、つまらないじゃない。
言語の優劣に興味があるんだから。
Re:混ぜるな危険 (スコア:1)
Re: (スコア:0)
見落としていましたァッーーー！
だけ見ていましたァッーーー！
そんなことではいつまでたっても講師になれないよ
FORTHやAPLの結果も見たかった、みたいな (スコア:0)
ものさしはものさし (スコア:0)
道具ってのは無いと始まらん。できれば競争・淘汰が起こるほどであればなお良し。
#HDD系のベンチマークはそんな感じだけどね。
OCamlいいよ (スコア:0)
うちではずっと業務に使ってるけど、速度が問題になったことはないし、みんなももっと使うといいと思うよ。
Re: (スコア:0)
Re:OCamlいいよ (スコア:1)
Re:OCamlいいよ (スコア:1, 興味深い)
http://caml.inria.fr/cgi-bin/hump.cgi
うちの会社ではWeb系のシステムは全部OCamlでやってるけど、フレームワークやライブラリを自前で用意したことは無いよ。
Re:OCamlいいよ (スコア:1)
初学者なので詳細はわかりませんが、WebアプリケーションフレームワークならばOcsigen [ocsigen.org]とかどうでしょう。
ソースサイズじうよう (スコア:0)
ライブラリにやらせられる部分はやらせて自分で書くものは最低限にってのはホント助かりますね。
この場合問題は速度との相関で
- ライブラリはネイティブコードにコンパイルされてるから(特にLLでは)速くなる
- ライブラリが汎用過ぎて余計な部分も読み込むから遅くなる
どっちに転ぶかなので、これは参考になります。
# でも真に扱う言語を決めるのは「その言語を使う仕事がどれだけあるのか」かもしれない
勘違いしてた (スコア:0)
手作業で展開してどこまで展開したら、余りメモリとバランスするかなんて…遠い昔だ
Re: (スコア:0)
今時のプロセッサは下手にループ展開すると遅くなりますけどね。