プログラマーズ雑記帳

NuGet は .NET プロジェクトにライブラリーやツールを追加するためのパッケージ管理ツールです。
今回はこの NuGet パッケージマネージャーのインストールと使い方について紹介します。

• NuGet Gallery | Home

なお、NuGet は .NET 開発用ですが、 Windows にアプリケーションなどをインストールするためのパッケージマネージャーもあります。 そちらに関しては以下の記事をご覧ください。

Windows 用パッケージマネージャー Chocolatey のインストールと使い方 | プログラマーズ雑記帳

NuGet パッケージマネージャー とは

パッケージマネージャー

パッケージマネージャーはインストール用の管理ツールです。 ここでのパッケージはアプリケーションやライブラリーなどのインストールする際の集まりを指しています。

インストールには Windows ではインストーラーを使うのが普通ですが、 Linux ではパッケージマネージャーを使います。 プログラミング言語でも、 Ruby における RubyGems のように独自のパケージマネージャーを持つものが増えて来ました。

このパッケージマネージャーは何がいいかというと、 あるライブラリーをインストールする場合にその依存ライブラリーも一緒にインストールしてくれる点です。
依存ライブラリーは、さらに他のライブラリー依存していたり、バージョンの制限があったりして、これを手動でチェックやインストールするは結構大変です。 パッケージマネージャーでは整合性のチェックが可能です。 特にインターネットに対応していれば、足りないもの自分で取ってきて、インストールしてくれます。

.NET プロジェクトのパッケージマネージャー

.NET 版 のパッケージマネージャーが NuGet です。もちろんネット上からのダウンロードにも対応しています。

.NET にもパッケージマネージャーができて、非常に喜ばしいことなのですが、 残念なところがあります。
大抵のパッケージマネージャーはシステムに対してインストールします。 一方、 NuGet はプロジェクト(ソリューション)に対してインストールします。 このプロジェクト用というのが残念な点であり、気をつけないといけない点です。

プロジェクト用なので、 プロジェクト(ソリューション)フォルダーにインストールした dll 等を含ませる形になります。
同じライブラリーを使うソリューションが複数あった場合には、毎回インストールする必要があります。 同じ dll を何個もシステム上に持つことにもなります。

また、他のパッケージマネージャーの経験者がプロジェクト用と気づかずに使うと "メニューが出ない" とか "コンソールで変なエラーが出る" といったことになります。

この辺は "もっとなんとかなったんじゃないか" とは思いますが、ないよりは全然いいでしょう。

NuGet の種類

NuGet には 3 種類のものが用意されています。

• Visutal Studio 版
• コマンドライン版
• WebMatrix 版

Visutal Studio 版 は VS 上でプロジェクトのパッケージ管理できるようにする NuGet です。 今回はこちらを中心に紹介します。

コマンドライン版 は VS 版に比べると使い方がややこしいです。 ただ、自分でパッケージを作成する場合には、こちらを使用する必要があります。
ここでは簡単な説明しかしていないので、 詳しくは最後の参考として挙げたページを見て下さい。

WebMatrix 版 は私が使ったことが無く、全く触れていません。

システム要件

Visutal Studio 版 は以下の条件が必要です。

• VS2012 以上
• VS2010 の場合は製品版のみ。 Express Edition は不可。
• Windows 7 以上

NuGet のダウンロードページ では "Windows PowerShell 2.0 がインストールされていれば、 XP や Vista でも動作する" といったことが書かれていました。 しかし、 PowerShell 2.0 は Vista の SP2 には含まれておらず、単体でインストールも失敗しました。


コマンドライン版 では、特にシステム要件の記述はなく、 Vista でも動作しました。

インストール

NuGet 自体のインストールは インストーラーを使う方法 と VS から行う方法 の 2 通りあります。

インストーラーを使ったインストール

インストーラーを直接ダウンロードして、インストールします。
一台の PC に複数バージョンの VS を入れている場合などには、 一度にできて便利だと思います。


まず、以下のページから NuGet.Tools.vsix をダウンロードします。

• NuGet Package Manager 拡張機能

ダウンロードした vsix ファイルを実行するとインストールウィザードが開始します。

ここで、 インストールする VS のバージョンを確認して、 [インストール] を押せば、 インストールは完了します。

Visual Studio からのインストール

VS からインストールする場合には 拡張機能マネージャー を使用します。

1. メニューの [ツール] → [拡張機能と更新プログラム] を選択
   
   
   
2. [オンライン] を選択
     「 NuGet パッケージマネージャー」の項目が出ない場合は検索に "NuGet" と入力
   
   
   
3. 「Nuget Packager」 の [ダウンロード] を選択

VS がインストーラーをダウンロードしてきて、自動的に起動します。
インストールウィザードに従って、インストールを行ってください。

使い方

NuGet をインストールするとメインメニューの [ツール] に NuGet 用のメニューが追加されます。

GUI でのパケージインストール

[NuGet パッケージの管理] 画面からインストールを行います。
これを呼び出すメニュー項目は以下のメニュー内にあります。 この時、 インストール先となるプロジェクトを開いておく必要があります。

• メインメニュー : [ツール] → [ライブラリ パッケージ マネージャー]
• ソリューションエクスプローラー : ソリューションやプロジェクトを選択した時の右クリックメニュー

パッケージのインストール手順は、拡張機能のインストールとほとんど同じです。
「 Prism 」 のパッケージを例とすると次のようになります。

1. [オンライン] を選択する。
2. 検索で "Prism" と入力
3. 「Prism」の項目にある [インストール] を選択

インストールするとパッケージがダウンロードされ、 ソリューションフォルダー内に dll 等が置かれます。
[参照設定] も自動的に追加してくれます。

コンソールでのパッケージインストール

あまり使うことはないと思いますが、 VS 内のコンソールからインストールすることもできます。 パッケージ名がはっきりわかっている場合にはこちらの方が速いかも知れません。

コンソールはメインメニューから起動します。

• [ツール] → [ライブラリ パッケージ マネージャー] → [パッケージ マネージャー コンソール]

このコンソール上では上下矢印キーによる履歴や Tab による補完など PowerShell と同じ操作が可能です。
パッケージをインストールするには プロジェクトを開いた状態で以下のように入力します。

Install-Package パッケージ名

PM> Install-Package Prism 

この他のコマンドについては 'get-help NuGet' を実行するか、以下のページを見てください。

• Package Manager Console Powershell Reference

コマンドライン版 NuGet.exe

コマンドライン版(NuGet.exe)も簡単に紹介します。

インストール

NuGet のインストールの説明ページのリンクをクリックすると、直接 NuGet.exe がダウンロードされます。

• Installing NuGet

ダウンロードした exe ファイルを PATH の通ったフォルダーにおいて下さい。

アップデート

NuGet.exe は自分で自分のアップデートができるようになっています。
サイトからダウンロードしたものが最新ではないこともあります。 インストール後、アップデートしておいた方がいいでしょう。

以下のコマンドを実行すると NuGet.exe 自身がアップデートされます。

~/test $ nuget update -self
Checking for updates from https://nuget.org/api/v2/.
Currently running NuGet.exe 2.5.0.
Updating NuGet.exe to 2.6.1.
Update successful.

使い方

以下の形式でコマンドを実行するとカレントフォルダーにパッケージがダウンロードされます。

nuget.exe install パッケージ名

  ~/test $  nuget.exe install Prism 

コマンドの使用法に関しては 'nuget.exe help [コマンド名]' を実行するか、 以下のページで確認してください。

• Command Line Reference

参考

