Path: titcca!kogwy!fxvax!kiuchi From: kiuchi@s5g.ksp.fujixerox.co.jp (Yasuhiko Kiuchi) Newsgroups: fj.lang.lisp Subject: Re: CLOS performance. (In Japanese/Kanji) Message-ID: Date: 10 Mar 90 02:17:01 GMT References: <187@ognews1.osakagas.co.jp> <190@ognews1.osakagas.co.jp> Sender: news@fxvax.fujixerox.co.jp Distribution: fj Organization: Fuji Xerox Lines: 78 In-reply-to: yosikawa@ccs.mt.nec.junet's message of 8 Mar 90 01:10:42 GMT こんにちは、富士ゼロックスの木内です。 CLOSのパフォーマンス/defconstructorについての話しなどしたいと思います。 defconstructorは、PCLを使って動作するCLOSのいくつかのプログラムの動作 があまりにも遅いという苦情から、実際にいくつかの具体的なアプリケーショ ンでどこで時間がかかるか調べたところ、make-instanceが問題であることが わかり、作られたものです。 しかし、make-specializableなどと同様に、CLOSの標準ではありません。 defconstructorは、PCLで記述したCLOSのプログラムの高速化には、このまま では、残念ながら、やくにたちません。 この原因は、Common Lispの仕様には、コンパイラーオプティマイザーがない (もっと正確にいえば、ポータブルなオプティマイザーが処理系を作っていな い/作られていない)ためで、make-instanceの高速化には、処理系に依存した コードが必要になります。もしコンパイラーオプティマイザーがあれば、プロ グラムのなかのmake-instanceの使われかたを解析して、それに対応したコン ストラクターを作成して、コードはそれを呼び出すように することができます。 もちろん、いくつかのCommon Lisp処理系には、コンパイラーオプティマイザー が用意されていますので、この実験はできるのですが、まだやったことはあり ません。イメージがわかないかたのために、どんなものかXerox Lispの例(マ ニュアルに出ている例です)で説明しますSyntaxは、defmacroに似ています。 EQのArgumentのどちらかがnilだったら最適化する例: (xcl:defoptimizer eq eq-nil-check (&whole form) (cond ((eq nil (second form)) `(not ,(third form))) ((eq nil (third form)) `(not ,(second form))) (t form))) (xcl:defoptimizer nth (n-form list-form) (if (and (typep n-form 'fixnum) (<= 0 n-form 10)) `(car ,(let ((cdr-form list-form)) (dotimes (i n-form cdr-form) (setq cdr-form `(cdr ,cdr-form))))) 'compiler:pass)) これは、nthの10番目までは、car/cdrに展開するという例です。 コンパイラーは、関数呼びだしのフォームをコンパイルするときに、オプティ マイザーで、argumentが&wholeになっていて、そのフォームを返すとき(eqの 例)や、特別のSymbol compiler:pass(じつは、Interlispとの互換性のために il:ignoremacroでもOKです)になったら、そのオプティマイザーは使用しませ ん。最適化がまったくされなかったら、通常のように関数が呼び出されるわけ です。ここに出したのは、説明のための例で、実際のシステムでは、もうちょっ と複雑です。 もちろん、eqの最適化などは、ほとんど全部のCommon Lispの処理系で行なわ れているわ けですが、たとえPCLで、make-instanceが遅くても、ちょいと処理系をいじれ ば、make-instanceに対して行なえば、カスタマイズ版のCLOSでは、まともな パフォーマンスを出すのは、システムに上のようなオプティマイザーがあれば、 結構簡単にできるはずですね。 そういうわけで、make-instanceの遅いのはPCLのせいじゃないということでし た。それから、ついでに、CLOSのパフォーマンスを話すときには、PCLのパフォー マンスをもとに議論するときは、このような問題を頭におかないと、まるで、 CLOS仕様のせいで高速な処理系は作成できないなどという誤解をまねきかねな いので、注意が必要です。 さて、話しはかわって、次にdefconstructorの話しですが、このコードは、 PCLのコードの中でも観賞に値するものです。2重のClosureを使っての最適化 のテクニックもその一つですが、初期化関係のものが再定義されると、自動的 にもとの外側のclosureに戻る点、自分でつくったmeta-classにもコンストラ クターを作れる枠組になっている点などがあげられます。 また、最適化のケースなども増やしたり減らしたりして実験ができますので、 LispによるシステムプログラミングやPCLのインプリメンテーションのメカニ ズムなどに興味のあるかたは、遊んでみてください。PCLで動くアプリケーショ ンのデモなどにdefconstructorを使ってみるとよいのではないでしょうか。 木内康彦(Fuji Xerox STDC) Kiuchi.pa@Xerox.com or kiuchi@s5g.ksp.fujixerox.co.jp Kiuchi:KSPA:Fuji Xerox (Xerox CIN)