パスワードを忘れた? アカウント作成
150461 story
プログラミング

プログラムの長さも考慮した言語ベンチマーク 22

ストーリー by hylom
OCamlの結果が興味深い 部門より

あるAnonymous Coward 曰く、

Radium Softwareの記事で知ったのだが、The Computer Language Benchmarks Gameにて、プログラムの長さと処理のパフォーマンスを関連付けたベンチマークグラフが公開されている。

具体的なプロットはベンチマークページの上部の "interpret scatter plot shapes" をクリックすると確認できるが、このような試みは珍しいんじゃないだろうか。

おおむねよく言われている印象を裏付ける結果が出ていると思うが、似た傾向の言語同士の比較も面白いかもしれない。あなたのお気に入りの言語はありましたか?

一覧ページではCやC++は速いが複雑、RubyやPython、Perlは簡潔だが速くない、という結果が確認できる。また、OCamlがそこそこ速く、そこそこ簡潔という結果を示している点も興味深い。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2009年10月07日 17時34分 (#1650263)
    CとJavaのソースだけ見ています。

    (並列)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
    各スレッドは、起きたら隣のスレッドを起こして終了するだけ。
    • by Anonymous Coward
      自分がどの言語が得意かを知るには使えそうですね。
      • by Anonymous Coward on 2009年10月08日 4時17分 (#1650587)
        >(逐次)n-body
        >N体問題。浮動小数点が主。
        >C版はx86のSSEを直接使っている。

        C版はSSEを使ったもの(C GNU gcc #5, 20.74sec)
        よりもSSEを使っていないもの(C GNU gcc, 20.37sec)
        の方が速いという不可解な結果ですね.

        言語仕様や処理系の能力の差がベンチマークの順位に表れているというのはちょっと危険だと思います.
        結局はソースを書いた人のコーディング能力の差が表れているに過ぎないと思います.
        如何でしょう?
        親コメント
        • by Anonymous Coward
          > C版はSSEを使ったもの(C GNU gcc #5, 20.74sec)
          > よりもSSEを使っていないもの(C GNU gcc, 20.37sec)
          > の方が速いという不可解な結果ですね.

          gccはx87 FPUは使わず、浮動小数点演算はSSEコードを吐きますから、そんなものかも。
  • by kikki (30639) on 2009年10月07日 15時35分 (#1650159)
    自己書き換え他、今は禁じ手のあんなことやこんなことをして、
    血のにじむ思いで1Byteを削ったアセンブラプログラムはどんな評価になるんでしょうね?
  • 混ぜるな危険 (スコア:1, フレームのもと)

    by wd-nara (25864) on 2009年10月07日 17時07分 (#1650237) 日記
    プログラムの長さとか構造の複雑さは言語対抗でやるものですが、速さとかメモリ使用量とかは処理系対抗でやるものです。本来混ぜられないものを混ぜているのは、笑うところですか?
    • by Anonymous Coward

      リンク先は見たの?
      言語を代表する処理系(言語によっては事実上由一の処理系)が揃ってるわけで
      形式的な反論に何の意味があるのでしょうか

      あ、笑う所ですか?

      • Re:混ぜるな危険 (スコア:1, フレームのもと)

        by wd-nara (25864) on 2009年10月07日 18時46分 (#1650308) 日記
        もちろん、リンク先を見た上で言っています。言語ごとに代表する処理系を一つだけ選ぶこと自体が、笑うところです。
        親コメント
        • by Anonymous Coward
          >言語ごとに代表する処理系を一つだけ選ぶこと自体
          はい、リンク先ちゃんと見てないこと確定。
          Ruby:Ruby1.8, 1.9, JRuby
          Python:Python 2, 3
          Javascript:TraceMonkey, V8
          Lua:Lua, LuaJIT
          処理系の比較もおりまぜてますよ?
          速度やメモリ効率の比較を処理系間だけでしか比較しちゃいけないなんて、つまらないじゃない。
          言語の優劣に興味があるんだから。
          • by wd-nara (25864) on 2009年10月07日 20時38分 (#1650377) 日記
            あ、ごめんなさい。Ruby のところを見落としていました。CもC++もGCCだけってところだけ見ていました。
            親コメント
            • by Anonymous Coward

              見落としていましたァッーーー!
              だけ見ていましたァッーーー!
              そんなことではいつまでたっても講師になれないよ

  • by Anonymous Coward on 2009年10月07日 14時58分 (#1650140)
    (T/O)
  • by Anonymous Coward on 2009年10月07日 15時38分 (#1650164)
    まあ、色々な側面から測れる道具があるのは良いことやね。
    道具ってのは無いと始まらん。できれば競争・淘汰が起こるほどであればなお良し。

    #HDD系のベンチマークはそんな感じだけどね。
  • by Anonymous Coward on 2009年10月07日 17時06分 (#1650236)
    さすがOCaml優秀。
    うちではずっと業務に使ってるけど、速度が問題になったことはないし、みんなももっと使うといいと思うよ。
  • by Anonymous Coward on 2009年10月07日 21時46分 (#1650421)

    ライブラリにやらせられる部分はやらせて自分で書くものは最低限にってのはホント助かりますね。
    この場合問題は速度との相関で
    - ライブラリはネイティブコードにコンパイルされてるから(特にLLでは)速くなる
    - ライブラリが汎用過ぎて余計な部分も読み込むから遅くなる
    どっちに転ぶかなので、これは参考になります。

    # でも真に扱う言語を決めるのは「その言語を使う仕事がどれだけあるのか」かもしれない

  • by Anonymous Coward on 2009年10月08日 9時18分 (#1650637)
    ループ展開して速くなるぞって話だと思ってた
    手作業で展開してどこまで展開したら、余りメモリとバランスするかなんて…遠い昔だ
    • by Anonymous Coward

      今時のプロセッサは下手にループ展開すると遅くなりますけどね。

typodupeerror

弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家

読み込み中...