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: Elisp performance Date: Tue, 04 Aug 2009 12:17:29 +0200 Message-ID: References: <4A7045AC.10407@domob.eu> <87ocr1yle9.fsf@arudy.ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1249381626 24436 80.91.229.12 (4 Aug 2009 10:27:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Aug 2009 10:27:06 +0000 (UTC) Cc: Daniel Kraft , guile-devel To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Aug 04 12:26:59 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 1MYHEO-0003lH-JY for guile-devel@m.gmane.org; Tue, 04 Aug 2009 12:26:57 +0200 Original-Received: from localhost ([127.0.0.1]:57801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MYHEN-0007gZ-Sd for guile-devel@m.gmane.org; Tue, 04 Aug 2009 06:26:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MYHED-0007eZ-J2 for guile-devel@gnu.org; Tue, 04 Aug 2009 06:26:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MYHE9-0007bV-H9 for guile-devel@gnu.org; Tue, 04 Aug 2009 06:26:45 -0400 Original-Received: from [199.232.76.173] (port=33480 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MYHE9-0007bB-9G for guile-devel@gnu.org; Tue, 04 Aug 2009 06:26:41 -0400 Original-Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:63915 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MYHE7-000272-No for guile-devel@gnu.org; Tue, 04 Aug 2009 06:26:40 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 8A5DE20607; Tue, 4 Aug 2009 06:26:37 -0400 (EDT) Original-Received: from unquote (unknown [82.123.246.238]) (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 D249B20606; Tue, 4 Aug 2009 06:26:33 -0400 (EDT) In-Reply-To: <87ocr1yle9.fsf@arudy.ossau.uklinux.net> (Neil Jerram's message of "Thu, 30 Jul 2009 21:18:54 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 4A9DBEB2-80E1-11DE-A9A2-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:9013 Archived-At: Hello! (Was away for the weekend, but back hacking all week now.) On Thu 30 Jul 2009 22:18, Neil Jerram writes: > Daniel Kraft writes: > >> Lambda arguments are still always dynamically bound, which is quite a >> pity as it inhibits tail-call optimization; Indeed, a pity. Though self-tail calls can be optimized... still, irritating. > This prompted me to wonder if using fluids is the best way to > implement dynamic binding. > > Perhaps I'm forgetting something basic, but surely it's using > `dynamic-wind' that gives us dynamic binding semantics, not fluids. I haven't read the rest of this thread yet, but this does not seem to be related to TCO. The middle thunk of a dynamic-wind is *not* called in a tail context, as indeed it does have a continuation -- the exit thunk. > The main thing I believe that makes a fluid different from a normal > variable is that a fluid can have a different value in each thread - > which is not relevant to Elisp. True. Of course, it would be a nice thing to give to elisp -- I mean, currently in Emacs variables have one value per thread as well, it's just that there's only one thread. So if we give Emacs the capability to run multiple threads (as we should IMO), we should provide thread-local values. >> My conjecture is that the remaining bottle-neck are the primitive >> calls, as they are still resolved using the dynamic-binding and fluid >> mechanisms; so maybe it is really a good idea to change function >> bindings to just global ones without dynamic scoping, and implement >> flet/flet* with dynamic-wind. In contrast to variables, for functions >> access performance is a lot more important than let performance, I >> guess, so this might be the way to go. What do you think? > > See above. I'm not sure why fluid access should be significantly > slower than non-fluid access, so I would guess that the performance > cost is coming from the dynamic-wind part. Yes, dynamic-wind does involve a cons. I wish this weren't the case, and perhaps in the future we can fix this, but that's the way it is now. But regarding speed: profiling is your friend. http://article.gmane.org/gmane.lisp.guile.devel/6639, for example. Cheers, Andy -- http://wingolog.org/