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: Thu, 04 Dec 2003 15:58:25 -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: <4nhe0ggv0u.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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070572239 13685 80.91.224.253 (4 Dec 2003 21:10:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 21:10:39 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 04 22:10:34 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 1AS0k6-0008Nx-00 for ; Thu, 04 Dec 2003 22:10:34 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AS0k5-00057C-00 for ; Thu, 04 Dec 2003 22:10:34 +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 1AS1h2-0006uJ-9o for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 17:11:28 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AS1cI-0003Kn-Bu for emacs-devel@gnu.org; Thu, 04 Dec 2003 17:06:34 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AS1Xn-00025e-QX for emacs-devel@gnu.org; Thu, 04 Dec 2003 17:02:26 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AS1X8-00022D-Ae for emacs-devel@gnu.org; Thu, 04 Dec 2003 17:01:14 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AS0Zg-0004O9-00 for ; Thu, 04 Dec 2003 21:59:48 +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 1AS0Zf-0004O1-00 for ; Thu, 04 Dec 2003 21:59:47 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AS0Zf-0003Az-00 for ; Thu, 04 Dec 2003 21:59:47 +0100 Original-Lines: 37 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:F8WLEq01pKnAyr7Ned6zgQJrQJc= 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:18398 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18398 On 04 Dec 2003, monnier@iro.umontreal.ca wrote: >> I don't think process filters would help much if I wanted to look >> up several entries in a hashtable in parallel to build an article >> summary buffer. Right now, doing this sequentially is the only >> way, and consequently doing fancy things while building the summary >> buffer is not a good idea. > > So you want to reduce the time it takes to build a summary buffer? > I agree that it would be good to build the summary buffer "in the > background" so I can do something else during this time, but if you > want to use parallelism to make things faster, then I think you're > barking up the wrong tree: Emacs is not optimized for speed and > there are probably much easier ways to make it faster. Easier and > safer as well (after all, parallelising doesn't always speed things > up, far from it). The point is not to make Emacs *faster* but to make the user experience better :) When Emacs can *respond* faster due to preemptive multithreading, the user can start reading a message thread while the summary buffer is being built, or the user can cancel the summary build and leave the group if something else came up. C-g is the only option to do the latter right now, and for instance nnrss servers in Gnus can be very slow so I often find myself hitting C-g when they take too long. I understand all this can be hacked into place, but is it really necessary to avoid multithreading so desperately? 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. With the good ole Pentiums this was not such an issue, but today's processors are definitely better at simulating multiples (hyperthreading) or cooperating (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. Ted