From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: 05 Dec 2003 15:44:45 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87oevbes4h.fsf@emacswiki.org> <20031117040607.C6C5D79B72@server2.messagingengine.com> <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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070635589 16925 80.91.224.253 (5 Dec 2003 14:46:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Dec 2003 14:46:29 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Dec 05 15:46:25 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 1ASHDs-00073a-00 for ; Fri, 05 Dec 2003 15:46:24 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ASHDs-0005K4-00 for ; Fri, 05 Dec 2003 15:46:24 +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 1ASIAQ-00083Y-Fg for emacs-devel@quimby.gnus.org; Fri, 05 Dec 2003 10:46:54 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ASIAK-00083H-TH for emacs-devel@gnu.org; Fri, 05 Dec 2003 10:46:48 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ASI9o-0007xT-0U for emacs-devel@gnu.org; Fri, 05 Dec 2003 10:46:48 -0500 Original-Received: from [217.80.160.111] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ASI9n-0007x2-0e for emacs-devel@gnu.org; Fri, 05 Dec 2003 10:46:15 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB5EiktM011525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2003 15:44:47 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB5Eij6x011521; Fri, 5 Dec 2003 15:44:45 +0100 Original-To: Ted Zlatanov In-Reply-To: <4nk75bwjaf.fsf@lockgroove.bwh.harvard.edu> Original-Lines: 81 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:18420 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18420 Ted Zlatanov writes: > On 04 Dec 2003, monnier@iro.umontreal.ca wrote: [...] > >> (Xeons). I don't have benchmarks, sorry, but at least on Solaris > >> the performance of a machine increases by at least 80% with each > >> additional SPARC processor. > > > > Such naive sweeping claims would tend to ruin your credibility, > > I'm afraid. > > OK, here's some Novell benchmarks that show significant increases in > performance with additional processors in Solaris in a particular > application (LDAP server): > > http://www.novell.com/info/collateral/docs/4621167.01/4621167.html > > I work with Solaris for a living, so I feel justified in making that > claim based on what I know - years of experience, Sun's published > benchmarks, vendors' benchmarks. Sun would hardly publish benchmarks centered around applications that don't gain from multithreading/multitasking. We are not talking about an LDAP server, but Emacs. Ironically, using applications like preview-latex or in general comint-mode, Emacs will show _vast_ speed improvements (decidedly more than 100%) under multiprocessor machines for most operating systems, and the reason is a scheduling anomaly for almost all operating systems on single processor machines that keeps pipes from getting more than minimal fill levels: as soon as there is something in the pipe, the pipe filling process gets starved from CPU, and so even a tight loop of for (;;) write(1,"\n",1); will never manage to get more than a single character processed by Emacs' filter functions. With a multiple CPU box, this does not happen as the pipe fills even while Emacs is processing the last bit. I have gotten real time speed improvements even by starting a completely useless busy loop that would get the scheduler involved more often than when Emacs and the comint-run application where just passing the CPU among each other. So here you have a situation where a two-processor machine will increase speed by decidedly more than 100%, and that even without Emacs itself being multithreading. I'd be careful about just what conclusions to draw from this. Similar from Solaris benchmarks. > Note I did not say that an *application's* performance increases by > at least 80%. The machine's performance, given processes or threads > within them that can be effectively run on separate processors by > the OS scheduler, is what increases. This is generally understood > but perhaps my language was not clear enough. > > Specifically in the context of Emacs, I do not know the internals > well enough to judge that. I hope I can help with the work in any > way I can, no matter what the eventual "multithreading or not" > decision is. My personal opinion is that the Lisp machine would need to get reorganized significantly to even get a modicum of advantage. And that implies, among others, a clean separation between global entities and locally bound entities that I don't see usefully implemented without lexical binding. I may sound as though I was riding a hobby horse here, but I am not involved in that work, and while I consider it an issue of architectural cleanliness, I have my doubts about the feasability of change here. The longer it is postponed, the more painful a change will get. And a change in there would bear quite more consequences to existing Lisp files than, say, the current garbage collector and memory layout changes. One may be able to duct tape some measure of multithreading even on top of pervasive dynamic binding, but to be honest, I fear the outcome. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum