私の歴史と今

振り返ると恥ずかしくなるのが私の歴史。だけどそのときは真面目に書いていた訳でね。そんな今の私を書いていく。

JRubyのメリット

ホームページを見ると、次のように書いてある。

    1. High Performance
    2. Real Threading
    3. Vast array of Libraries

つまり、ハイパフォーマンスなのと、ネイティブスレッディングなのと、Javaの豊富なライブラリを使えるってことだよな。その辺、詳しく調査してみよう。(ちなみにJRubyは2001年に初公開されてる。古い!)

High Performanceについて

これはAOTコンパイルJITコンパイルによるパフォーマンスの向上だよな。インタプリタで動かしたらCRubyよりも遅いに決まっていると。AOTコンパイルで(バイトコードに)コンパイルしておけば、より早くなる。更にJITコンパイルにより劇的に速くなるということだよね。以前、YARV1.9と比較した記事を読んだことがあったけど、YARVよりもパフォーマンスが高かった記憶がある。(もちろん、起動時ではなく、JITによる最適化後)
これだ。

Ruby 1.8.6よりも50倍高速なバージョンはいくつかのケースで動かないことが確認されているため、JRuby 1.3には取り込まれないとみられる。ひとつ前のRuby 1.8.6よりも12.8倍高速、Ruby 1.9.1よりも2.54倍高速のあたりまでの実装が取り込まれるとみられる。

http://journal.mycom.co.jp/news/2009/04/07/035/index.html

1.3の時のことだから、現在のJRuby1.4ではYARV同等の性能が出ているのだろうな。1.5のRC1も登場したので、近いうちに更にパワーアップしたJRubyに会えるかも。

Real Threadingについて

ここに詳しく書いてあった。

Q. なるほど, じゃ JRuby みたいなネイティブスレッドの実装はどうなの ?
A. JRuby だと, グリーンスレッドの実装よりずっといい. JRubyRuby のスレッドをネイティブのカーネルレベルスレッドで実装しているから, Rails アプリは単一のインスタンスで並列リクエスト全部を全てのコアを使って処理できる. ここで 単一のインスタンスというのは "おおよそ単一のインスタンス" を意味している. 何かの共有リソースがボトルネックになるアプリケーション固有の都合はあるだろうからね. そういう時は 2, 3 個のインスタンスを使ってボトルネックを減らしたいかもしれない. けれど一般に, こういう場面はとてもレアだと思う. そういうのはほとんどが JRubyRails のバグで, 私達が直さなきゃいけないものだろう.

つまりこういう感じだ: JRuby を使った Rails の配備は今の 1/N 倍のメモリしか使わなくなる. N はいま並列リクエストをこなすのに必要なスレッド非安全な Rails インスタンスの数だ. スレッドセーフ Rails を動かしているグリーンスレッドな実装と比べても, 1/M 倍のメモリですむ M はコアの数. なぜなら JRuby は単一のインスタンスをめでたく並列化できるからだ.

http://www.hyuki.com/yukiwiki/wiki.cgi?WhatThreadsafeRailsMeans

つまり、必要なリソースが少なくて済むってことだよね。中小企業にはありがたい。(そもそもJavaを使えばこんな問題は発生していないから、やっとJava並になるってだけだけど)

Vast array of Librariesについて

Javaの安定した豊富なライブラリを使用できるってことだろうけど、Rubyを使いながらJavaを使うのであれば、Rubyを使う必要がない?
いやいやそうではない。Ruby(on Rails)の生産性を取り入れたいのであって、Javaを使ってしまったら意味がない。じゃあなぜJavaを使いたいのかといえば、Rubyにはライブラリが少ないのよ(たぶんw)。それに、JavaのWEBアプリケーションが既に沢山作られているのよ。それを活用しない手はない。兎に角、同一プロセス内でJavaのライブラリを使用できるのであれば、物凄い安心感を得られる。「調査してないけど、たぶん大丈夫っすよ〜」みたいな。(そう考えると、Javaは本当に巨人様だ)