• NuGet - NuGet でプロジェクト ライブラリを管理する
• .NET 開発の新標準「 NuGet 」入門（前編） - ＠ IT
• .NET 開発の新標準「 NuGet 」入門（後編） - ＠ IT

今回は JVM, .NET といった仮想マシン(VM)についての記事です。
最初、 .NET と仮想マシンの説明のスライドを作っていたのですが、 最近 JVM と BEAM を少し調べて興味がでてきたので、合わせて VM の話としました。 そうすると今度は、スクリプト言語や LLVM の話も外せないなと思って足したら、結構な大作になってしまいました。

JVM に絞った話では、以下の記事にも説明を書いているので、こちらもご覧ください。

• JDK のインストール(Windows)と Java 関連用語の説明 | プログラマーズ雑記帳

---

---

スライド版です。

---

---

ここからブログ版です。

はじめに

仮想マシンといっても、 OS のエミュレーターのようなものではなく、 JVM といったプロセス仮想マシンについてのお話です。

JVM 、 .NET Framework など最近、この仮想マシン(VM)のシェアが大幅に増加して来ました。
また、 LLVM(正確には VM ではない)の登場や VM を利用したスクリプト言語の高速化など 今 仮想マシンが熱い です。

そこで、 "VM とは何か ?"、"なぜ使うのか ?" といったことについてざっくり説明していきます。

目次

1. 仮想マシンとは
   • コンパイラー、インタープリター型との比較
2. 特徴
   • メリット、デメリット
3. 各種VM について
   • JVM、.NET Framework、Erlang VM (BEAM)、スクリプト言語での VM、LLVM

仮想マシンとは

コンパイラー、インタープリター型と比較にして VM の概要を説明します。

通常(Native)アプリ

C, C++ に代表される Native やコンパイル型と呼ばれるタイプのアプリケーションは次のような手順で、作成、動作します。

1. ソースファイルを用意
2. コンパイルして実行ファイルを生成
3. コンピューター(OS)上で動作

ソースファイルは人が読み書きするテキストファイルです。
これをコンパイルして OS(機械) が読める マシン語(機械語) に変換します。
マシン語のファイルは機械が読むものなので、 0, 1 の並びです。 これはバイナリーファイルと呼ばれます。(厳密にはテキストファイルも 0 1 の並びですが)

インタープリター型

スクリプト言語、インタープリターと呼ばれるタイプは、コンパイルを必要としません。 インタープリターに直接ソースファイルを渡して、実行することができます。



これらの代表としては Perl, Ruby, Python といったところでしょう。 JavaScript も実行するのが OS ではなく、ブラウザーですが、スクリプト言語です。

インタープリター型はコンパイルが不要という手軽さが利点ですが、 その代わりコンパイル型と比べて、実行速度が遅いという欠点があります。

仮想マシン

C#, Java などの言語が使っている仮想マシン(VM)は OS(マシン) 上に仮想的な OS(マシン) を用意します。 VM 自体は、基本的に Native アプリケーションで、 OS が実行します。
Native では実行ファイルはマシン語で書かれたファイルですが、 VM の場合は中間コード(バイトコード)です。 これはソースのプログラミング言語とマシン語の中間であり、 Native と同様にソースファイルをコンパイルして作成します。



VM を実現しているアプリケーションやライブラリーの集まりをランタイム (Run-time emvironment, 実行環境) と呼ぶことが多いです。

インタープリターと VM の違い

インタープリターと VM は似ていて、インタープリターを VM と呼ぶことさえあります。 この 2 つの違いを見ていきましょう。

インタープリターはたいてい次のような手順で実行します。

1. ソースファイルを解析
   • 字句解析、構文解析を行います。ここではまとめてソース解析と呼んでいます。
2. 構文木を作成
   構文解析により、ソースコードの内容をインタープリターが扱いやすい構文木と呼ばれるデータ構造にします。
3. 構文木を評価エンジンが解釈、実行
   • 解釈、実行することを評価(evaluate)といいます。
     また、この評価する部分がインタープリターの中心で、 評価エンジンの部分をインタープリターと呼ぶこともあります。

このインタープリターと VM の大きな違いは次の 2 つです。

• 中間コードなので、ソース解析が不要
• JIT(Just In Time, 実行時) コンパイル

一つ目は中間コードを使う点です。
インタープリターが実行時にソース解析を行うのに対して、 VM では事前にコンパイルして、 ソース解析を済ましておきます。 実行時にソース解析が不要になる分だけ、速度的にお得です。

この中間コードはソースコードのように人が読める必要がないため、たいていバイナリーであり、 バイトコード と呼ばれます。

中間コードといっても、マシン語ではないので、 VM が解釈、実行します。 そこで、 JIT コンパイルを使います。これが 2 つ目の違いです。

実行時 (JIT) コンパイル

VM は中間ファイルの実行時にマシン語にコンパイルしてから実行します。
VM が必ず JIT コンパイルを使うというわけでもなく、インタープリターのように実行することもあるのですが、 たいていは JIT コンパイルが使われています。


この方法は Native のコンパイルと比べて、制約、デメリットがあります。

• コンパイル時間も実行時間に含まれるため、最適化に時間をかけれない
• 生成したマシン語コードはメモリー上に保持するので、メモリーを大量に使用する

そんな欠点の多い JIT コンパイルですが、 なぜ使われているかというと、それでも一回マシン語に直して実行した方がインタープリターより速いためです。
とはいっても、 Native のコンパイラー型よりは遅いです。 特に起動時に行うコンパイルが多いため、起動には時間がかかります。

インタープリター << VM < コンパイラー

しかし、 JIT コンパイルも改良され、あくまで部分的にですが、 Native よりも早くなることもあります。

よく使うところだけコンパイルすることによって、 コンパイル時間を減らし、 メモリー消費量の削減をします。

1. 起動時にはインタープリター形式で実行し、プロファイルを取る
2. よく使う部分(メソッド)、フローだけコンパイル
   (コンパイルしてない部分はインタープリター形式)

コンパイルの単位は基本的に関数(メソッド)単位ですが、特にフローレベルでコンパイルすることを トレーシングといいます。
例えば、正常系、異常系の if 分岐があったとして、正常系だけコンパイルするといった感じです。

実行時の環境がわかっていることによって、より状況に合わせた最適化ができます。

• 実行時コンパイラ - Wikipedia
• トレーシング実行時コンパイル - Wikipedia

スクリプト言語では JIT コンパイルを使わないのか?

インタープリター形式よりもマシン語に直す JIT コンパイルの方が高速です。

VM の特徴として、 JIT コンパイルをあげましたが、
   "速いのだったら、スクリプト言語でも JIT を使えばいいじゃん"
と思われる人もいると思います。

確かにその通りなのですが、 スクリプト言語の場合にはコンパイルに関して難しい問題があります。
それはスクリプト言語の多くが動的型を使っている点です。
Java, C# は変数宣言で型を指定する静的型ですが、 動的な型では変数の型を特定しません。
この柔軟性はスクリプト言語の書きやすさにもなっています。 ただその分、高速なコンパイル済みコードの生成を難しくしており、 コンパイルするメリットがなくなります。

そのため、前はスクリプト言語は JIT コンパイルはしないものだったのですが、 最近は状況が変わってきました。

用語の区別

スクリプト言語で使われる VM, JIT コンパイルについては後述しますが、ここでは今後、次のように用語を区別します。

用語	説明
インタープリター	直接、ソースファイルを実行。 マシン語にはしない。
JIT コンパイル	実行時にマシン語にしてから実行
VM	中間コードを実行 JIT コンパイルしないものもある。
スクリプト	直接、ソースファイルを実行。 JIT コンパイルするものも出てきた。

