From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: byte-code optimizations Date: Tue, 21 Sep 2004 17:05:30 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200409181152.15364.pogonyshev@gmx.net> <200409191412.50820.pogonyshev@gmx.net> <200409212242.47848.pogonyshev@gmx.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1095800770 10702 80.91.229.6 (21 Sep 2004 21:06:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 21 Sep 2004 21:06:10 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 21 23:05:56 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C9rpk-00064R-00 for ; Tue, 21 Sep 2004 23:05:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9rvg-0003TT-HM for ged-emacs-devel@m.gmane.org; Tue, 21 Sep 2004 17:12:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C9rvZ-0003TH-2o for emacs-devel@gnu.org; Tue, 21 Sep 2004 17:11:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C9rvX-0003Sn-NK for emacs-devel@gnu.org; Tue, 21 Sep 2004 17:11:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9rvX-0003SY-En for emacs-devel@gnu.org; Tue, 21 Sep 2004 17:11:55 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C9rpU-0004I9-6j; Tue, 21 Sep 2004 17:05:40 -0400 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 26C0FB3027B; Tue, 21 Sep 2004 17:05:31 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id EADCF8CA23; Tue, 21 Sep 2004 17:05:30 -0400 (EDT) Original-To: Paul Pogonyshev In-Reply-To: <200409212242.47848.pogonyshev@gmx.net> (Paul Pogonyshev's message of "Tue, 21 Sep 2004 22:42:47 -0200") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 5) X-MailScanner-From: monnier@iro.umontreal.ca X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27397 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27397 >> Unless I have missed some point here, I think your version of the >> optimization is the better of the two (all else being equal), because >> it gets directly to the desired result instead of requiring it to be >> done in two steps. > It must also be much simpler (though I never saw what Stefan had). Yes, it's much simpler. Also my code can break on some bytecode. More specifically, my code requires that the specpdl stack be unique for any given point in the byte-code, which is not the case for example if the bytecode does the equivalent of if cond varbind X endif ...blabla... if cond unbind 1 endif AFAIK, my code works for any bytecode coming out of the current bytecode compiler (barring bugs), but it might break with some other bytecode compiler. >> However, there is still the question of whether we should >> change the standard defsubst to work the way defsubst* does. > Maybe we can even use `defmacro' for `caar' and friends. Since > they evaluate their lone argument only once, there must not be > any problems, right? Just think of (mapcar 'caar x) > If this (or `defsubst*') works, I'll investigate whether this > byte-code optimization gives any improvement after such a change. What defsubst* does is treat the argument as a kind of "lexically scoped" variable, but only in very limited ways. I.e. the (defsubst* caar (x) (car (car x))) will expand: (caar y) => (car (car y)) (caar (f y)) => (let ((x (f y))) ..cl-gunk.. (car (car x))) [ The cl-gunk is stuff added by CL for CL such as a `catch' statement. ] If you ignore the nasty cl-gunk, I think the resulting optimization is similar to what we get, except it works in a few more cases. E.g. it'll expand (defsubst* foo (x) (symbol-value x)) (foo y) => (symbol-value y) whereas our optimization won't be able to do that because it can't assume a "somewhat lexically scoped" semantics. Stefan