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:18:17 -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: <4nu14ggwvq.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> <5bptf4ebw8.fsf@lister.roxen.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070569470 7729 80.91.224.253 (4 Dec 2003 20:24:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 20:24:30 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 04 21:24:27 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 1AS01T-0004yn-00 for ; Thu, 04 Dec 2003 21:24:27 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AS01T-0004Z5-00 for ; Thu, 04 Dec 2003 21:24:27 +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 1AS0yi-000895-Jb for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 16:25:40 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AS0yI-0007u5-31 for emacs-devel@gnu.org; Thu, 04 Dec 2003 16:25:14 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AS0xe-0006zc-V1 for emacs-devel@gnu.org; Thu, 04 Dec 2003 16:25:06 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AS0xe-0006rZ-3i for emacs-devel@gnu.org; Thu, 04 Dec 2003 16:24:34 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by mx20.gnu.org with esmtp (Exim 4.24) id 1ARzwq-0003U7-LE for emacs-devel@gnu.org; Thu, 04 Dec 2003 15:19:40 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ARzwq-0003fb-00 for ; Thu, 04 Dec 2003 21:19:40 +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 1ARzwo-0003fS-00 for ; Thu, 04 Dec 2003 21:19:38 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ARzwo-0001o8-00 for ; Thu, 04 Dec 2003 21:19:38 +0100 Original-Lines: 58 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:/756Uh6YjnwJhnML+AIAgfkB3aw= 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:18396 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18396 On Thu, 04 Dec 2003, mast@lysator.liu.se wrote: Ted Zlatanov wrote: >> The best cooperative multitasking can't make use of multiple >> processors as well as preemptive multithreading. > > I don't see how preemption per se can improve parallell execution. > Fine grained locking can, but it's hard to avoid making it too fine > grained so that the locking itself becomes more time consuming than > the speedup from the improved parallellism it achieves. Not all threads need to be aware of each other. Not all threads will compete for the same resources. Not all threads, in a cooperative setup, will cooperate with each other due to programmer or design error. Also, I actually think it's easier to program for preemptive multithreading because you write thread-safe code instead of reengineering your code to fit the cooperative model. >> /.../ Converting a single-threaded application to multithreaded, >> especially one as complex as Emacs, is a daunting task. I think >> it's worthwhile. > > I gather then that one important goal for you with the thread > support is to make Emacs utilize true parallell execution better, > i.e. it's for performance reasons and not only to let elisp > developers take advantage of the threading paradigm. Yes. > I don't regard that performance gain as significant, at least not > compared to the amount of work involved. Emacs is still an > interactive application, and as such it essentially only responds to > user actions. Granted, there are some elisp packages that > occasionally can be very heavily cpu bound, but they are afterall > only a few exceptions. The only case when true parallell execution > would improve things are when two or more such tasks are run > concurrently. I regard that as an extremely rare situation, but you > would probably disagree? It's rare currently because it's not possible. I think the application will come once the support for them is built. Here's more examples: font-locking a buffer; reading or writing a file. Cooperative or preemptive multithreading would make them a more pleasant user experience. > Anyway, a way to cope with such heavy tasks could be to make it easy > to fork a separate interpreter with its own data set. It would then > only take the main interpreter lock explicitly and rarely to > communicate its results and request new data, or perhaps even be > restricted to communication through a pipe. Heavyweight threads are a problem because, as I mentioned already, Emacs is such a tightly coupled environment. I think lightweight threads are better for performance. Ted