仮想マシンの特徴

VM のメリット、デメリット

デメリット

最初にデメリットからあげます。

遅い、メモリー消費量が多い

速くなったとはいっても、 Native と比べれば、やっぱり遅いし、メモリーを大量に使用します。

リバース エンジニアリングされやすい

商用アプリに限った問題ですが、中間言語の形式でリリースすることで、 元のソースを得るリバースエンジニアリングがやりやすくなってしまいます。
これを防ぐ難読化という技術もあります。これはわざとコードをぐちゃぐちゃにして、元をわかりにくくしています。 ただ、コードに手を加えるため、速度の低下や新たなバグを生成させる危険がある上、完全に防ぐものでもありません。

インタープリター、 Native の両方の利点がない

インタープリターはコンパイルがいらない手軽さがありますが、言語をインストールしないと使えません。
一方、 Native はコンパイルが必要ですが、生成ファイルだけで動作します。
VM はコンパイルが必要なうえに、実行環境(ランタイム)のインストールも必要となります。

メリット

デメリットが多い VM がなぜ広く使われているかというと、 当然、使うメリットがあるためです。

1. 移植性の向上
2. 開発の効率化
3. クロスランゲージ

移植性の向上

アプリケーションは中間コードの形式です。 そのため、 VM を OS 等の環境で変えれば、 アプリケーションはそのままで動作します。
例えば、新しい OS を作ったとしても、 VM さえ用意すれば、大量のアプリがすぐ使えるようになります。
ただ、理屈はそうだというだけで、実際は環境ごとに手を入れて直さないと動かないということも結構あります。

開発の効率化

コンパイラーの仕事のうち、大きなポイントが 2 つあります。
一つが言語の仕様に基づき、ソースを解釈する処理です。 もう一つはプログラムをいかに速く動かすかという最適化の部分です。
この特性の違う二つを VM では分けて開発できるようになります。


例えば、速度に関しては初期の Java は「使い物にならない」といわれるほど、遅いものでした。
しかし、中間言語、 VM の仕様が公開されており、多くの JVM が開発されました。 そこで、 前述の JIT コンパイルや世代別 GC といった高効率な GC(Garbage Collection) などの改良により、 かなり改善してきました。

• 開発者が知っておくべき Java と仮想マシンの歴史 - ＠ IT

また、ソース解析が分かれていることによって、新しい言語でも解析部分の作成だけで済みます。
例えば、 F# では次のような感じです。

1. 関数型言語が流行っている
2. 実行環境はそのまま使える
3. センスを問われる言語仕様は実績のある OCaml を使う
4. F# の出来上がり !

もちろん、.NET への移植はそう簡単なことではないと思いますが、従来のコンパイラー作成より簡単になることは間違いないでしょう。また、後述するクロスランゲージで .NET のライブラリーもすぐ使えます。

クロスランゲージ

中間コードを利用することによって、言語間のやり取りが簡単にできるようになります。

共通したライブラリーが使える

• ライブラリーも中間コードなので、 1 つ作ればどの言語からでも使える
• スクリプト言語からのライブラリーの呼び出しも簡単

---

スクリプト言語の組み込みが簡単

• 全体を書きやすいスクリプトで作って、スピードネックだけ静的型言語で作ることができる(にかわ言語)。
  • C++ など Native のライブラリーもラップして使えるようになるものが多い。
• 動的言語でアプリケーションに拡張性を持たせる(マクロ、プラグイン)

---

モジュールごとに言語を変える

私はアプリケーションの目的にあわせて言語を選択するものだと思っています。
それに加えて、今後はアプリケーションの部分(モジュール)の目的に合わせて言語を選択し、 組み合わせて、使っていくことになっていくのではないかと思います。

例えば、関数型言語は単体テストしやすい、並列処理に強いといった特徴があり、 アプリケーションのコア部分に向いています。 一方、 GUI はオブジェクト指向との相性がいいので、これらを組み合わせるといった感じです。

各種 VM

以降は VM 別に解説していきます。

1. JVM
2. .NET Framework
3. Erlang VM (BEAM)
4. スクリプト言語での VM
5. LLVM

Java 仮想マシン (Java Virtual Machine, JVM)

旧 Sun Microsystems 社が開発した Java 言語のための実行環境

Write once, run anywhere

"一回書けば、どこでも動く" が Java のスローガンでした。
スローガンからもわかるように Java が VM を使っているメインの目的はクロスプラットホームでしょう。
Windows, Linux といった PC の OS だけでなく、 厳密には JVM ではありませんが、その変種の Dalvik は Android といったモバイルの分野でも広く使われています。

ただし、 個人的には分離、仕様公開による副次的な方が功績が大きいと思います。

ソース解析

Java の生み出した環境は素晴らしいものだと思いますが、 Java の言語仕様自体は単に C++ の仕様を劣化させただけのように私は感じます。
しかし、 Java を改良した言語や全く新しい言語など数多くの JVM 言語が生まれ、 それらを JVM の環境で動作させることができます。

ランタイム(実行環境)

開発効率のところでも述べましたが、 Java はデビュー時は異常に遅いものでした。
しかし、仕様の公開などにより GC 、 JIT コンパイル性能が向上されていき JVM の機能の改良され、 それらの技術の促進にもつながっていると思います。

• 開発者が知っておくべき Java と仮想マシンの歴史 - ＠ IT
• Java はどのように動くのか - スライドでわかる JVM の仕組み
• Javaはどのように動くのか - 図解でわかるJVMの仕組み：連載｜gihyo.jp … 技術評論社

JVM 言語

JVM はその名のとおり、もともと Java 用のものでしたが、 今では 200 を超える JVM 言語が生まれています。
JRuby のように移植系の言語ではメジャーな汎用プログラミング言語はすべて移植されているのではないかという勢いですし、新しい言語にも興味深いものがたくさんあります。

• JVM上で動くプログラミング言語のまとめ - NAVER まとめ
• List of JVM languages - Wikipedia, the free encyclopedia

動的型付け言語は JIT コンパイルによる高速化が難しいと説明しましたが、 JDK 7 からは動的言語のサポートも追加されています。 Java 専用だったものが、積極的に JVM 言語のサポートも行われているようです。

• JDK 7 の新機能： Java 仮想マシンにおける動的型付け言語のサポート

JVM 言語を大きく分けると次のような感じです。

Clojure, Scala など

コンパイルして、 Java バイトコードを生成する言語

JRuby, Groovy など

JVM 上で動作する動的言語

ただ、実際はどっちでも動作するものが多いです。
JRuby はインタープリター、事前コンパイル、実行時(JIT)コンパイルと 3 つのパターンで動作できます。 また、 Clojure, Scala もスクリプトとして動作させることもできます。

• Clojure, Leiningen の Windows へのインストールと使い方 | プログラマーズ雑記帳
• Scala のインストール(Windows)と Emacs モードの設定 | プログラマーズ雑記帳

.NET Framework

Microsoft による開発、実行環境

Common Language (共通言語)

.NET が登場した時には、 "MS が Linux に進出か ?" と思ったものです。
実際、 mono(Xamarin) といった他のプラットホームで動作するものもありますが、 MS 自身は仕様の公開だけして、それほどクロスプラットホームには積極的ではないみたいです。

ちなみに他のプラットホームとしては .NET を JVM 上で動作させる IKVM.NET といった面白い試みもあります。

• IKVM.NET - Wikipedia

では、クロスプラットフォームが目的ではないとしたら、目的は何かというと、 私は Java では副次的効果であったクロスランゲージ(共通言語化)が最初からメインの目的だったと思います。

