From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Emacs Lisp, macros Date: Fri, 24 Jul 2009 00:14:16 +0200 Message-ID: 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 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1248387305 15351 80.91.229.12 (23 Jul 2009 22:15:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jul 2009 22:15:05 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Daniel Kraft Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 24 00:14:58 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 1MU6Z0-00014J-FH for guile-devel@m.gmane.org; Fri, 24 Jul 2009 00:14:58 +0200 Original-Received: from localhost ([127.0.0.1]:33946 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU6Yz-0003GK-R9 for guile-devel@m.gmane.org; Thu, 23 Jul 2009 18:14:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MU6Yw-0003G0-Q1 for guile-devel@gnu.org; Thu, 23 Jul 2009 18:14:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MU6Yr-0003Eu-3w for guile-devel@gnu.org; Thu, 23 Jul 2009 18:14:53 -0400 Original-Received: from [199.232.76.173] (port=47204 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU6Yq-0003Eo-WB for guile-devel@gnu.org; Thu, 23 Jul 2009 18:14:49 -0400 Original-Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:34072 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MU6Yk-0005A0-Rt; Thu, 23 Jul 2009 18:14:43 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 8ED9C113C0; Thu, 23 Jul 2009 18:14:42 -0400 (EDT) Original-Received: from unquote (unknown [81.38.186.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 96755113BC; Thu, 23 Jul 2009 18:14:39 -0400 (EDT) In-Reply-To: <4A5D94F3.9050507@domob.eu> (Daniel Kraft's message of "Wed, 15 Jul 2009 10:36:03 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 38B43190-77D6-11DE-99F8-F699A5B33865-02397024!a-sasl-quonix.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) 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:8947 Archived-At: On Wed 15 Jul 2009 10:36, Daniel Kraft writes: > Ludovic Court=C3=A8s wrote: >>> as well as found a (hopefully good) solution to automatically create >>> fluids not yet present on reference.=20 >> >> 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. 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. > 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)) I wouldn't bother, to be honest. dynamic-ref will be plenty fast, and a has to be on the heap anyway, unless the compiler does a lot more analysis than it currently does. > 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. Yes :) Peace, Andy --=20 http://wingolog.org/