Kenta Murataさん「bigdecimal ライブラリと Ruby の数値系の未来」

BigDecimalのメンテナであり，Ruby札幌メンバーの一人である，Kenta MurataさんのBigDecimalの発表から中ホール最終日は始まりました。セッションの冒頭で，12月4日に札幌Ruby会議03が開催されるとの告知がされました。

BigDecimalとは，Rubyに標準添付されている数値計算ライブラリです。BigDecimalクラスとBigMathモジュールの2つから構成されています。BigDecimal classは多倍長浮動小数点数を扱うことができ，メモリが許す限りまで"一応"小数を扱えるクラス。もう一つのBigMath moduleは，BigDecimal用のMathモジュールです。Mathクラスのメソッドに対応しており，桁数を指定できるようになっています。今回Murataさんは，このBigDecimalが抱えている問題点を指摘しました。

グローバルに管理されている動作モード

BigDecimalでは，動作モードを設定して，例外発生の有無や，計算の丸め方を設定できるようになっています。しかし，「⁠動作モードがグローバル変数であるため，スレッドセーフでない」とMurataさんは指摘されました。

そのため，Murataさんは発表の前日に動作モードについて，Rubyのスレッドごと独立した動作モードを設定できるように改善したことを説明されました。さらに，ブロック内で動作モードを変更しても，ブロックから抜けた時にはモードが戻るようにされたそうです。このブロックでの動作は，「⁠動作モードがスレッドセーフになったからこそできた」と語られました。

有効桁数について

小数点第何桁まで意味があるかということを示すのが有効桁数です。「⁠現在のBigDecimalでは，この有効桁数が管理されていない」とBigDecimalの問題点を指摘されました。現在の実装では，メモリ確保済み桁数と使用済み桁数が管理されているそうです。また，RubyのFloatも有効桁数を管理していないため，BigDecimalとFloatを混在して使用した場合，Floatへ強制変換されるため，数値の信頼性がなくなってしまいます。

インスタンス生成

BigDecimalのインスタンス生成は，文字列から生成します。

BigDecimal.new("3.14")

しかし，数値からインスタンスを生成することができず，さらにBigDecimalのインスタンスからインスタンスを生成もできません。「⁠インスタンス生成方法も改善していきたい」と述べられていました。

スピード

BigDecimalは内部での数値の表現方法が複雑であるため，かけ算や割り算の計算が遅くなっているそうです。しかし，計算を短縮するアルゴリズムがあるため，それを利用することで早くできるため，改善していきたいと述べられました。

BigDecimalの未来について

Murataさんは，今後のBigDecimalの未来として，「⁠Rubyでは無理数に対応したクラスがないため，計算可能実数を利用してBigDecimalで対応したい」と意気込みを語られました。計算可能実数を利用することで，無理数を内部ではアルゴリズムとして表現し，小数表現が必要になったときのみ計算するという方法をとることで，きれいに実装できるのでは，と説明されました。

Masahiro Tanakaさん「NArray and scientific computing with Ruby」

Ruby/NArrayの開発者である，Masahiro TanakaさんによるNArrayの紹介です。NArrayとは，多次元数値配列クラスのライブラリです。NArrayを使用することで，大規模な多次元数値配列の計算を高速かつ簡単に扱うことができます。

最初に，Ruby/NArrayを利用している科学分野を紹介してくれました。使用されている分野としては，「⁠地球物理学」「⁠物質科学」「⁠分子生物学」「⁠力学」など幅広い分野で使われているそうです。

Ruby/NArrayは，1999年に0.3.0を最初にリリースされ，「⁠IDL（Interactive Data Language⁠）⁠」⁠「⁠Yorick」「⁠Python Numeric」などを参考に作成されたと語られました。NArrayの実装の特徴としては，「⁠次元数の扱い方」「⁠配列の形」「⁠要素の型のもち方」「⁠メモリブロック」というのがあるそうです。

続いて，Ruby/NArrayの操作方法が説明され，Rubyの配列で計算を行ったときとの，コードと速度の違いが紹介されました。Ruby1.9.2で100万の要素のある配列同士のかけ算を行なった場合，

(0...n).map{|i| a[i] * b[i]}

のようなコードになり，180msかかるそうです。しかし，NArrayなら，

a * b

と書け，6.4msと28倍速くなりました。簡潔に記述できて，高速というのは嬉しいですね。ただし，NArrayは直接メインメモリにアクセスしてしまい，最近の計算機のアーキテクチャにはあっていなく遅くなってしまうことがあると述べられました。

最後に，現在研究されている並列分散ワークフローについて説明されました。科学データ処理は複雑なワークフロー記述が必要なのですが，現在はMakeを使って記述されているそうです。しかし，Makeでは表現力が乏しいため，より表現力のあるRakeを利用したPwRakeを作成されています。