1. ライブラリーを作ったら、 VC++, VB など複数の言語から使いたい
   • これはユーザーの要望ですが、 MS 自身も多くの言語を抱え、言語ごとにライブラリーを用意するのは負担だと思います。
2. 昔は COM 。
   • 言語間を超えてオブジェクト(ライブラリー)を使う技術として COM がありました。
     ただ、これが面倒で難しく、 かなり使いづらいものでした。
3. .NET では共通(中間)言語化で垣根をなくし、言語間の連携が簡単に。

また、言語間だけでなく、 同じ言語でも C++ ではライブラリーとして公開するのに おまじない のような記述が必要だったり、 lib ファイルが必要だったりしましたが、 .NET では dll だけで済むようになっています。

さらに .NET では新しい技術の導入にあたって、過去の資産も無駄にしませんでした。
COM は .NET でもそのまま使えますし、 昔の C++ ライブラリーも C++CLR(.NET 用の C++)でラップするだけで使えるようになっています。

• .NET からの COM コンポーネントの呼び出し

VM ではコンパイル型、インタープリター型の両方のデメリットを持っていると書きましたが、 .NET に関しては OS 制作の強みで VM のデメリットも減っています。

• 動作にランタイムが必要
  • OS と一緒にインストール
• コンパイル型は生成ファイルだけで動作可能
  • コンパイルしたバイトコードを exe 形式に

OS と一緒にインストールされるのは、アップデートの問題もあるので、それほどでもないかも知れませんが、 コンパイルしたバイトコードをそのまま実行できるのは、 開発者もユーザーもあまり VM ということを意識せずに利用できます。

• .NET アプリケーションが実行される仕組み － ＠ IT
• Java から見た.NET （ 1 ）：プログラマが知っておきたい Java と.NET の違い (1/4) - ＠ IT

用語

.NET では略称の用語がいろいろ出てくるので、それらについてまとめておきます。
ちなみに Java の用語に関しては以前の記事をご覧下さい。

• JDK のインストール(Windows)と Java 関連用語の説明 | プログラマーズ雑記帳

.NET の仕様は CLI として公開されています。
この CLI に従って MS が実装した実行環境(ランタイム)を CLR と呼びます。
ただ、これは実行のためのコアな部分だけです。 さらにライブラリーや開発ツール等を加えて .NET Framework となります。

略称	用語	説明
CIL (MSIL)	共通中間言語 Common Intermediate Language (MicroSoft Intermediate Language)	中間言語
CLI	共通言語基盤 Common Language Infrastructure	.NET の VM の標準化仕様
CLR	共通言語ランタイム Common Language Runtime	CLI の MS による実装
DLR	動的言語ランタイム Dynamic Language Runtime	CLR 上で動作する動的言語のためのライブラリー群 スクリプト言語を高速に動作させるためのサポート
.NET	.NET Framework	開発、実行環境 CLR にライブラリー、ツールなどを加えたもの

.NET 言語

共通言語としていろいろな言語が使えるのですが、.NET の機能をフルに使うための 標準として C# を作成されました。
C# は Delphi の作者として有名だった アンダース・ヘルスバーグさんが開発された言語で、 基本的に移植しかしない MS にしては開発に力を入れている言語だと思います。(Delphi 、 C#、 TypeScript も 0 から作ったかといわれると微妙ですが)。
言語作者として多くのファンを持つ人で、私も C#、 TypeScript あたりからファンです。


MS の旧言語も .NET に対応しています。

言語	ベース言語	説明
C++/CLR	VC++	C# を使った方がいいけど、旧 C++ ライブラリーのラップで必要
Visual Basic .NET	Visual Basic	動的言語の一部機能(DLR)を使用
J#	VJ++(Java)
JScript .NET	JScript(JavaScript)	コンパイルが必要

JScript はあまり有名ではないかも知れませんが、 WSH(Windows Script Host) と言われるスクリプトの実行環境で動作する言語です。 言い換えると Windows のローカルで動かせる JavaScript です。
個人的には JScript は Windows におけるインストールいらずのスクリプト言語として重宝しているのですが、 コンパイルが必要となると C# の方がいいかなと思います。
ただ、 JavaScript への変換言語もありますし、それらと組み合わせると需要があるかもしれません。

• 続々出てきた JavaScript 系新言語。どれを使う? | プログラマーズ雑記帳

WSH には VBScript という Visual Basic 風のスクリプトもあるのですが、 こちらはコンパイルすると VB.NET とかぶるためか、 VBScript.NET はありません。



また、旧言語からだけでなく、新しい言語、移植もあります。

言語	ベース言語	説明
F#	OCaml	関数型言語
Windows PowerShell		シェル、シェルスクリプト
IronRuby	Ruby	動的言語。 DLR 上に構築
IronPython	Python

Windows PowerShell はコンソールプログラム(シェル)であり、シェルスクリプトも指します。 これは WSH の置き換えが狙いにあるようです。



MicroSoft 製ばかりではなく、サードパティー製の言語も少しづつ出て来ました。

言語	ベース言語	説明
ClojureCLR	Clojure	JVM 言語の移植
Fantom		JVM、 .NET の両方で動く

Fantom は Java, C# 風の言語で JRuby や Clojure と違い、 JVM 、 .NET のソースコードの移植性が特徴です。 ただ、その分 Java 等との親和性は落ちているように感じます。

Erlang VM (BEAM)

大手通信メーカー Ericson の開発した Erlang 言語のための VM 。

let-it-crash (クラッシュさせろ)

Erlang VM (BEAM) は JVM や .NET に比べると少しマイナーかも知れません。 Erlang の場合は今までと別の目的で VM を使用しています。

Erlang は耐障害性の高いリアルタイム分散処理システムの作成を得意としており、 これを実現するための軽い特殊なプロセスの実現が目的です。
また、複数台のコンピューターに処理を分ける分散コンピューティングにも強くなっています。


ここでいう "耐障害性" は安定性とは別もので、むしろ逆の発想です。
エラーが発生してもプロセスを監視し、自動で復旧します。 エラーを起こさないのではなく、エラーを許容するシステム(fault-tolerant)です。

信頼性への最適化

Erlang は fault-tolerant に加え、実行時アップデートもでき、なるべくサービスを止めないシステムに向いています。

サーバーサイドとしては、 今は Java が主流です。 JVM でも似たことはできますし、速さは JVM の方が上です。

• Twitter Storm : リアルタイム分散処理、 耐障害性
  • Twitterのリアルタイム分散処理システム「Storm」入門
  • リアルタイム分散処理Stormの耐障害性は？ - Tech-Sketch
  • [Storm] ストリーム処理エンジン Storm | 情報基盤システム学研究室
• vert.x : 実行時アップデート
  • 内部から見た Vert.x と Node.js との比較 - uehaj's blog
  • vert.xのハイボリューム／スケーラブルなアーキテクチャ - Eberhard Wolff氏とのインタビュー

ただし、 JVM は確かに速いですが、 速度だけが設計上の最優先事項ではありません。
速度は他の要素とトレードオフとなることが多いです。 例えば、 Ruby などは "書きやすさ" と "速度" の選択では書きやすさを優先し、 スクリプト言語として最高レベルの言語に仕上がっています。
Erlang も電話会社の言語らしく、速さよりも信頼性に最適化されています。 ライフラインのサーバーなどでは、信頼性を一番におくべきものだと思います。

• 2012-02-14 - トーフサロン
• マルチコア危機： Scala と Erlang の対立
• Javaはもう古い！次の主流は「関数型」 - ［Erlang］分散システムに特化し耐障害性に優れた言語：ITpro

