From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Martin Stjernholm Newsgroups: gmane.emacs.devel Subject: Re: What's the problem? (Was: Are there plans for a multi-threaded Emacs?) Date: Wed, 10 Dec 2003 01:45:03 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5bvfopzek0.fsf@lister.roxen.com> References: <87ekvpx18d.fsf@emptyhost.emptydomain.de> <4nad6cikxy.fsf@holmes.bwh.harvard.edu> <4nllpt3hr3.fsf@lockgroove.bwh.harvard.edu> <5bad69zd43.fsf@lister.roxen.com> <4noeuon378.fsf@lockgroove.bwh.harvard.edu> <4ny8tsgxy6.fsf@lockgroove.bwh.harvard.edu> <4nhe0ggv0u.fsf@lockgroove.bwh.harvard.edu> <4nk75bwjaf.fsf@lockgroove.bwh.harvard.edu> <4nsmjv8d32.fsf@collins.bwh.harvard.edu> <4nu14b6q33.fsf@collins.bwh.harvard.edu> <4nvfop6bay.fsf@collins.bwh.harvard.edu> , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Dec 10 01:49:37 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATsXp-000516-00 for ; Wed, 10 Dec 2003 01:49:37 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATsXp-00047U-00 for ; Wed, 10 Dec 2003 01:49:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATtSA-000218-Qr for emacs-devel@quimby.gnus.org; Tue, 09 Dec 2003 20:47:50 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ATtS0-0001z9-V8 for emacs-devel@gnu.org; Tue, 09 Dec 2003 20:47:40 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATtRU-0001hz-QJ for emacs-devel@gnu.org; Tue, 09 Dec 2003 20:47:39 -0500 Original-Received: from [194.52.182.190] (helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATtQz-0001dk-86; Tue, 09 Dec 2003 20:46:37 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id 31E3F9B60; Wed, 10 Dec 2003 01:45:08 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id 86BAE9A3A; Wed, 10 Dec 2003 01:45:03 +0100 (MET) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 1ATsTP-0002cn-00; Wed, 10 Dec 2003 01:45:03 +0100 Original-To: David Kastrup In-Reply-To: (David Kastrup's message of "09 Dec 2003 23:02:29 +0100") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/20.7 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 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:18593 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18593 David Kastrup wrote: > Do you have an idea what figure we are speaking about here? I repeat: > _every_ access to a symbol that now works directly instead has to work > via stack pointers. /.../ Not necessarily. State swapping can be used if only a single thread is running at a time. I have explained how such a "limited" solution still can give a worthwhile improvement. I haven't yet seen any response to those constructive contributions to this discussion that motivates they would be infeasible or meaningless. I truly believe I have proposed a viable solution, but the lack of comment on it is disappointing. > And CPUs like the x86 do not have spare address registers flying > around. Appearance can deceive. I've heard all reasonably modern x86 cpu:s have quite a lot of registers. They're just not accessible through the archaic machine code format, so elaborate register renaming algorithms are used instead. Not that I particularly advocate making the binding environment thread local, for the pragmatic reason of the amount of code change I fear would be involved. > We are quite probably talking about a _significant_ slowdown of the > Lisp machine here. I'm not at all certain of that; cpu optimizations can slant these things in unexpected directions. It wouldn't surprise me if an extra indirection on the stack is faster than a global variable due to better memory locality.