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: Wed, 15 Jul 2009 10:36:03 +0200 Message-ID: <4A5D94F3.9050507@domob.eu> References: <4A5CE0F9.4080904@domob.eu> <874ote3o8v.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1247647084 27864 80.91.229.12 (15 Jul 2009 08:38:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jul 2009 08:38:04 +0000 (UTC) Cc: guile-devel@gnu.org To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jul 15 10:37:57 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 1MQzzx-0002mF-8V for guile-devel@m.gmane.org; Wed, 15 Jul 2009 10:37:57 +0200 Original-Received: from localhost ([127.0.0.1]:45321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQzzw-0003FX-HX for guile-devel@m.gmane.org; Wed, 15 Jul 2009 04:37:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQzxp-0002ID-Qi for guile-devel@gnu.org; Wed, 15 Jul 2009 04:35:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQzxl-0002GP-Me for guile-devel@gnu.org; Wed, 15 Jul 2009 04:35:45 -0400 Original-Received: from [199.232.76.173] (port=59960 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQzxl-0002GE-Fl for guile-devel@gnu.org; Wed, 15 Jul 2009 04:35:41 -0400 Original-Received: from tatiana.utanet.at ([213.90.36.46]:47467) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MQzxh-0008UZ-NQ; Wed, 15 Jul 2009 04:35:38 -0400 Original-Received: from pam.xoc.tele2net.at ([213.90.36.6]) by tatiana.utanet.at with esmtp (Exim 4.69) (envelope-from ) id 1MQzxe-0000cT-Ru; Wed, 15 Jul 2009 10:35:34 +0200 Original-Received: from d86-33-197-124.cust.tele2.at ([86.33.197.124] helo=[192.168.1.18]) by pam.xoc.tele2net.at with esmtpa (Exim 4.69) (envelope-from ) id 1MQzxe-0001IW-Mz; Wed, 15 Jul 2009 10:35:34 +0200 User-Agent: Thunderbird 2.0.0.0 (X11/20070425) In-Reply-To: <874ote3o8v.fsf@gnu.org> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:8877 Archived-At: Ludovic Courtès wrote: >> as well as found a (hopefully good) solution to automatically create >> fluids not yet present on reference. > > Is each Elisp variable mapped to a fluid? Eventually, you may need VM > instructions for fluid-{ref,set!}, to speed things up. Yes it is; and I agree that variable references surely have terrible performance at the moment, because of other things that have to go on for each reference: * see if there's a fluid with that name; create if not (but creation is only done once of course, so the performance hit is from the check only) * reference the fluid to get the current value * check if the value is the special elisp void, in which case an error is reported So taking this all together, I think there's a lot of potential for optimization here! Unfortunatly I think that all this is necessary to ensure the semantics, but two ideas: 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. 2) I already mentioned some ideas like that before, but if we do careful analysis of the elisp code, we can probably get rid of some fluid-references; for instance: (let ((a 5)) (setq a 1) (while ... something which references a a lot) (foobar 1 2 3)) In order to preserve dynamic scoping for a in the call to foobar, we still have to save a in a fluid as well as do the setq on the fluid value. But all references to a within the while-loop (if they are reads) are known to refer to the let-bound a, so we could optimize them and not take a fluid-ref every now and then. I think, however, that this can get fairly complicated and need a lot of tweeking in order to get a sensible optimization. So for now I think we should try getting the real bottle-necks into VM opterations and see what that can buy. > There's 1.5 framework. The first one is under `test-suite/tests', used > to test the API. The remaining 0.5 is under `testsuite': it's inherited > from Guile-VM and is used to make sure interpreted and compiled code > yield the same result. > > I think the best way would be to add, say, > `test-suite/tests/elisp-compiler.test' (there's already `elisp.test'), > and from there use a macro akin to Andy's `c&e' in `bytevectors.test'. Ok thanks for the hint! So far I did mainly look into testsuite, but then I'll take a look at the framework in test-suite and see if I can do something useful there :) cheers, Daniel