ただ、 "信頼性に優れている" というのは、 Erlang 擁護側の意見で、 個人的には JVM のシステムも捨てたものではないかなと思ってます。

Erlang VM (BEAM) の言語

Erlang VM 上で動作する言語と言えば、もちろん、 Erlang です。 これは Prolog 風の関数型言語です。

• Erlang のインストール(Windows)と Emacs モードの設定 | プログラマーズ雑記帳
• Prolog のインストール(Windows) と Emacs の設定 | プログラマーズ雑記帳

ただし、この Prolog 風というのがクセモノで、かなり書きづらいです。 Erlang はその遅さと書きづらさにも定評があります。

遅いのは信頼性の代償だとしても、書きづらいのはいただけません。
しかし、 最初 Java 専用の JVM から多くの JVM 言語が生まれたように、 Erlang VM でも Erlang 以外の言語がボチボチ登場しています。

• Elixir
• Lisp Flavored Erlang
• efene programming language
  • へびのぬけがら: プログラミング言語 efene について

書きやすさで言えば、中でも Elixir がお勧めです。

• Elixir ： Erlang VM 上で動作する Ruby 風味の関数型言語 | プログラマーズ雑記帳

スクリプト言語での VM

ここからは動的言語でのコンパイルの問題について掘り下げた(ただし、さっくりと)後、 VM(JIT コンパイル) を利用しているスクリプト言語について見ていきます。

スクリプト言語でも VM (JIT コンパイル)

インタープリター型よりも JIT コンパイルを使う VM の方が速いと記述しました。
であれば、当然、 スクリプト言語でもインタープリターをやめて JIT コンパイルすればいいということになります。

動的型付けでの JIT コンパイル

ただし、ここで出てくるのが静的な型でないと高速なバイトコードにできないという問題です。
この対処法はガードと呼ばれるもので、型を決めてコンパイルします。

• 決めていた型なら高速なバイトコード
• 違う場合は通常のインタープリター処理

変数のオブジェクトを自由に変えられるといっても、 普通書く時はめったに最初に入れた型から変えませんし、妥当な対処法だと思います。
ただし、最近コンパイル言語で使われている型推論のようなことは ちゃんとやるとかなり時間がかかります。 しかし、 int, string, ... というように単にガードを入れまくるのは、 逆に遅くなります。
そこで、実際は VM ごとに他にもいろいろやっているらしいです。 ただし、これ以上は踏み込まず、スクリプト言語別に移りたいと思います。 というよりは、あまりよく理解できていないので、踏み込めません。

• JIT - nothingcosmos wiki
• 流行りの JIT コンパイラは嫌いですか? — PyPy Advent Calendar 2011 v1.0 documentation
• FirefoxでJITコンパイルの「正しさ」を担保する”Invalidation” | ψ（プサイ）の興味関心空間

JavaScript V8 エンジン

Google の開発した JavaScript エンジンで、 Google Chrome で使用されています。 スクリプト言語にもかかわらず、 JIT コンパイルを使って高速な動作を実現させています。

• Google Chrome

また、オープンソースなので、サーバーサイドの Node.js などでも利用されています。 サーバーサイドも JavaScript で書くことによって、クライアントサイドとのソースの統一が実現出来ます。


ただ、 V8 エンジンが有名ですが、 JavaScript エンジンの高速化は Chrome だけのものではありません。 Firefox では IonMonkey で JIT コンパイルを使っています。

• Firefox 、 JIT エンジン「 TraceMonkey 」削除へ | 開発・ SE | マイナビニュース

Firefox では Asm.js にも対応しています。
これは 整数用の変数の場合、 + を付けて始めるなど特殊な書き方で型指定する JavaScript のサブセットです。 サブセットなので、 Asm.js に対応していなくても、 JavaScript として動作させることができます。
対応している場合には Native の速度が期待出来ます。

• asm.js:コンパイラのための低レベルかつ高度に最適化可能な JavaScript のサブセット - Publickey
• azakai: What asm.js is and what asm.js isn't

Chrome でも Firefox 程ちゃんと対応する予定は無いみたいですが、 型指定されているので、ある程度の高速化は見込めるようです。

• Google 、 asm.js の最適化は Chrome でも進めていることを表明、ただし一般的な最適化として - Publickey

Dart VM

Dart は Google が JavaScript の置き換えとして開発している言語です。
まだ開発中の言語ですが、着々と使われていっているようです。

• 続々出てきた JavaScript 系新言語。どれを使う? | プログラマーズ雑記帳
• Blossom が Dart に移行
• Google Dart:Polymer が Web UI を置き換える
• AngularJS の Dart へのポーティングが進行中

Dart は VM 上で動作します。 Node.js と違い、 最初からサーバーサイドでの動作も考慮されて作成されています。
このような形態は Dart が最初ではなく、 実は Java もデビュー時はクライアントサイドの言語(Java アプレット)として開発されていました。


Dart VM は高速な V8 エンジンを改良して作成されており、速度にも期待が持てます。 実際、JVM を少し超えるレベルの速度らしいです。

• 最新の Dart VM が JVM に DeltaBlue ベンチマークで勝つ
• Frameworks Round 6 - TechEmpower Blog
  • こちらのベンチマークはエラーが出ているせいか、まだ負けています。

Python(PyPy)

Python では JIT コンパイルを使った PyPy という処理系があり、 本家(CPython)よりも高速に動作するらしいです。

• 流行りの JIT コンパイラは嫌いですか? — PyPy Advent Calendar 2011 v1.0 documentation
• ryu22eBlog:第八回ありえるえりあ勉強会 ～ PyPy のキホンの気 に参加しました #arielarea

PyPy は Python で実装された Python というのがその名前の由来ですが、 正確には RPython という型推論できるように制約を加えた Python のサブセットで実装されています。

ちょっとややこしいですが、先に RPython というサブセットを作って、 JIT コンパイルできるようにし、 それを使って Python と互換性の高い PyPy が作られています。
通常、 VM はバイトコードをトレーシングしますが、 PyPy の場合は RPython をトレースするので、メタトレーシング と呼ばれています。

この仕組みは PyPy の開発にかぎリません。 RPython を使って実装すれば、 他の処理系でも JIT コンパイルできるようになります。
実際に別言語の処理系として Ruby を RPython で実装した Topaz があります。

• Rails Hub 情報局: 本家の 5 倍速？ Python で実装した Ruby 処理系の「 Topaz 」が登場

ただ、 次の RubyVM で述べるように Ruby 自体に VM が使われています。
まだ、 Topaz も開発中で、どうなるかはよくわかりませんが、 効果の程はどうかなと個人的には思っています。
また Topaz の現状はただの Ruby の別実装なので 新しい宝石名をつける程ではなったと思います。 Python 、 Ruby の両方のライブラリーを使えるような言語になると面白いのですが。

Ruby VM

Python と PyPy の関係と違い、 Ruby VM (YARV) はのバージョン 1.9 以降から本家(MatzRuby)に正式に採用されています。

サイトの説明によると JIT コンパイルに関しては試験段階っぽいですが、それでも 5 倍程度高速らしいです。

• 「 Ruby 1.9 は 1.8 より平均 5 倍速い」、 YARV 笹田氏 － ＠ IT

本家以外ではそれぞれの VM で JIT コンパイルができます。

言語	VM
JRuby	JVM
IronRuby	.NET(DLR)
MacRuby 、 Rubinus	LLVM (後述)

LLMV

コンパイラー作成のための基盤。

LLVM は略称ではなく、フルネーム

VM の話の中で紹介していますが、正確には LLVM は VM ではありません。 LLVM は Low Level Virtual Machine の略ではなく、これでフルネームです。
おそらく誤解を生むので変えたのだと思いますが、今のサイトの説明ではそうなっています。

