From: SASADA Koichi <ko1 atdot.net>
Subject: [yarv-dev:504] Gauche:LazyCompilation
Date: Thu, 09 Jun 2005 14:27:42 +0900

> Gauche:LazyCompilation
> http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Gauche%3aLazyCompilation
> 
> 　を見ていたんですが、多分コンパイル時間が問題になるのはライ
> ブラリなどの、膨大で、しかもめったに変更がないものばかりでは
> ないかと思うのですが、どうでしょうか。
> 
> 　で、どうせめったに変更しないんだったら、pre-compile してお
> くというのはどうでしょうか。

srfi-1みたいに、もうほとんどいつも使うよ、ってなやつは、いずれ
pre-compileにしようと思っています (今の構成だと、pre-compile
したものはdlopenされる拡張ライブラリになります)。

でも一般的なライブラリに関しては、ソース形式とpre-compile
された形式の両方がインストールされると管理上まぎらわしいんですよね。
特にサードパーティのライブラリが増えてきて、しかも複数のディレクトリに
ライブラリパスを通してたりすると、こっちのソースを見てるつもりだったのが
あっちのプリコンパイルされたライブラリをロードしてた、とか。

(ちなみに、例えば社内製作のプロダクションパイプライン用ライブラリ
とかだと、結構頻繁に更新されたりします)。

アーキテクチャ非依存の形式にコンパイル結果をdumpするようにして、
Emacs Lispみたいにインストールされたソースと並べて置いとくように
すれば多少はましですが、それでもdump形式が変わった時にリコンパイルを
忘れていつしかソースの方しか使われなくなっているのに気づかなかった、とか。

まあ、根本的には「情報は一ヶ所に置く」原則が崩れるのが気持ち悪い
のかなあ。

コンパイル時間の増大がどうにもならなくなったら何か考えると思います。

> 　LazyCompilation とかをするなら、もっとごつい最適化をプロファ
> イラを走らせといてホットスポットのみに適用のほうがいいんじゃな
> いかと思いました。

速くする目的によると思うんですよねー。言語実装者的にはVMをいじる楽し
さってのはあるんですが、Gaucheユーザから見た場合、例えば「もっと
速いのが欲しかったら最適化オプションmaxにしてバッチコンパイルしてね、
そしたら型推論してグローバルフロー解析してC経由でネイティブコードに
するから」という方法以上のメリットを提示できるのかどうか。

実行時最適化は諸刃の剣で、プログラムの動作がある意味非決定的になる
(1回目とn回目で実行されるコードが異なる)とも言えるんで、
信頼性確保がものすごく難しくなりそうな気がします。大企業で
たくさんのスタッフを抱えてやるならともかく、少人数で開発する場合は
大変そう。

--shiro








--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml