『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
タイトルは「遅くて使えない」となっているが、 実際に呼んでみると「使えないわけではない」というような論調。
いや、別に「Rubyが遅い(特に1.8が遅い)」って言われても、 「はぁ、そうですか」としか思わないんだけど(性能を目指して実装してないし)、 パフォーマンスと言うのは非常にFUDに満ちあふれた分野であるので、 誰かが「遅い」とか「遅くて使えない」と言った場合には、 その真意を見極める必要がある。
で、「遅くて使えない」って言った人が、 その根拠にGreat Language Shootoutを 持ち出してくるようなら、その人の言うことは聞かなくてもいい。
Shootoutは娯楽としては面白いけど、 実際の仕事の参考になるようなベンチマークではない。 これが測っているのは主にインタプリタの性能(メソッド呼び出しや単純な計算)だが、 実際のアプリケーションの性能は、そのような部分よりも アプリケーションフレームワークの性能や、ライブラリ実装の品質などの 影響の方がはるかに大きい。
YARV (Ruby 1.9)がリリースされたあかつきにはShootoutの順位はずいぶん変化すると思う。 YARVは現在のPHPやPerlやPythonよりも速い。 テストによっては現在のRuby (1.8)の数倍から数十倍高速になる。
じゃあ、速度の問題はこれで解決かというとそんなことはない。 YARVになってもRailsの性能は改善されないからだ。 要するにRailsが遅いのだとしてもそのボトルネックはインタプリタ性能にはないってこと。
このことを見るだけでも、実際の局面でShootoutがいかに意味がないかはわかると思う。
さて、とはいえ、新しいVMを導入したのにRailsの性能が改善しないというのは あまりにもナンなので、12月のリリース前にはRailsをベンチマークにして、 ボトルネックを探して改善する計画がある。本番ではRailsも高速になるから。多分。
2008年以降の「いつか」にリリースされるUnicode 5.1で増えるもの。 これによって総文字数は100,823文字とはじめて10万文字を越える(5.0は99,024文字)。
誰だよ、65536文字表現できれば十分だなんて言ったのは。
とはいえ、もうこのレベルになると追加されるのはもうほとんど使われないような文字ばかり。 特に台湾から来たものとかは「ある特定の個人の名前に使われているだけ」とか ちょっとどうなのよ、というものもある。その人が死んだらもう歴史的文字になっちゃうね。
自分が死んだ後に歴史に名を残すのはなかなか難しいことで、 大半の人たちは200年もしないうちに存在すら定かではなくなってしまう。 それを思うと、Unicodeという国際規格に自分の名前を残すというのは 良い考えかも……迷惑だから、やめてください。ダメ、ぜったい。
This work is licensed under a Creative Commons License.
Railsの定番のベンチマークというのを教えてください。
この手の話で余り見かけないなと常日頃思っていることを（まぁ私の見聞不足も考えられるが）書いておきたい。<br>基本的にアプリケーションは，同様のアルゴリズムであれば機械語に（もっと言えば物理的な配線に）近いほど高速である。<br>言語しかりである。<br>だから構造的にインタープリタ言語がコンパイラ言語と比較して遅いのは当たり前である。<br>こういうと（Shootoutや何らかのベンチで）コンパイラAより早いインタープリタBを指摘する人もあろうかと思う。事実は認めたいが，その場合，Aの実装が悪い（Bの実装が良い）か，Bに有利なベンチであるかの何れかである。速度（機械の物理的性能を最大限引き出すこと）を優先するなら，Aよりマシなコンパイラの実装を探すべきだ。Aの実装が複数があるなら幸いだ。乗り換えればよい。<br>そうではなく，インタープリタ言語Aとインタープリタ言語Bの速度差を問題視しているならナンセンスと言わざるを得ない。なぜなら，インタープリタ言語を選択するなら如何に物理的制約から解放されて意図したことができるかを優先すべきであるからだ。<br>ちなみに私はawkが大好きだが，Shootoutでは最下位の体たらくだ（すまん）。しかし気にしたことはない。いや，正直に告白すれば，より速いawk実装に乗り換えた経験がある。同じ実装なら確かに速い方が嬉しい。しかし最も速いコンパイラ型のawkへの乗り換えを考えたことはない。コンパイル工程が増えることによる制約や管理が増えるからだ。私は速度優先ならC言語で書く。<br>繰り返しになるが，速度とは物理である。言語Aと言語Bの物理的な（むしろ論理的な）構造によって大筋決まる。同じ言語の実装Aと実装Bがある場合もしかりであるが，その場合はよほどの速度差がない限り，その言語の評価が変わるとは思えない。<br>何だか高速化の努力に冷や水を浴びせるような部分があって恐縮だが，そうではないことを蛇足ながら加えておく。