«前の日記(2004年02月02日) 最新 次の日記(2004年02月04日)» 編集

Matzにっき


2004年02月03日 節分 [長年日記]

_ [Ruby]VMの高速化手法

いつまでたってもRite VMの開発に取り掛かれないし、 そうこうしているうちに笹田さんがyarv(yunoだっけ?)を始めちゃったりしてるので、 今までサーベイしたことをメモしておこう。

Rubyのような型情報が一切なく、最適化が行いにくい言語のための仮想機械で有効そうなテクニックは以下の通り(全部ではない)。

  • word code(バイト単位ではなくそのマシンでもっとも扱いやすいサイズの整数で命令を表現する)
  • indirect branch(GCCの拡張機能を使いアドレスに直接ジャンプする)
  • branch prefetch(メモリからアドレスをloadするのに時間がかかるので、先にレジスタにフェッチしておく。パイプラインが短かったりレジスタ数がタイトな場合には効果がないかも)。
  • super operator(頻繁に連続して登場する複数の命令を融合して新しい命令を作る)

基本的なアイディアは、仮想機械の実行のうち、 もっとも多く時間を消費するのは、命令のフェッチとジャンプであるので、 ここを改善しようというもの。ソフトウェアによる仮想機械ではCISCな発想が良いみたい。 yarvはこれらの多くをすでに実現している。

これらでVM部分の実行時間が半分以下くらいになるんじゃないかと期待している。

後、残りは

  • メソッド検索の高速化
  • メソッド呼び出しの高速化

だが、これはなかなか良いアイディアがない。

メソッドキャッシュの高速化について考えると、 現在のメソッドキャッシュはなかなか効率的ではあるが、 グローバルなテーブルルックアップなのがスレッドには嬉しくない。 とはいえ、インラインメソッドキャッシュはなかなか難しいし。

メソッド呼び出しの方はスタックのデザインで少し変わるかも。 vmgenのサンプルにあるminiとかが参考になるかもしれない*1。 それと、演算子呼び出しなどで、条件が成立している時には、 直接計算してしまうことでメソッド呼び出しを削減できる。 lightningのようなものによる JITも考えられるけど、移植性を犠牲にする割にどれだけ嬉しいかは検討しないとな。

JITに限らずVMの高速化は面白いテーマではあるが、 所詮スクリプト言語なので報われるかどうかわからない分野である。

*1  もっともminiが速いのはチェックがないからかも

_ [METI]ハッカー甲子園(2)

明日は経済産業省による「高度IT人材早期発掘のあり方検討会」の第二回である。

しかし、はっきり言って私には画期的なアイディアはないのだよなあ。

  • IT分野にとんがった人材を早いうちから発見する
  • かつ世に数多くあるプログラミングコンテストに埋没しない
  • プレゼンスを獲得するため世の注目を集められる

ような企画ってのはどんなものがあるのか。 「未踏ユース」でいいじゃんって思いも一部あったりする。


«前の日記(2004年02月02日) 最新 次の日記(2004年02月04日)» 編集