• The LLVM Compiler Infrastructure Project

"VM でないのならば、なんなのか" というとコンパイラー基盤です。
ではコンパイラー基盤はというと、"コンパイラーを作るためのライブラリーやツールの集まり"です。 簡単にいえば、コンパラーを作るのを楽にするためのものです。


前の方で VM のメリットについていろいろ書いて来ましたが、これらは基本的に開発者目線のものです。
対してデメリットのほとんどは使用者側に生じます。 純粋に使用者側に立てば、 Native の方がメリットが多いでしょう。

• Android が iPhone に勝てない点: ニュースの社会科学的な裏側

そうはいっても、私も開発者であり VM のメリットは大きいと思っています。 LLVM は Native コンパイラーの作成に VM のメリットを持たせるものです。

VM と同じ利点

中間言語(LLVM IL) を使うことによって、 VM と同じ利点が得られます。

• 開発の効率化
  • フロントエンド(ソース解析)だけ作ればいい
• 移植性の向上
  • ただ、Windows はまだ試験段階で、Mac がメイン

ただし、 生成するのはあくまでマシン語なので、クロスランゲージの利点はあまりありません。
(後述の Emscripten のように少しはあります)

VM じゃないといいつつ JIT コンパイルも

また、話が少しややこしくなりますが、 VM ではないと言いつつ、 JIT コンパイルもできますし、 GC もあり、 VM のように使えます。

しかし、他の VM のようなランタイム(実行環境)を配布するような形態ではなく、 スクリプトへの組み込みとして限定したもので、若干オマケっぽい位置づけにあります。

これを利用した有名なものは Mac 用の Ruby である MacRuby です。 また Rubinus も LLVM を利用した Ruby です。

LLVM を使った言語

Clang :

• C, C++, Objectiv-C 用コンパイラー
• コンパイルエラーのメッセージが親切らしい
• Apple 製

LLVM を実際に使った言語で一番有名なものは Clang でしょう。
Objectiv-C 用コンパイラーの作成に Apple が LLVM を使ったことにより、 LLVM に Apple の後押しがついて、一気に有名になった感があります。


その他にも D 言語、 Scheme などの既存言語や Pure (関数型) などの新しい言語も出てきています。

• The LLVM Compiler Infrastructure Project
• Julia : スクリプト言語最速? 手軽さと速さを求めた科学技術計算向け言語 | プログラマーズ雑記帳

その中でちょっと興味深いなと思ったのが Emscripten です。
これは LLVM のバイトコードから JavaScript を生成するツールです。 中間言語から変換するということは、LLVM を使ったいろんな言語から JavaScript に変換できることになります。

あと、ロゴがかっこいい

どうでもいいといえば、どうでもいいことなのですが、 LLVM はロゴがかっこいいです。
ゲームやファンタジーが好きな人は知っていると思いますが、ワイバーン(飛行型の小型ドラゴン)です。 メタリックな感じで SF 心もくすぐられます。

まとめ

目的

今まで説明した対象の VM (LLVM の場合は中間コード) を使う主目的をまとめると次表のようになります。

対象	主目的
JVM	クロスプラットフォーム(移植性の向上)
.NET	クロスランゲージ(共通言語)
BEAM	耐障害性、分散コンピューティング
スクリプト言語	高速化
LLVM	コンパイラーの開発を効率化

クロスランゲージ

言語を組み合わせたアプリ開発を個人的には一番注目しています。
クロスランゲージ関連でまとめたものが下表です。

VM	言語	ベース言語	動的言語	C++ 連携
JVM	多	Java	JSR 292	JNI, JNA
.NET	中	C#	DLR	COM, C++CLR
BEAM	少	Erlang	Erlang が動的	erl_nif

使用出来る言語の量だけで言えば、 一番古くからある JVM が一番多いです。
シェアがあまり大きくない Erlang VM (BEAM) は少ないですが、 Elixir は魅力的な言語だと思います。

JVM には関数型言語も多くありますが、オブジェクト指向の Java がベースのため、 JVM は関数型言語には向いてない面があります。
例えば、 末尾再帰最適化(Tail Call Optimization 、 TCO) と呼ばれる機能は関数型では欲しい機能ですが、 JVM の制限により、 JVM の関数型言語では使えません。 .NET の場合は C# もオブジェクト指向ですが、機能はあります。もともと共通言語化が目的だからかもしれません。 BEAM はベースが関数型言語で使用可能です。

動的言語の高速化のためのサポートは .NET 、 JVM ともにあります。 BEAM は高速化に関してはよくわかりませんが、 Erlang 自体が動的型付けを使っています。

C++ ライブラリーといった旧資源の利用に関しては、 .NET が一番積極的な感じです。
ただし、 Java からも C++ の利用は可能です。 Erlang からも利用はできるようですが、 まだ試験段階らしいです。

• 末尾再帰最適化 - (hatena (diary ’Nobuhisa))
• JDK 7 の新機能： Java 仮想マシンにおける動的型付け言語のサポート
• Erlang の型記法（ Type Notation ） - 檜山正幸のキマイラ飼育記
• JNI より簡単に Java と C/C++ をつなぐ「 JNA 」とは（ 1/4 ）- ＠ IT
• Integrating Erlang with C++ - Stack Overflow

今後は

その他の今後の動向が興味深いものについて、挙げてみます。

LLVM

VM のシェアは増えてますが、やっぱり、 Native の利点は大きいでしょう。 Mac では LLVM が主流になると思います。他の環境ではどれだけ使われるようになるでしょうか。

DartVM

Dart はクライアントサイドとしても、もちろん注目ですが、 JVM の速度を超え、 サーバーサイドの言語としても注目です。

スクリプト言語

スクリプト言語における JIT コンパイルでの高速化は結構大変なので、 今やっているのは JavaScript 、 Ruby 、 Python といったメジャーな言語ぐらいです。 これからはもっと増えていくような気がします。

Erlang VM (BEAM)

サーバーサイドとして、 JVM vs BEAM では JVM に押されていますが、 今後シェアは増えていくのでしょうか ?
逆に耐障害性や分散コンピューティングといった BEAM の得意分野でも JVM が向上していき、減っていくのでしょうか ?

Ruby には本家 Ruby だけでなく、いろいろな処理系があります。
今回はそれらの Windows へのインストール方法について紹介します。 また、各処理系での gem (パッケージ管理ツール)についても簡単に触れています。

1. MatzRuby (本家 Ruby)
2. IronRuby (.NET Framework)
3. JRuby (JVM 言語)
4. Topaz (Ruby の PyPy 実装)
5. mruby (組み込みシステム向け軽量 Ruby)

IronRuby, JRuby, Topaz はそれぞれ .NET 、 JVM 、 PyPy 上で動作する ruby です。 これらを良く知らないという方は以前の記事をご覧ください。

• 雑把の仮想マシン(JVM, .NET, BEAM, スクリプト言語, LLVM) | プログラマーズ雑記帳

MatzRuby (本家 Ruby)

