From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Kraft Newsgroups: gmane.lisp.guile.devel Subject: Re: Emacs Lisp, macros Date: Fri, 24 Jul 2009 09:00:26 +0200 Message-ID: <4A695C0A.6060708@domob.eu> References: <4A5CE0F9.4080904@domob.eu> <874ote3o8v.fsf@gnu.org> <4A5D94F3.9050507@domob.eu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248418823 13089 80.91.229.12 (24 Jul 2009 07:00:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jul 2009 07:00:23 +0000 (UTC) Cc: =?UTF-8?B?THVkb3ZpYyBDb3VydMOocw==?= , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 24 09:00:15 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MUElH-0005il-N6 for guile-devel@m.gmane.org; Fri, 24 Jul 2009 09:00:12 +0200 Original-Received: from localhost ([127.0.0.1]:39330 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUElH-00071y-0d for guile-devel@m.gmane.org; Fri, 24 Jul 2009 03:00:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MUElD-00071s-OQ for guile-devel@gnu.org; Fri, 24 Jul 2009 03:00:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MUEl8-00070G-Lj for guile-devel@gnu.org; Fri, 24 Jul 2009 03:00:06 -0400 Original-Received: from [199.232.76.173] (port=42238 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUEl8-0006zu-Gf for guile-devel@gnu.org; Fri, 24 Jul 2009 03:00:02 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:35416) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MUEl5-0008Jc-Sr; Fri, 24 Jul 2009 03:00:00 -0400 Original-Received: from tatiana.utanet.at ([213.90.36.46]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MUEl4-0000yA-NE; Fri, 24 Jul 2009 02:59:59 -0400 Original-Received: from paris.xoc.tele2net.at ([213.90.36.7]) by tatiana.utanet.at with esmtp (Exim 4.69) (envelope-from ) id 1MUEl2-0003SJ-Fy; Fri, 24 Jul 2009 08:59:56 +0200 Original-Received: from d83-187-186-129.cust.tele2.at ([83.187.186.129] helo=[192.168.1.18]) by paris.xoc.tele2net.at with esmtpa (Exim 4.69) (envelope-from ) id 1MUEl2-0003MX-Ar; Fri, 24 Jul 2009 08:59:56 +0200 User-Agent: Thunderbird 2.0.0.0 (X11/20070425) In-Reply-To: X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8959 Archived-At: Andy Wingo wrote: >> 1) As you suggested, try doing some parts of this with new VM >> operations. Like all of these in one op, or maybe just a "reference and >> error on void" as one op, and/or "lookup the variable in some module, >> and create it if not there" as another. I think we need some planning >> to get the right choice, but it certainly is an important thing for >> performance. But for now I'd suggest to keep on with the current >> implementation and later see what the real performance bottle-neck is >> when running real-world code. > > So, agreed wrt perspective on when to optimize. I still think that we > should be able to cache fluid locations in the same way that Scheme > caches variable locations, and add dynamic-ref / dynamic-set analogs to > toplevel-ref / toplevel-set. See their implementations for details on > what I mean. You mean, (dynamic-ref fluid) equvialent to (fluid-ref fluid) but just VM optimized, and the same for dynamic-set!? Sounds nice! Well, just some notes about variable references and performance; there are still those three things that have to be done I mentioned already some time before (for setting a variable, 1) and 2) will be relevant): 1) Make sure the fluid itself is there for each variable needed and create a new one if not. I did this once on every access, but now I'm scanning each compiled expression for variable references and ensure all fluids for them beforehand, so that this is only done once per compiled expression and not, say, on each iteration in a loop. This brought runtime for one test down from 2.8s to 0.1s... This pretty amazed me, and I think the current solution is quite ok. 2) Reference the fluid. This is what we could do with VM operations, but I've not yet done tests to find out how much time this really costs compared to 3). 3) Check if value is void and error if it is. Maybe we could also do this in a VM operation (and then it would probably cost nearly nothing at all?), but I think that maybe just optionally getting rid of this test at all (see my remark about compiler options) is the better solution. When I've implemented the options to disable 2) and/or 3), I'll do some timings and let you know about that. Then we can decide if VM ops for the fluids are worth it and how much we can gain by them. Daniel -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri