From: SASADA Koichi <ko1@...>
Date: 2008-04-13T02:46:51+09:00
Subject: [ruby-dev:34370] Re: ComplexFloat

　ささだです．

Tanaka Akira wrote:
>> ComplexFloat が組み込みで提供されていれば，ComplexFloat が生成される
>> ポイントは (関数の上書きがされていない条件下で) 確定するはずです．さらに，
>> ComplexFloat を伴う演算も組み込みのものは事前に知っているわけですから，
>> ComplexFloat が絡む演算の流れをコンパイラが追うことは可能だと思います．
>> FIxnum，Bignum，Rational，そして Float の演算も同様の方法で最適化可能
>> だと思います．
> 
> YARV は関数の上書きが行われる可能性があるという前提で実装さ
> れていますが、どういうふうに変えるんでしょう?
> 
> 関数の上書きが起きた時点で遅い (上書きが起きても正しく動作す
> る) 実装に遷移するんでしょうか?
> それとも、関数の上書きを禁止するんでしょうか?
> 
> 前者だとしたら、その実装はそう簡単なものではないと思うんです
> が、誰がいつ実装するんですか?

　いくつか案はありますが，メソッドをまたいだ型の伝搬の解析は，Rubyで
はそんなに簡単にはいきません．この辺はもっと詳しい人が居そうですね．

　脱最適化の仕組みをきちんと実装すれば，この辺の話は飛躍的にいろいろ
と進みそうです．ただし，すぐに出来るような簡単な話ではないことは確か
です．簡単だったらどうしよう．

> 後者だとしたら... もし提案が通れば、ささださんは喜びそうです
> ね。

　逆に，通るとこれまでの苦労が...．


　この辺の話は，実際に証拠を突きつけて

・ほら，こうやると速いでしょう
・この方式じゃこんなに遅くなりますよ
・このアプリケーションではこんなに (困る|助かる) でしょう

などというと，説得力が増すんじゃないかと思います．「多分，その方法
じゃ遅くなるから」だと，どれくらい遅くなり，どんなケースで困るのかわ
からないので，説得力があまりないかもしれません．ちょっとした，簡単な
実験でもあると，説得力がぐっと増すと思います．

-- 
// SASADA Koichi at atdot dot net