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: Compiling byte code to native Date: 02 Jun 2004 19:05:28 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87llj5vnrr.fsf@sno.mundell.ukfsn.org> References: <87u0xuuqvm.fsf@sno.mundell.ukfsn.org> <87pt8hvs6h.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 1086199554 31968 80.91.224.253 (2 Jun 2004 18:05:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 2 Jun 2004 18:05:54 +0000 (UTC) Cc: emacs-devel Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jun 02 20:05:36 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 1BVa7L-0001CQ-00 for ; Wed, 02 Jun 2004 20:05:35 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BVa7L-0006hr-00 for ; Wed, 02 Jun 2004 20:05:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BVa7e-0001uJ-0l for emacs-devel@quimby.gnus.org; Wed, 02 Jun 2004 14:05:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BVa7b-0001u6-6Q for emacs-devel@gnu.org; Wed, 02 Jun 2004 14:05:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BVa7a-0001tu-D7 for emacs-devel@gnu.org; Wed, 02 Jun 2004 14:05:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BVa7a-0001tr-Ac for emacs-devel@gnu.org; Wed, 02 Jun 2004 14:05:50 -0400 Original-Received: from [217.158.120.143] (helo=mail.ukfsn.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BVa7G-0000lt-Tl for emacs-devel@gnu.org; Wed, 02 Jun 2004 14:05:31 -0400 Original-Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id F1821E6D3C; Wed, 2 Jun 2004 19:04:14 +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 04871-13; Wed, 2 Jun 2004 19:04:14 +0100 (BST) Original-Received: from sno.mundell.ukfsn.org (dsl82-163-187-89.as15444.net [82.163.187.89]) by mail.ukfsn.org (Postfix) with ESMTP id 9FCFDE6A96; Wed, 2 Jun 2004 19:04: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 1BVa7E-0000LW-00; Wed, 02 Jun 2004 19:05:28 +0100 Original-To: Stefan Monnier In-Reply-To: Original-Lines: 28 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:24423 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24423 Stefan Monnier writes: > >> Maybe the results would be a bit more encouraging if you tried to compile > >> lexbind byte-code (where local variables are kept on the byte-code stack > >> rather than being varbound&varref'd). > > > This would be quite similar to compiling to a primitive, where the > > arguments will have to be lexically scoped. It may show an > > improvement over the standard byte-code, but the lexbind byte-code may > > show a similar improvement. > > I do expect lexbind byte-code to be slightly faster than dynbind byte-code, > but I also expect that the speed up you get from compilation to native code > will be even larger with lexbind byte-code than with dynbind byte-code. > > This is because lexbind byte-code uses more stack-access operations which > are very simple and thus quick to execute and because such quick byte-code > operations have a relatively larger interpretive overhead (because the > overhead is constant per operations, so it's relatively higher for simple > operations). Right, I get what you're saying: the smaller lexbind variable ops will reduce the time spent in primitives, which favours the native functions. And the frequent use of the variable operations may make the improvement substantial. It's a bit much for me to try now, so I'll consider it again in a few weeks time.