From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Matthew Mundell Newsgroups: gmane.emacs.devel Subject: Re: Compilation to native Date: 16 Apr 2004 15:20:47 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87pta8dmww.fsf@sno.mundell.ukfsn.org> References: <87eks0654s.fsf@sno.mundell.ukfsn.org> <87n06bp4ng.fsf@sno.mundell.ukfsn.org> <877jxccutf.fsf@sno.mundell.ukfsn.org> <87k712gesk.fsf@sno.mundell.ukfsn.org> <87k70lhrsq.fsf@sno.mundell.ukfsn.org> <87wu4jrf3j.fsf@sno.mundell.ukfsn.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1082125685 10219 80.91.224.253 (16 Apr 2004 14:28:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Apr 2004 14:28:05 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 16 16:27:39 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BEUJe-0001Ug-00 for ; Fri, 16 Apr 2004 16:27:38 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BEUJe-0006nQ-00 for ; Fri, 16 Apr 2004 16:27:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BEUHP-0005wR-SI for emacs-devel@quimby.gnus.org; Fri, 16 Apr 2004 10:25:19 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BEUGx-0005kb-IX for emacs-devel@gnu.org; Fri, 16 Apr 2004 10:24:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BEUGO-0005WF-Mk for emacs-devel@gnu.org; Fri, 16 Apr 2004 10:24:49 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1BEUGN-0005Uj-NE; Fri, 16 Apr 2004 10:24:15 -0400 Original-Received: from [217.158.120.143] (helo=mail.ukfsn.org) by mx20.gnu.org with esmtp (Exim 4.30) id 1BEUD3-0000kp-Rk; Fri, 16 Apr 2004 10:20:49 -0400 Original-Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id BBCB0E6E0B; Fri, 16 Apr 2004 15:17:54 +0100 (BST) Original-Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22098-18; Fri, 16 Apr 2004 15:17:54 +0100 (BST) Original-Received: from sno.mundell.ukfsn.org (dsl213-218-238-16.as15444.net [213.218.238.16]) by mail.ukfsn.org (Postfix) with ESMTP id 72836E6DEE; Fri, 16 Apr 2004 15:17:54 +0100 (BST) Original-Received: from sno.mundell.ukfsn.org ([10.0.0.3]) by sno.mundell.ukfsn.org with esmtp (Exim 3.36 #1 (Debian)) id 1BEUD1-0000oi-00; Fri, 16 Apr 2004 15:20:47 +0100 Original-To: Stefan Monnier Original-Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21768 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21768 Matthew Mundell writes: > Stefan Monnier writes: > > > > This optimisation more than doubles the speed of the generated > > > function. The optimisation adds two new byte operations. As a start > > > the new operations always take parameters that are four bytes wide. I > > > think the loading of these four bytes is the cause of the slower byte > > > interpretation. > > > > I don't understand. Could you give us more info about what those new byte > > ops are and what they're used for (and maybe why you think they make things > > slower in the byte-interpreter, tho I should be able to figure that out on > > my own at that point). > > The optimisation moves variable referencing and setting out of loops. > The Lisp objects are instead referenced onto the stack before the > loop, and set from the stack afterwards. The new operations are used > inside the loop to access or set an object on the stack. The > operations both take a parameter which indicates how far below the top > of the stack the object is. The parameter is the four bytes in the > byte stream which follow the operation byte code. In the byte > interpreter this means four more loads for each reference and for each > set, on every iteration of the optimised example. I think this is the > cause of the 3 extra seconds in the interpretation of the optimised > byte code. > > The purpose of doing the optimisation was to speed up the native code > generated for the test example. Always using four bytes was the > quickest way to do it. Now that it is done I'll try for a better > parameter mechanism. A possibility is to do it like the varset and > varref operations where the operation byte code identifies the number > of parameter bytes to follow. I'm guessing that afterwards the byte > interpretation of the test example will be at most a few seconds > faster than before the optimisation. It'll be interesting to see. Using varset-like op code parameters for the stkset and stkref operations makes the byte interpretation of the optimised example a second faster than usual. So the loading of the four bytes was the cause of the extra 3 seconds.