From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Martin Stjernholm Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: Thu, 04 Dec 2003 18:22:15 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5bptf4ebw8.fsf@lister.roxen.com> 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070559736 18739 80.91.224.253 (4 Dec 2003 17:42:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 17:42:16 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 04 18:42:13 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 1ARxUT-0001Mo-00 for ; Thu, 04 Dec 2003 18:42:13 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARxUS-0002Xu-00 for ; Thu, 04 Dec 2003 18:42:12 +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 1ARyOG-0008ES-LV for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 13:39:52 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ARy9Q-0000AL-Ip for emacs-devel@gnu.org; Thu, 04 Dec 2003 13:24:32 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ARy8p-0008Gf-Gt for emacs-devel@gnu.org; Thu, 04 Dec 2003 13:24:26 -0500 Original-Received: from [194.52.182.190] (helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARy8j-0008BX-95 for emacs-devel@gnu.org; Thu, 04 Dec 2003 13:23:54 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id 8E3DB9A99; Thu, 4 Dec 2003 18:22:21 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id 90CDF9A16; Thu, 4 Dec 2003 18:22:15 +0100 (MET) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 1ARxB9-0006OU-00; Thu, 04 Dec 2003 18:22:15 +0100 Original-To: Ted Zlatanov In-Reply-To: <4noeuon378.fsf@lockgroove.bwh.harvard.edu> (Ted Zlatanov's message of "Thu, 04 Dec 2003 08:05:15 -0500") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/20.7 (gnu/linux) 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:18387 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18387 Ted Zlatanov wrote: >> o To be able to run several threads simultaneously in multicpu or >> hyperthreaded systems. >> o To get OS level preemption between threads. > > Those two benefits make a big difference. The last does not since it's quite feasible to simulate, as I've outlined. (I know that from practical experience with this threading model in a language environment fairly similar to elisp.) > Today's Pentiums have hyper-threading technology, so even a single > processor can act as two. True. Hyperthreading is becoming more commonplace. > The best cooperative multitasking can't make use of multiple > processors as well as premptive 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. > Cooperative multitasking definitely has benefits - time-critical > applications for instance, but I don't think that applies to Emacs. One thing that does apply to Emacs, and very heavily too, is that cooperative task switching makes it a lot easier to cope with the threading issues at the application level - it becomes an opt-in feature instead of an opt-out, i.e. code that doesn't need or want to bother with thread safety remains safe. This is important even if the considerable transitional work to thread safe existing code is disregarded. Thread locking is still a complex issue that easily leads to bugs (and often very tricky ones too), so it's a big advantage to not have to bother about it in the vast majority of code. > /.../ 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. 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? 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.