公式の Ruby 処理系です。
他の処理系と区別するため、 MRI(Matz' Ruby Implementation), MatzRuby, CRuby などと呼ばれることもあります。

インストール

Windows 用のインストーラーが用意されているので、簡単にインストールできます。


まず、以下のサイトからインストールしたいバージョンをダウンロードします。

• RubyInstaller for Windows
  • Downloads
  

ダウンロードしたrubyinstaller-X.X.X-pXXX.msi ファイルを実行します。

インストールウィザードの最初にセットアップ時の言語を選ぶことができ、日本語にも対応しています。


インストール先の変更もできます。
オプションにチェックを入れると環境変数 PATH の設定もインストーラーが行ってくれます。


後はそのままウィザードに従っていけば、インストールは完了します。

インストールすると bin フォルダーに以下の exe ファイルができています。

実行ファイル	説明
ruby.exe	通常版
rubyw.exe	GUI スクリプト用
irb	対話モード用

通常使う exe は ruby.exe です。

~ $ ruby -v
ruby 2.0.0p247 (2013-06-27) [i386-mingw32]

では rubyw.exe は何かというと ruby で GUI アプリを作った場合に使う実行ファイルです。 GUI アプリを起動するときにコンソール画面を出さないようにするために用意されています。

gem (RubyGems)

gem は Ruby のパッケージ管理ツールで、ライブラリーなどを追加したいといった時に使います。
ネット上からパッケージ(gem)を取ってきて、インストールします。 そのパッケージが依存しているパッケージもあれば、それらも一緒に入れてくれます。

パッケージのインストールは以下のように行います。

  gem instal GEM名 [オプション]
  (例) $ gem install rails -v "= 1.4.1"

バージョンは -v で指定できます。 何も指定しない場合は最新版がインストールされます。
更新、 削除の場合は install ではなく update, uninstall をそれぞれ指定します。

その他、次のようなコマンドも覚えておくと良いかもしれません。

コマンド	説明
gem help [コマンド名]	ヘルプ
gem list	インストール済みパッケージの一覧を表示
gem list -d GEM名	インストールしたパッケージの詳細情報表示
gem update --system	RubyGems 自身を最新版にアップデートする

• そろそろ整理しておきたい、Gemコマンドの使い方 - ばくのエンジニア日誌

なお、 プロキシー経由でないと外部にアクセスできない場合には環境変数 http_proxy でプロキシーサーバーとポート番号を指定しておきます。

プロキシーサーバー:ポート番号
(例) foo.bar.co.jp:8080

どんな gem パッケージが利用できるかは gem list -r で見れます。
しかし、大量に出て来るので、 Web 上見つけてからインストールすることが多いです。 以下のサイトなどで探すことができます。

• BestGems -- Ruby Gems Download Ranking
• The Ruby Toolbox - Know Your Options!
• RubyGems.org | your community gem host

ただし、 C/C++ の拡張ライブラリーを使っている gem パッケージの場合には DevKit が必要になります。 DevKit のインストールについては以下の記事をご覧ください。

• DevKit のインストール | プログラマーズ雑記帳

Bundler

RubyGems は依存している必須のものをインストールするので、 オプション機能やテスト機能で使うパッケージの選択といったことができません。
そこで、 Ruby で作ったアプリケーションなどでは Bundler という gem を更に管理するツールを使うのが主流になって来ています。

gem の練習がてら Bundler もインストールしておきましょう。
なお、使う前は Bundler が古いと動かないことがあるので、使う前には update もしておいた方がいいと思います。

~ $ gem install bundler
~ $ gem update bundler

使い方はアプリケーションにもよりますが、基本的にソースをダウンロード、展開して、 Gemfile ファイルがあるフォルダーで次のようなコマンドを実行します。

d:/redmine/redmine-2.3.0 $ bundle install
d:/redmine/redmine-2.3.0 $ bundle install --without development test

インストールしない機能は --without オプションで指定します。
どのような機能が指定できるのかは各 Gemfile の中身で確認して下さい。

• gem 管理の新標準ツール"Bundler"の Tips - 昼メシ物語
• Redmine 2.0 の Windows でのインストール | プログラマーズ雑記帳

IronRuby (.NET Framework)

IronRuby は .NET Framework 上で動作する Ruby です。
Ruby のソースコードを事前にコンパイルして使う Ruby.NET もあったのですが、 .NET では IronRuby というのが最近の流れのみたいです。

インストール

ダウンロードページからIronRuby.msi のインストーラーをダウンロードします。
IronRuby の 1.0 系が Ruby の 1.8 系で、 1.1 系が Ruby の 1.9 系としているようです。

• IronRuby - Downloads
  

ダウンロード後、インストーラーを実行するとインストールが完了し、 PATH の登録もインストーラーが行ってくれます。

ウィザードに従っていけば問題ないと思いますが、変更するとしたら、インストール先をかえるか、 Silver Light や Visual Studio 用のモジュールを外すくらいでしょう。


インストールすると bin フォルダーに ir.exe ができています。 これが IronRuby の実行ファイルです。

~ $ ir -v
IronRuby 1.1.3.0 on .NET 4.0.30319.18052

igem

IronRuby 用の RubyGems である igem もあります。使い方は基本的に gem と同じです。


ただし、そのまま igem を使うと次のようなエラーが発生します。(Ver. 1.1.3)

~ $ igem install json_pure
ERROR:  While executing gem ... (NoMethodError)
    undefined method `set_params' for #<OpenSSL::SSL::SSLContext:0x00001a8>

OpenSSL のライブラリーを使っているところでエラーが発生しているようなので、 設定で一旦 SSL のチェックをしないようにします。

~(環境変数 HOME で指定したフォルダー) の直下にある .gemrc ファイルに以下の記述を追加します。 (なければ作成)

~/.gemrc :

:ssl_verify_mode: 0

これで igem が使えるようになりますが、 SSL のチェックをしないのはお勧めできない状態です。
OpenSSL のライブラリー(rubysl-openssl)をインストールした後、追加した行を削除します。 削除後も OpenSSL のエラーはでないようになっています。

 ~ $ igem install rubysl-openssl

また、ライブラリーではなく、実行ファイルのような gem の場合は管理者として実行する必要があるようです。

• IronRuby で RubyGems を利用する igem コマンドの実行 - Jamzz の日々

JRuby (JVM 言語)

JRuby は JVM 上で動作する Ruby です。
IronRuby とは違い、 JRuby だけで 3 つのモードがあります。

• 事前コンパイル
• ソースコードを直接実行
  • JIT コンパイルモード
  • インタープリターモード

なにが違うかというと "速さ" です。 インタープリターモードよりも JIT コンパイルした方が速く、 また、手間は増えますが、事前コンパイルするとさらに速くなります。

• JRuby 50 倍速、 MacRuby はすでに到達域 - 竹内関数 | 開発・ SE | マイナビニュース

インストール

JRuby をつかうためにはまず JDK をインストールしておく必要があります。 JRE だけでも動作しそうなのですが、 JRuby プロジェクトのインストール方法のページにはそう書いてあるので、 一応インストールして JAVA_HOME の環境変数も設定しておきます。

JDK のインストール方法については以前の記事をご覧ください。 JDK や JRE といった用語の説明も行っています。

• JDKのインストール(Windows)と Java 関連用語の説明 | プログラマーズ雑記帳

ダウンロードは JRuby のダウンロードページから JRE 無し版のインストーラーを選んでください。

• Downloads — JRuby.org
  

ダウンロード後、インストーラーを実行するとインストールが完了します。
PATH の登録もオプションのチェックを入れたままであれば、インストーラーが行います。


インストールすると bin フォルダーに jruby.exe ができています。 これが JRuby の実行ファイルです。
また、 JRuby 用の RubyGems である jgem.bat もあります。 こちらも使い方は gem と同じです。

ただし、 bin フォルダーの中には gem.bat もあります。 本家 Ruby と共存させる場合には、 PATH で JRuby のフォルダーが後にくるよう変更するか、 gem.bat を別名に変更してください。

jruby

デフォルトでは JIT コンパイルモードで動作します。通常これで問題ないと思います。


インタープリターモードなどの最適化動作を変更したい場合はオプションで指定します。 このオプション指定については以下ページに詳しい説明があります。

• How JRuby Makes Ruby Fast を読んで、試したログ - tragicomedy

事前コンパイルする場合は jrubyc のコマンドを使います。 こちらは以下のサイトが参考になるのではないかと思います。

• たくまけい: jrubyc でプリコンパイルしてみた

また、 現在 の JRuby (Ver. 1.7.4) は本家 1.9.3 互換で動作します。 オプションで 1.8 系として動作させることもできます。

 ~ $ jruby -v
 jruby 1.7.4 (1.9.3p392) 2013-05-16 2390d3b on Java HotSpot(TM) Client VM 1.7.0_21-b11 [Windows 7-x86]
 ~ $ jruby -v --1.8
 jruby 1.7.4 (ruby-1.8.7p370) 2013-05-16 2390d3b on Java HotSpot(TM) Client VM 1.7.0_21-b11 [Windows 7-x86]

jgem

jgem は gem と同じように使えます。

~ $ jgem install mirah

ただし、 jgem 自身のアップデート(update --system)を実行すると次のようなエラーが発生することがあります。

RubyGems system software updated
'inNT' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

この場合、カレントフォルダーを jruby.exe のあるフォルダーにして実行すると、 エラーは残っているみたいですが、一応インストールは最後まで終わります。

c:\>where jgem
c:\jruby-1.7.4\bin\jgem
c:\jruby-1.7.4\bin\jgem.bat

c:\>cd c:\jruby-1.7.4\bin

c:\jruby-1.7.4\bin>jgem update --system

Topaz (Ruby の PyPy 実装)

PyPy という JIT コンパイルできる Python の処理系があります。この PyPy は Python (正確には RPython) で実装された Python で、 他の言語処理系の基盤としても使えます。
で、 実際に RPython で実装された Ruby が Topaz です。

Topaz はまだまだ開発段階ですが、インストールも簡単ですし、ちょっと試すのにはいいのではないかと思います。
なお、互換としては本家 Ruby の 1.9.3 が対象となっています。

• Current Status — Topaz 0.1 documentation

インストールは、まず Topaz の Nightly ビルドのページから windows32 のファイル (topaz-windows32-XXXXXXXX.tar.bz2)をダウンロードし、適当なフォルダーに展開します。

• Topaz | Nightly Builds
  

展開したフォルダー内の bin の中にある topaz.exe が実行ファイルです。 Topaz 用の gem コマンドはまだないようです。

 d:/usr/topaz/bin $ ./topaz.exe -v
 topaz (ruby-1.9.3p125) (git rev 42c875e) [i686-windows]

よく使うという場合は bin フォルダーを PATH に追加するとパス指定なしで起動できます。

mruby (組み込みシステム向け軽量 Ruby)

mruby は組み込みシステム向けの軽量 Ruby です。
組み込みシステム向けですが、 Windows でも動作することができ、 アプリケーションへの組み込みにも向いています。 JVM 、 .NET のアプリへの組み込みには、 JRuby や IronRuby がいいと思いますが、 Native な C, C++ アプリへの組み込みにはいいのではないかと思います。

• 埋め込みruby、組み込みruby、組み込み向けruby 違いわかる? | プログラマーズ雑記帳
• mruby を知ると Ruby がもっと楽しくなる！｜【 Tech 総研】

とはいえ、いきなり組み込みというのは大変でしょう。 今回はお試しでちょっと動かしてみるということでインストールします。
ただ、インストールいってもバイナリーファイルが公開されているわけではないので、自分でビルドする必要があります。 ここでは Visual Studio を使ったビルドを紹介します。

• 連載： Windows ランタイム・コンポーネントによるコードの再利用：第 2 回　 Windows ランタイム・コンポーネントの作成と mruby のコンパイル (3/3) - ＠ IT

ちなみに mruby には Mrbgems という gem 風の機能があります。
こちらはライブラリーをインストールするのではなく、ビルド時に機能モジュールを追加して実行ファイルを作成します。詳しくは mruby の Readme.md ファイルを見てください。

必要プログラムのインストール

Visual Studio

VS2010 または VS2012 が必要となります。
gcc を使う場合は Cygwin や Mingw などになると思います。

本家 Ruby

最初の章を参考にインストールしておいて下さい。

Windows 版 Bison

以下のページからインストーラーをダウンロードします。

• Bison for Windows
  

インストーラーを実行します。この時インストール先はスペースを含まないようにする必要があります。 デフォルトは "C:\Program Files\..." となっているので、変更しておきます。


PATH の設定まではおこわないので、 手動でインストール先の bin フォルダーを PATH に追加します。

ダウンロード

mruby の GitHub のページからソースコードをダウンロードします。
とくにリビジョン(バージョン)は切られていないようなので、最新版を zip で取得し、任意の場所に展開します。

• mruby/mruby
  • GitHub, Bitbucket でのファイルのダウンロード方法 | プログラマーズ雑記帳

ビルド

デフォルトの設定では ToolChain(制作に使うツールの集合)が gcc に設定されています。
そこで build_config.rb ファイルのツールチェインの記述を :vs2010に変更します。

 MRuby::Build.new do |conf|
   # load specific toolchain settings
   toolchain :gcc   # <= ここを :vs2010 に変更

Visual Studio 2012 の場合は :vs2012 です。利用可能なツールチェインについては以下のページで確認できます。

• https://github.com/mruby/mruby/tree/master/doc/compile#toolchains

展開したフォルダー上で次のコマンドを実行します。

 d:/src/mruby-master $ ruby ./minirake

自分の環境では設定済みなので確認していませんが、 VS のコンパイラーの PATH の設定が必要かもしれません。 上手くいかない場合は以前の記事を見てください。

• VS で gcc のようにファイルを指定してビルドする方法 | プログラマーズ雑記帳

ビルドが完了すると bin フォルダーに mruby.exe が作成されます。

 d:/src/mruby-master/bin $ ./mruby.exe --version
 mruby - Embeddable Ruby  Copyright (c) 2010-2013 mruby developers

その他

その他の Ruby 処理系としては LLVM を使った MacRuby や Rubius なども有名です。
しかし、 MacRuby は Mac 用ですし、 Rubius の Windows 版はまだ安定板がリリースされておらずビルドも必要なため、今回は記述していません。

また、 Ruby っぽいというだけでよければ他にもいろいろあります。

• Elixir ： Erlang VM 上で動作する Ruby 風味の関数型言語 | プログラマーズ雑記帳
• RedScript : Ruby 風の JavaScript 変換言語 | プログラマーズ雑記帳
• Mirah : 静的型付けを持った Ruby 風の JVM 言語 | プログラマーズ雑記帳
  • ジャワ語で Ruby

Erlang VM(BEAM)、 LLVM については、以下の記事を参考にしてください。

• 雑把の仮想マシン(JVM, .NET, BEAM, スクリプト言語, LLVM) | プログラマーズ雑記帳

今回、種々の処理系のインストール方法を紹介しましたが、 Ruby の複数環境の構築としては Windows には pik というツールがあります。 これは Ruby の違ったバージョンや IronRuby や JRuby を切り替えて使えるツールです。
ただし、残念ながらこちらは開発が止まっているらしく、 3 年ほど更新されていません。 そのため、 ruby 2.0.0 や 1.9.3 など新しいバージョンはありませんが、 1.8 系と 1.9.2 を切り替えて使いたいといった目的には使えると思います。

• Ruby アソシエーション: 複数の Ruby 環境の構築
• pik を使って Windows に ruby をインストール - miau の避難所