[#7785] rb2c — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

28 messages 1999/09/02

[#7845] [Q] irb and SizedQueue — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

14 messages 1999/09/15

[ruby-dev:7838] Re: rb2c

From: Kazuhiro HIWADA <hiwada@...>
Date: 1999-09-11 21:10:45 UTC
List: ruby-dev #7838
ひわだです。

From: keiju@Rational.Com (Keiju ISHITSUKA)
Subject: [ruby-dev:7833] Re: rb2c 
Date: Fri, 10 Sep 1999 14:03:27 +0900

> けいじゅ@日本ラショナルソフトウェアです.

> >#スピード狂としては残念至極… ^^;;
> 
> やはり, メソッドの束縛のところがネックになっているのでしょうね? 

そうですね。静的に束縛できればもっと optimize の手も考えられるんです
が…。

ただ今のところ rb2c がたいして早くならないのは「静的に束縛できない」か
らというよりも、「結局Rubyインタプリタと同じ処理をせねばならないところ
が多い」からと言えそうです。

えっと以下はもう独り言の世界ですが、ひょっとすると興味がある人もいるか
も知れないので書いてしまいます ^^;。

* Rubyインタプリタの行う処理 (のうち重そうなもの)

(1) eval ループ (メソッド呼び出し以外)
(2) メソッド呼び出し
(3) GC
(4) Cで実装されたライブラリでの処理
(5) lex, parse
etc.

rb2c では実行時に構文木の走査を行わない分(1)が早くなり、また(5)の分も
早くなります。が、(3)のGCや(4)に多くの時間がかかっていると殆んどrb2cを
使っても早くなりません。

またメソッド呼び出し処理については、メソッドの検索(束縛?)よりメソッド
呼び出しに伴うコンテキスト?更新の影響のほうが現状では大きいようです。

* Ruby でのメソッド呼び出し時の処理

1.メソッドの検索 (class, method id -> method body) ← これが束縛?
2.private, protected の check 
3.PUSH_ITER       ←これとか
4.PUSH_FRAME      ←これとか
5.関数呼び出し(rb2cの場合)
  1.PUSH_SCOPE    ←これとか
  2.PUSH_VARS     ←これとか
  3.PUSH_TAG      ←これ
  4.処理 

#これらのコンテキストを「整理またはチューンする」さらにrb2cの場合は「不
#要なものを削る」ことができれば、メソッド呼び出しを高速化できるだろうと
#考えてます。

#でも GC が早くなる方がきっと嬉しい…。
--
檜田和浩 <hiwada@kuee.kyoto-u.ac.jp>

In This Thread

Prev Next