Q&Aでは「NArrayは標準添付になりませんか？」という質問に対して，「⁠今は満足していないので次のバージョンで満足できれば標準添付にしていきたい」と意気込みを述べていました。

Hideki Miuraさん「yarv2llvmはどう失敗したのか」

Hideki Miuraさんによる，Yarv2llvmというRuby1.9から採用されているYARVのバイトコードをLLVMで動作するように変換するツールがどのようにして失敗していったのか，そして今後新たに取り組んでいくYtlというツールの紹介が発表されました。

まず，そもそもなぜRuby処理系が遅くなってしまうのか，という問題は以下の2点にあると語りました。

• Dynamic Method Search （⁠実行時でないと解決できない）のコスト
• BONXING/UNBOXING によるデータ変換のコスト

そして，その問題点を「型推論を利用することで解決できるのではないか」ということを出発点としてyarv2llvmの開発が始まったのですが，型推論を行う時間が掛かりすぎてしまうなどの理由で頓挫してしまったそうです。

そこで，新たに開発が始まったのがYtlです。YtlはRuby1.9の機能をフルセットでサポートすることを目標に開発しているトランスレータです。

現在の進捗状況として，簡単な型推論なしでHelloWorldが表示される程度とのことでしたが，今後の展望や乗り越えていく必要のある課題についても語り，今後の発展に期待が高まる紹介になりました。

Satoshi Shibaさん「Ruby 用 AOT コンパイラ」

東京大学笹田研究室の学生の芝 哲史さんによる，Ruby用AOTコンパイラについての発表です。AOTコンパイラ（rcc）とは，ahead-of-time（AOT）といい，実行前にスクリプトを機械語に変換すること方法のことです。最初は笹田さんと卜部さんによって作成されていたものです。

rccは，「⁠Rubyの高速化」「⁠Ruby1.9との互換性」をかかげ，いつかRuby自身に取り込んでもらうという大きな目標があるようです。

rccでは，1つのスクリプトから1つのバイナリを生成する形式をとっているそうです。生成されるファイルは，単体実行可能ファイルと共有ライブラリの生成できます。ソースコードの変換の流れは，一度YARVのバイトコードに変換されたコード列をCの関数に変換します。その変換方法は，テンプレートを使用して変換していると説明されました。そのとき，高速化や変換後のコードサイズ削減のために工夫されていることが述べられました。

現在rccは，互換性や可搬性，細かい高速化については実装が完了しているそうです。今後は，「⁠プロファイル情報を用いたコード生成や，更なる最適化を目標としている」と，今後の展望を述べられました。

最後にrccの評価を紹介し，現時点の総括を以下のようにされました。

• Rubyについているテストは99%通過
• 5種類のOS，2種類のプロセッサアーキテクチャで動作可能
• マイクロベンチマークは全体的に速度向上
• マクロベンチマークの速度が低下してしまうものもある 今後の更なる改良に期待です。

Tetsu Sohさん「Memory Profiler for Ruby」

Tetsu Sohさんが，現在研究されているRubyのメモリプロファイラについて紹介されました。Tetsuさんは，一つ前に発表された芝さんと同じく，東京大学笹田研究室の学生さんです。

まず，Tetsuさんが作成したメモリプロファイラの使用方法をデモ動画で紹介されました。動画の内容は，RDocを動かし，メモリが解放されない箇所を特定するという内容でした。Rubyのソースリポジトリにあるlibディレクトリに対してRDocを実行したところ，ドキュメントの生成に15分かかって，1.3GBのメモリを消費していたそうです。しかし，このメモリプロファイラを使用して問題点を発見し，RDocに対する3行の修正で7分の生成時間，82MBのメモリ使用量になったことが述べられました。

Tetsuさんの作成されたメモリプロファイラのUIは，とても優れたものでした。実行しているアプリケーションの状況がリアルタイムに確認できるだけでなく，アプリケーションの実行を止めたり，再起動したりできます。また，どのオブジェクトがGCされたかという円グラフが見れたり，そのオブジェクトがソースコード内のどの箇所に沢山あるかというのがわかるようになっています。動画内でメモリプロファイラの操作が行われるたびに，会場からは歓声があがりました。

「可能な限りメモリプロファイラによる影響を少なくする」「⁠取得するプロファイル情報の変更を簡単に行なえるようにする」というコンセプトで作成されていることが話されました。影響を少なくするため，RubyVMとは別にプロファイラのバックエンドを持つようにし，VMのeventとcontrol情報のやりとりを行なっているそうです。バッグエンドからは，Javaで作成されたプロファイラのフロントエンドにTCP/IP経由で情報を送りあっていることが説明されました。また，どのプロファイル情報を取得するかをコントロールできるようにもなっていることが述べられました。

IRCやQ&Aで，「⁠すぐ使いたい」という声が沢山でていました。Tetsuさん自身も「RubyのVMの一部を変更する必要があり，現在コミット件はない。でも1.9.3には入れたい」と意気込みを語っていました。