TOPシステム開発> Ruby 1.9.1の特長
Ruby 1.9.1を試す!
Ruby 1.9.1を試す!

先取り!Ruby 1.9.1

著者:東京大学  笹田 耕一   2007/9/28
前のページ  1  2  3  次のページ
Ruby 1.9.1の特長

   では、Ruby 1.9.1の特長の中から、仮想マシンの導入と、M17N(多言語化)について紹介します。特に筆者が開発を行っていたことから、仮想マシン導入について少し詳しく解説します。

仮想マシンの導入による高速化

   Ruby 1.9の大きな特長の1つとして、筆者が開発しているYARV(Yet Another RubyVM)が導入され、速度改善が行われたことがあげられます。

   Ruby 1.8までは、Rubyプログラムを若干非効率な方法で実行していました(コラム参照)。そこで、Ruby用仮想マシンYARVを実装して高速に実行できるようにしました。仮想マシンを利用した高速化は、Java仮想マシンや.NET CLRの仮想マシン実行型でおなじみの手法かと思います。

   実際「どの程度速くなるか」ですが、メソッド呼び出しや変数アクセス、整数の計算など、基本的な機能が5倍程度速くなっています。この結果を確認するには、murphy氏によるベンチマーク測定結果(Ruby 1.8.6と開発版のRuby 1.9.0との比較)がわかりやすいです。

Benchmarks: Ruby 1.8 and Ruby 1.9
http://www.rubychan.de/share/yarv_speedups.html

   実際のアプリケーションでは、現在の筆者の経験からですが、だいたい1.1倍〜2倍くらいの高速化が得られるようです。

   LL魂でのまつもとさんの発表では、「YARV導入によって2〜500倍速くなる」という話がありましたが、これは2つの意味で間違いです。まず、500倍速くなるケースというのはゼロではないのですが(注1)、かなりのレアケースなので成果としてあげるのは難しいでしょう。

※注1: 例外処理の方法をいろいろと変更して高速化したので、場合によっては500倍速くなることもあります。

   また、2倍「必ず」高速化する、というような表現も間違いです。例えば現在のRuby 1.8系のRuby処理系でも、C言語で書いたプログラムとRubyで書いたプログラムの実行時間があまり変わらないことがあります。これは、例えば文字列操作やネットワーク処理などが実行時間の大半を占めているといった、Ruby処理系の処理時間があまり関係ない場合です。このような場合では、Ruby処理系を速くしてもプログラムの実行時間短縮には寄与しません。

   Rubyは元来、このような言語処理系の処理時間を気にすることがないような用途に利用されてきましたので、あまり実行速度というのは問題になりませんでした。しかし、汎用プログラミング言語としても十分書きやすいというRubyの特長から、それ以外の用途や一般的なプログラミングに多く使われるようにもなってきました。しかし、速度的な問題点からRubyではなく他のプログラミング言語で書き直す、ということも行われてきたと思います。Ruby 1.9の仮想マシン導入による高速化によって、Rubyだけで完結するケースが増え、これらの性能を必要とする用途でのRubyの活用範囲が広がるでしょう。

   余談ですが、言語処理系の性能が効いてくる最たる例が、言語処理系の基本性能を測るマイクロベンチマークです。世の中の評判は得てしてマイクロベンチマークの性能で語られることが多いため、マイクロベンチマークが遅いRubyはどんなプログラムを書いても遅い、という具合で評価が広まっていました。

   少なくともYARVを導入したRuby 1.9.1は他のスクリプト言語にひけをとらないくらい高速な実装になっています。というわけで「Rubyは遅い」という評判をひっくり返すことが、この仮想マシン導入による高速化の一番の利点かもしれません。

Ruby 1.8の処理

   このあたりは言語処理系の実装方法の話になってしまいますが、少し掘り下げてみます。

   Ruby処理系はまずRubyプログラムを構文解析という操作により抽象構文木(AST)へ変換します。Ruby 1.8以前では、このASTを直接たどりながら実行していました。仮想マシンでは、さらにASTを独自の命令セットにコンパイルして実行します。

   「木構造の構文木をたどる」よりも、「線形の命令列をたどる」ほうが高速なので、速くなるわけです。また、線形の命令列だと命令を入れ替えるなどの高速化ができるので、もっと速くなる可能性が広がります。

M17N(Multilingualization、多言語化)

   次に以前より計画されていた文字列の多言語対応がついに導入されます。

   現在、プログラミング言語の多言語化の主流は、言語処理系内部で扱う内部文字コードをすべてUnicodeにするなど、統一した内部コードに変換して扱うというアプローチ(UCS:Unified Code Set)を取ってきました。Rubyの多言語化では、各文字列に対してエンコード情報を保持する方式(CSI:Code Set Independent)で行われる予定です。

   M17Nについては現在も仕様を検討中であるため、本記事ではあまり詳しく述べません。というか、筆者はM17N周りについては詳しくないので(巻き込まれないように逃げ回っているので)、あまり詳しく述べることができません。

   この変更に伴い、いくつか文字列まわりに重要な変更が発生します。例えば、文字の扱いがいろいろと変わります。従来、文字列に対して「String#[n]」とすると、バイト列のn番目の数値が返ってきました。つまり、"Hello"[0]は72を返す、といった具合です。しかし、今後文字列はエンコード情報を保持しますので、"Hello"[0]は"H"という1文字を返すようになります。

   これは、1文字に複数バイト利用するエンコーディングの場合に重要です。いわゆる2バイト文字の場合には、n番目の1文字が返ることになります。"こんにちは"[0]という例では「こ」が返るようになります。

   また、1文字を示す文字リテラル「?a」などは文字列の長さが1(1バイトとは限らないことに注意)の文字列を返すことになります。つまり、「?a」は「a」を返すようになります。

   そのほか、M17N対応のためにエンコーディング情報を扱うために文字列や入出力関連のAPIの変更が行われる予定です。この仕様自体はまさに検討中です。

前のページ  1  2  3  次のページ


東京大学大学院情報理工学系研究科創造情報学専攻特任助教 笹田 耕一
著者プロフィール
東京大学大学院情報理工学系研究科創造情報学専攻特任助教
笹田 耕一

趣味ではじめたはずのRubyのVM開発が、いつの間にか本職に。2006年に東京農工大学博士後期課程を退学して現職。言語処理系やOS、並列システムなどの研究に従事。日本Rubyの会理事として、RubyistMagazine(http://jp.rubyist.net/magazine/)の編集なども。


INDEX
先取り!Ruby 1.9.1
  2007年クリスマスにRuby 1.9.1をリリース
Ruby 1.9.1の特長
  Ruby 1.9.1を試そう!