From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: 07 Dec 2003 18:55:20 -0500 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 1070841532 25854 80.91.224.253 (7 Dec 2003 23:58:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2003 23:58:52 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Dec 08 00:58:48 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 1AT8nY-00037I-00 for ; Mon, 08 Dec 2003 00:58:48 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AT8nY-0004CH-00 for ; Mon, 08 Dec 2003 00:58:48 +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 1AT9il-0000lE-6u for emacs-devel@quimby.gnus.org; Sun, 07 Dec 2003 19:57:55 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AT9iE-0000l4-Vj for emacs-devel@gnu.org; Sun, 07 Dec 2003 19:57:22 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AT9hi-0000Id-04 for emacs-devel@gnu.org; Sun, 07 Dec 2003 19:57:21 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AT9hh-0000IR-MZ for emacs-devel@gnu.org; Sun, 07 Dec 2003 19:56:49 -0500 Original-Received: from vor.iro.umontreal.ca (vor.iro.umontreal.ca [132.204.24.42]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id B9C9120F6C; Sun, 7 Dec 2003 18:55:20 -0500 (EST) Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id 6F2FE3CFD9; Sun, 7 Dec 2003 18:55:20 -0500 (EST) Original-To: Ted Zlatanov In-Reply-To: <4nk75bwjaf.fsf@lockgroove.bwh.harvard.edu> Original-Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean 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:18527 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18527 >>> (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 Solaris is indeed fairly well designed w.r.t scalability (at the cost of single-proc performance, of course). But that only means that Solaris is not an obstacle: it will not magically make your application scalable unless your application was designed for it. Making Emacs scalable is probably best done by starting all over from scratch. The current structure of the C code together with the semantics of elisp means that it's about as far from scalable as you'll ever get. Now, that doesn't mean you can't do it, but just that it's going to be a lot of work and it might introduce subtle incompatibilities, so you need a lot of motivation to start the effort and you'll need really good arguments to convince RMS that breaking compatibility is worth the pay off. Now what is the payoff ? Speed. Given the fact that elisp is known to be slow, and that pretty much no work has been done to speed up Emacs in the last N years, I get the impression that nobody really cares about speed here. What people do care about a little is the "non-blocking thingy" which might require some form of multithreading but does not require any kind of scalability and does not require nearly as much work (and as much breakage of backward compatibility). So I'd recommend people start with this if they want to work on something like that. Once this is done, we might be able to start thinking about scalability. Stefan