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: expansion, memoization, and evaluation... Date: Wed, 04 Dec 2002 22:47:34 +0100 Sender: guile-devel-admin@gnu.org Message-ID: References: <87r8cyh5ec.fsf@raven.i.defaultvalue.org> <87heduh43b.fsf@raven.i.defaultvalue.org> <8765uah1fe.fsf@raven.i.defaultvalue.org> <878yz5fq1l.fsf@raven.i.defaultvalue.org> 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 1039039027 17863 80.91.224.249 (4 Dec 2002 21:57:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2002 21:57:07 +0000 (UTC) Cc: djurfeldt@nada.kth.se, Dirk Herrmann , 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 18JhVt-0004dL-00 for ; Wed, 04 Dec 2002 22:57:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JhUB-0000fT-00; Wed, 04 Dec 2002 16:55:15 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18JhTG-0007DV-00 for guile-devel@gnu.org; Wed, 04 Dec 2002 16:54:18 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18JhTA-0007Cy-00 for guile-devel@gnu.org; Wed, 04 Dec 2002 16:54:17 -0500 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JhTA-0007Ba-00 for guile-devel@gnu.org; Wed, 04 Dec 2002 16:54:12 -0500 Original-Received: from barbara.blakulla.net ([213.212.21.238] helo=linnaeus) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 18JhMk-0004iW-00; Wed, 04 Dec 2002 22:47:34 +0100 Original-Received: from mdj by linnaeus with local (Exim 3.36 #1 (Debian)) id 18JhMk-0004C1-00; Wed, 04 Dec 2002 22:47:34 +0100 Original-To: Rob Browning Original-Cc: djurfeldt@nada.kth.se In-Reply-To: <878yz5fq1l.fsf@raven.i.defaultvalue.org> (Rob Browning's message of "Wed, 04 Dec 2002 15:11:02 -0600") 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:1803 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1803 Rob Browning writes: > OK, so does that mean that at each invocation, you need to look at the > incoming types and check to see if you already have a cached method > that matches the incoming signature? i.e. if you have > > (blah) > (foo bar baz) > (blarg) > > and foo is a generic function, and last time through, bar and baz were > integers, but this time bar and baz are strings. Would the current > behavior be for goops to check, notice this, and build a new > "precompiled" invocation for two strings? Yes. > For example, if you know that within a given function (or closed set > of functions) you use some set of symbols, and within the set you > have big (case foo ...) statements using those symbols, you may be > able to compile the object code to use plain integers to represent > these symbols and then issue c-style switches to handle the case > statements. Yes, a wonderful optimization. :-) And if the compiler gets source back from the goops optimizer or does flow analysis, it may know the types of some arguments and some expressions in the source, and might be able to use native integer or double representation. In this context it's nice that a goops "cmethod" (the result of compile-method) has a fixed type signature. > (Of course if the guile compiler were implemented targeting C, and if > guile were to "Depends: gcc", we might be able to use dlopen/dlsym to > support heavyweight online compilation. Yes, yes, yes! > Though first-time execution would be awfully painful unless your > machine was really fast ;>) I wouldn't be so sure. Of course we wouldn't get "real-time" performance but I think the performance of the current goops is promising considering what *it* does for each "first" invocation: Traversing and rewriting the entire method source and rebuilding the entire GF method cache up to eight times... and all of it done on the Scheme level. Maybe I shouldn't reveal this :), but I've seen the current goops as a large-scale experiment to test whether these crazy ideas really work in practise. And they actually seem to. I've made heavy use of goops in large systems consisting of maybe 50 modules, and I don't have any complaints on its performance. Best regards, Mikael _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel