From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: goops and memoization Date: Wed, 20 Nov 2002 22:11:31 -0500 Sender: guile-devel-admin@gnu.org Message-ID: References: Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037848457 18144 80.91.224.249 (21 Nov 2002 03:14:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 21 Nov 2002 03:14:17 +0000 (UTC) Cc: Neil Jerram , guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18Ehn9-0004hz-00 for ; Thu, 21 Nov 2002 04:14:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Eho9-0007af-00; Wed, 20 Nov 2002 22:15:14 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18Ehnq-0007Kg-00 for guile-devel@gnu.org; Wed, 20 Nov 2002 22:14:54 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18Ehnk-0007Dp-00 for guile-devel@gnu.org; Wed, 20 Nov 2002 22:14:52 -0500 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Ehnj-0007Cz-00 for guile-devel@gnu.org; Wed, 20 Nov 2002 22:14:47 -0500 Original-Received: from linnaeus ([18.42.2.46]) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 18Ehkc-0002hj-00; Thu, 21 Nov 2002 04:11:34 +0100 Original-Received: from mdj by linnaeus with local (Exim 3.36 #1 (Debian)) id 18Ehka-00055C-00; Wed, 20 Nov 2002 22:11:32 -0500 Original-To: Dirk Herrmann Original-Cc: djurfeldt@nada.kth.se In-Reply-To: (Dirk Herrmann's message of "Wed, 20 Nov 2002 19:11:20 +0100 (CET)") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1732 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1732 First a disclaimer: I added GOOPS to Guile because I needed an object system in my neural simulator. I did not have infinite time to code, but I tried to focus on at least getting the user-level definition reasonable so that we would not build ourselves into a corner. I looked at many different kinds of object systems when arriving at the current GOOPS. That said, quite a lot of the code was developed during a few days a certain Christmas, and parts of compile.scm was written on Arlanda airport while waiting for boarding an aircraft. I urgently needed someting working and planned to rewrite it later. Well, later I judged it would serve people better to add the code to the Guile source tree than letting people wait infinitely until my rewrite would get high enough priority. I then tried to get volunteers to rewrite the code in C. While there are "dark corners" in GOOPS I still dare to claim that it works on sound principles, works reliably and is probably one of the most efficient Scheme object systems. Benchmarks show that GOOPS method dispatch is negligible and a GOOPS generic function nearly as efficient as an ordinary closure. Dirk Herrmann writes: > This conflicts with goops: goops unmemoizes the function code, using > 'procedure-source' (look into oop/goops/compile.scm). This will re-create > the original code, including all the symbols that refer to local > variables. This un-memoized code is then optimized in some way, and > re-written into the closure object. Then, if the closure is evaluated, it > is not run through the memoizer again (since it is already a closure). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just a note: This is something which holds *after* your change, not previously. > Now, if the executor runs over a symbol corresponding to a local variable, > it will treat is as a symbol belonging to a global variable and try to > find it within the module. I'm sure Neil would find his way in the code, but since the answer seems obvious to me because of my previous knowledge, I'll give some hints: A few notes on GOOPS method dispatch: As in most CLOS-like systems, GOOPS method dispatch is quite advanced. For example, a generic function application involves sorting the applicable methods after specificity. We might in fact like to make it even more advanced (adding support for singletons and type coercion for example). To get GOOPS fast, we cache the results of this involved process in a "method cache" in the generic function. Next time a GF is applied to the same set of argument types, the evaluator just makes a quick lookup in the cache and can start to evaluate the method body without delay. The format of the method cache is described in oop/goops/dispatch.scm. The procedure compile-method in oop/goops/compile.scm takes the sorted list of applicable methods and a list of the argument types in the GF application and returns a "cmethod", which is the tail of a method cache entry: CMETHOD ::= (CLOSURE-ENVIRONMENT FORMALS BODY-FORM1 ...) Currently, compile-method only makes sure the method has a local next-method binding (specific to this method cache entry) if that is needed. However, there are plans to let it make powerful optimizations of the code, with great potential of reducing overhead. It seems to me that what you need to do is to run the tail of the cmethod (BODY-FORM1 ...) through your memoizer. That should fix it. In fact, as you see above, a cmethod contains the same information as a closure. Mikael _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel