[#9445] thread.rb — m_seki@...

18 messages 2000/03/16
[#9446] Re: thread.rb — matz@... (Yukihiro Matsumoto) 2000/03/17

[#9460] Re: thread.rb — m_seki@... 2000/03/21

[#9462] Re: thread.rb — matz@... (Yukihiro Matsumoto) 2000/03/21

まつもと ゆきひろです

[#11281] Re: thread.rb — Masatoshi SEKI <m_seki@...> 2000/10/22

[#9498] timeout しない timeout — ARIMA Yasuhiro <fit0298@...>

有馬です。

20 messages 2000/03/26
[#9506] Re: timeout しない timeout — matz@... (Yukihiro Matsumoto) 2000/03/27

まつもと ゆきひろです

[#9509] Re: timeout しない timeout — gotoken@... (GOTO Kentaro) 2000/03/27

In message "[ruby-dev:9506] Re: timeout しない timeout"

[ruby-dev:9411] idea: static ruby optimizer

From: Minero Aoki <aamine@...>
Date: 2000-03-08 11:33:34 UTC
List: ruby-dev #9411
あおきです。

Subject 通りアイデアだけです。
(自分では実装しそうにないので ^^;;)

前にまつもとさんが「Ruby は動的な言語なので最適化は難しい」と
おっしゃっていたと思うんですが、最近これを逆手にとって
「じゃあ、動的じゃなくしちゃえば高速化できるんでない?」という
着想に至りました。が、当然そのまま静的にしてしまうとなんにも
いいところはないので、それをミックスして使います。すなわち、

  1  最初はいままで通りの Ruby が動く。
  2  ある一点を境に、eval 系の実行及びメソッドの追加、変更を禁止する。
  3  オプティマイザに動作が移り、最適化を行う。
  4  動作再開

最初は動的で、その後静的になるというところがポイントです。
これは、実際のプログラムでは、メタ機能を使う部分は
クラスの初期化の時点に集中しているという仮定に基いています。
(実際、ぼくの作ったのはほとんどそうです。)

3 の段階で完全に最適化してしまおうと思うとその部分でかなり
時間がかかってしまいそうですが、たとえばサーバーのように、
fork で数が増えるアプリケーションではそれでも有効そうです。

また、全部を一気に最適化してしまうのではなく、コードが到達したときに
最適化する Just In Time Optimizer というのも考えられます。
大規模な最適化はオーバーヘッドがかかりすぎるにしても、たとえば
クラスのメソッド表をフラットにしてしまう(できれば完全ハッシュに)
だけでもメソッド探索のコストは結構下がりそうです。


というアイデアなんですが、みなさんどう思われますか?
-------------------------------------------------------------------
あおきみねろう

In This Thread

Prev Next