From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: Fri, 05 Dec 2003 07:17:28 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4nk75bwjaf.fsf@lockgroove.bwh.harvard.edu> 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070627679 660 80.91.224.253 (5 Dec 2003 12:34:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Dec 2003 12:34:39 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Dec 05 13:34:36 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 1ASFAK-0007eO-00 for ; Fri, 05 Dec 2003 13:34:36 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ASFAK-0002bZ-00 for ; Fri, 05 Dec 2003 13:34:36 +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 1ASG3d-0006ew-NG for emacs-devel@quimby.gnus.org; Fri, 05 Dec 2003 08:31:45 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ASFyc-0005gp-8E for emacs-devel@gnu.org; Fri, 05 Dec 2003 08:26:34 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ASFvr-000580-Oh for emacs-devel@gnu.org; Fri, 05 Dec 2003 08:24:14 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ASFsg-0004RB-Lc for emacs-devel@gnu.org; Fri, 05 Dec 2003 08:20:26 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ASEv5-00069k-00 for ; Fri, 05 Dec 2003 13:18:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ASEv4-00069c-00 for ; Fri, 05 Dec 2003 13:18:50 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ASEv4-00089x-00 for ; Fri, 05 Dec 2003 13:18:50 +0100 Original-Lines: 68 Original-X-Complaints-To: usenet@sea.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v) Cancel-Lock: sha1:nszswFiDAJ+jeuyPfjmroIgPBbE= 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:18413 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18413 On 04 Dec 2003, monnier@iro.umontreal.ca wrote: >> take too long. I understand all this can be hacked into place, but >> is it really necessary to avoid multithreading so desperately? > > Nobody is avoiding it here. We're just explaining to you why nobody > bothered to do it yet and why none of us feels the urge to do it: > lots of work, unclear payoff. I was referring to hacking things into place in that particular example, where multithreading seemed like a natural approach, not the attitude of this group. Sorry if it seemed otherwise. The attitude of this group of developers is wonderful. >> Plus, I am pretty sure that when an application uses N processors >> instead of one (as Emacs might with true preemptive multithreading) >> there is at least some speed improvement. > > Your being pretty sure does not magically eliminate all the known > counter examples. You're right. I had specific applications in mind, not any general application. In the general case that is not necessarily true, because not all applications can take advantage of multithreading of course. I think that Emacs in particular can use it right now, and that applications will develop in time that will take full advantage of multithreading. >> (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. I think you'll find that Solaris specifically is known to scale very well with additional processors, at the penalty of being pretty slow on a single-processor machine. The Linux kernel (2.5 especially), to give another example, scales well with additional processors too, even when hyper-threading instead of a real additional processor is used. See this article for an overview and benchmarks: http://www-106.ibm.com/developerworks/linux/library/l-htl/ 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. > Yes, things can be made to work well, but do you have an idea of the > amount of work it takes to do that ? 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. Ted