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: 13 Apr 2004 17:56:48 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87wu4jrf3j.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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1081875645 18368 80.91.224.253 (13 Apr 2004 17:00:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2004 17:00:45 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Apr 13 19:00:34 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 1BDRH0-0004CA-00 for ; Tue, 13 Apr 2004 19:00:34 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BDRGz-00035M-00 for ; Tue, 13 Apr 2004 19:00:34 +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 1BDRF6-0005z3-H4 for emacs-devel@quimby.gnus.org; Tue, 13 Apr 2004 12:58:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BDRDy-0005j2-DP for emacs-devel@gnu.org; Tue, 13 Apr 2004 12:57:26 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BDRDR-0005Y8-Et for emacs-devel@gnu.org; Tue, 13 Apr 2004 12:57:24 -0400 Original-Received: from [217.158.120.143] (helo=mail.ukfsn.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDRDQ-0005XI-Sf; Tue, 13 Apr 2004 12:56:53 -0400 Original-Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 2E53AE6E56; Tue, 13 Apr 2004 17:54:15 +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 26753-12; Tue, 13 Apr 2004 17:54:15 +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 C8485E6DFC; Tue, 13 Apr 2004 17:54:14 +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 1BDRDO-0000GS-00; Tue, 13 Apr 2004 17:56:50 +0100 Original-To: Stefan Monnier Original-Lines: 33 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:21574 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21574 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.