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: What's the problem? (Was: Are there plans for a multi-threaded Emacs?) Date: Tue, 09 Dec 2003 14:28:05 -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: <4nvfop6bay.fsf@collins.bwh.harvard.edu> References: <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> <4nsmjv8d32.fsf@collins.bwh.harvard.edu> <4nu14b6q33.fsf@collins.bwh.harvard. NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071002577 19125 80.91.224.253 (9 Dec 2003 20:42:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 9 Dec 2003 20:42:57 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Dec 09 21:42:49 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 1ATogz-0005xj-00 for ; Tue, 09 Dec 2003 21:42:49 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATogz-0008Ji-00 for ; Tue, 09 Dec 2003 21:42:49 +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 1ATpQl-0008Bj-F3 for emacs-devel@quimby.gnus.org; Tue, 09 Dec 2003 16:30:07 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AToYt-0004dG-Jm for emacs-devel@gnu.org; Tue, 09 Dec 2003 15:34:27 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AToV0-0003hU-MK for emacs-devel@gnu.org; Tue, 09 Dec 2003 15:30:58 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AToUz-0003gs-N9 for emacs-devel@gnu.org; Tue, 09 Dec 2003 15:30:25 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATnXW-0006U3-00 for ; Tue, 09 Dec 2003 20:28:58 +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 1ATnXU-0006Tv-00 for ; Tue, 09 Dec 2003 20:28:56 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATnXU-0002Pu-00 for ; Tue, 09 Dec 2003 20:28:56 +0100 Original-Lines: 53 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:S+2S8+lOcx7O1L8ebEdIPsepplI= 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:18581 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18581 On 08 Dec 2003, dak@gnu.org wrote: > Ted Zlatanov writes: > >> Note I don't claim these can't be rewritten in a concurrent >> fashion. I simply gave examples that could stand to be improved. >> The majority of examples are in Gnus, because that's the Elisp >> application I know best. > > Have you already done the obvious thing of setting gnus-asynchronous > to a non-nil value? That's the least one would expect from somebody > that wants parallelism that badly. I'm fairly familiar with Gnus. gnus-asynchronous helps pre-fetch articles, which is nice but tangential to the issues raised here. > You can't just throw in parallelism and hope that things will work > out somehow. I was aware of that fact. >> - Gnus mail retrieval, summary thread building, registry lookups > > Most of those can be controlled with gnus-asynchronous and > subordinate variables. Only pre-fetching of articles, which is not the problem most of the time. >> - independent hashtable lookups and calculations in parallel would >> be a very nice improvement in themselves, > > Why? What time-critical code performs them frequently? 1) It's hard to write code that does parallel calculations when there is no API and no internal support. Most current Emacs code would not use parallel calculations because if was not written with that in mind. As you appropriately mention above, you can't just throw in parallelism, applications have to be written for it. 2) The improvement is incremental, for the user's benefit. Emacs will not gain speed or simplicity, but users will gain improved responsiveness and will be happier using Emacs. > If you want to afford a separate binding stack for every thread, > this also means that every _read_ _access_ to a symbol must run via > the thread's binding stack instead of just using the stack whenever > the a binding _changes_. So you're saying that it will slow down Emacs by using memory and CPU, to manage the thread-local binding stack, correct? I agree. Ted