新しいインストーラが Windows 版 Ruby の実行速度を大きく向上する

作者 Mirko Stocker , 翻訳者 吉田 英人 投稿日 2009年8月17日

セクション

運用/インフラ,

設計/アーキテクチャ,

デベロップメント

トピック

IronRuby ,

Ruby ,

動的言語 ,

.NET ,

言語 ,

Windows ,

コンパイラ ,

プログラミング ,

インスタレーション ,

パフォーマンス&スケーラビリティ ,

Install ,

OS

共有 |

原文(投稿日：2009/8/11)へのリンク

Antonio Canigiano氏 の最新版 Ruby ベンチマークによれば，IronRuby のパフォーマンスは Ruby 1.8.6 を大幅に上回っている。これに対して Luis Lavena氏が，Antonio 氏は " IronRuby のパフォーマンスと，公式のワンクリック・インストーラに使われている12年前のコンパイラ(VC6)を比較"しているのだ，とコメントしている。その Luis 氏は現在，ワンクリック・インストーラの後継に関係する作業を行っている。ベンチマーク第２ラウンドが示すように，これはパフォーマンスを大きく改善するものだ。

Ruby 1.8.6 および 1.9 用の新たな Windows インストーラは急を要しているようだ。InfoQは Luis Lavena 氏からさらに詳しい話を聞いた。

Ruby コミュニティにとって非常に有益であるとはいえ，インストーラを作るよりもっとエキサイティングなことがあるようにも思うのですが？

確かにそのとおり，Ruby や関連ライブラリのビルドとリビルドを繰り返すより，もっと面白いことはたくさんあります。この仕事を続ける動機はいつも，私自身の不便さを解消することにありました。

私は個人的に C や C++, さらにアセンブラを使った開発作業のグルーとしてのスクリプトを記述するために，Windows で Ruby を使ってきました。Ruby によっていくつかのタスクを自動化することができ，そのおかげで自分の作業に集中することができました。

こうして何年もかけて蓄積した知識や経験は，寛容でオープンなコミュニティと共有する価値のあるものだと考えたのです。

新しいインストーラは，以前のものとどのように違うのでしょうか？

新インストーラでは何よりもまず，Windows に Rubyを正しく，以前より適切かつ容易に組み入れることを目指します。

２つめに重要な点は，利用可能なツールの面で Linux ユーザと windows ユーザの間の垣根を低くする，ということです。ビルドツールに関する知識を持たない大部分の Windows ユーザは，gem 作成者あるいは他の協力者が Windows ネイティブな gem をリリースしてくれるのを待っていなければなりません。

Ruby エクステンションのビルドと組込作業に12年前のコンパイラ(Visual C 6.0)が必要であったことが，問題をさらに大きくしました。コンパイラがインターネットで入手できないために，メンテナンスがますます難しくなったのです。

今回の新インストーラは Ruby-core 開発者たちが提供しているバイナリリリースをベースにするのではなく，完全にスクラッチからビルドを行います。そのことが設定オプションやバンドルされているエクステンションのバージョンなど，いろいろな調整を行う機会を私たちに与えてくれました。

それだけではありません。私たちは GNU Readline を ピュア Ruby バージョンである rb-readline に変更するなど，依存ライブラリをいくつか置き換えています。

リリースサイクルをより早くするため，この新インストーラではサードパーティ製のライブラリは使用していません。そういったものはインストーラへの組込に際して，チェックやメンテナンスに非常に大きな労力を必要とするからです。

ユーザはまずRuby，RubyGems，ドキュメントの入った最小限のインストーラを入手して，そこから必要なgemだけをインストールすることになるでしょう。膨大な量のダウンロードを心配することはありません。

新しいインストーラの作成にこれほど手間がかかるのはなぜでしょう。Ruby を再コンパイルすればよいのではないのですか？

簡単なように思えますが，単にRubyをパッケージして公開するだけではないのです。

Ruby は Zlib，OpenSSL，ReadLine など複数のパッケージに依存していますが，これが外部ライブラリを必要とします。それら外部ライブラリの中には，Windows向けにコンパイルされたものがなかなか見つからないものもあります。

バイナリが見つからなければ，一度戻って自分でビルドするしかありません。ひとつの例として私たちは OpenSLL の比較的新しいバージョンを使用していますが，これは最新のバイナリがなく，しかもソースからのビルドが大変な作業だからです。

更新やカスタマイズが必要なのは Ruby 自体だけでなく，時にはそれを取り巻くエコシステム全体にまで及ぶこともあります。

Windows用の新しいRubyバイナリが入手できるようになった場合，それはネイティブ拡張を持つ Gem にはどのような影響を与えるのでしょうか？ "旧"Ruby用にビルドされたネイティブ拡張を持つ Gem を RubyInstaller バージョンの Ruby で使用することはできますか？

実行可能ですが，gem をこのバージョンのRubyで動かそうとするとうまくいかない場合があります。RubyInstaller がこの１年間に渡って開発されてきた理由のひとつがここにあります。

Ruby 自体の記述言語であるC言語に詳しい方であれば，Cプログラムをコンパイルするときに CRT という名称の C ランタイムライブラリがリンクされることをご存知でしょう。これはメモリ確保や文字列操作，I/Oといった低レベルサービスを行うライブラリです。

GCCもVC6も同じCRT(MSVCRT.DLL)をターゲットとしてリンクを行います(より詳細な情報は Luis のブログを参照してください)。

これで問題のひとつが解決できます。残る問題はRubyコードです。

Ruby をコンパイルする時，ビルド時に使用するコンパイラやフラグの指定を内部の設定ファイルに記述しておきます。 つまり VC6 を使ってビルドする場合は RUBY_PLATFORM に "mswin32" を，GCCを使う場合は "mingw32" というように設定します。

理屈の上ではこの２つはバイナリ互換ですが，実際には Ruby コードからのアクセスの仕方次第となっているライブラリもいくつかあります。

ライブラリにプラットフォーム依存コードを組み込むことがありますが，そのライブラリが Windows で実行されるかどうかを判断するために RUBY_PLATFORM の設定内容をチェックして "mswin"， "mswin32"，あるいは "win" という文字列を検索している開発者がいます。

RUBY_PLATFORM の設定内容が "mingw32" を含んでいる場合，そのようなライブラリはこれを Linux 上で動作するものと想定するため，結果として失敗します。

このような開発者は，この悪い習慣をただちに正すべきです。

Windowsコードをガードする方法として，私は RUBY_PLATFORM =~ /mingw|mswin/ という定義を提案します。

最初のリリースについての予定を教えてください。

現時点で達成できている主な目標は以下のものです。

1. Ruby 1.8.6 と 1.9.1 のビルド自動化
2. 上記をインストーラにバンドル可能にすること
3. 開発キットパッケージをユーザに開放し，開発を容易にすること
4. rake-compiler を使って Gem 作者が Windows ユーザ向けツールを容易に出荷できるようにすること

いくつかのタスクについてはプロジェクトTODOに概要を記録しています。これを再構成して，RubyInstaller Wiki によりよい形で反映したいと思っています。

ドキュメント作成とインストーラ関連のタスクがほぼ完了した時点で，最初の安定バージョンをリリースすることができるでしょう。

RubyInstaller に関するさらに詳しい情報と最新のプレビュー１リリースが Luis 氏のブログに紹介されている。RubyInstaller のリポジトリは GitHub にある。