From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Thu, 21 Sep 2023 10:29:48 +0000 Message-ID: <87v8c3zun7.fsf@localhost> References: <0518f65b-1dd1-6923-8497-da4d3aeac631@gutov.dev> <87sf7fc7kd.fsf@dataswamp.org> <834jjuk68t.fsf@gnu.org> <87cyyhc7uu.fsf@dataswamp.org> <83ttrsg9nx.fsf@gnu.org> <83h6nrg4eg.fsf@gnu.org> <83v8c7elan.fsf@gnu.org> <877conk5ny.fsf@localhost> <83ttrreeu0.fsf@gnu.org> <87bkdzeas1.fsf@localhost> <83cyyfe5l8.fsf@gnu.org> <87led2o0nb.fsf@localhost> <83ttrqcpfb.fsf@gnu.org> <877comnv4a.fsf@localhost> <83fs3ackrq.fsf@gnu.org> <87ttrp89bx.fsf@localhost> <83led1aqnq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10768"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 21 15:37:08 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qjJrf-0002W3-G7 for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Sep 2023 15:37:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjJqz-0004K8-CE; Thu, 21 Sep 2023 09:36:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjJqv-0004IB-PO for emacs-devel@gnu.org; Thu, 21 Sep 2023 09:36:21 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjJqq-0000Gj-VI for emacs-devel@gnu.org; Thu, 21 Sep 2023 09:36:20 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id BE12E240103 for ; Thu, 21 Sep 2023 12:28:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695292112; bh=8ybDUtx/MLlxw2T/Cmg8xzm8Bc3V+qqAwUT3xQvxa8E=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=YgnljOMrtVCSCe8NBeTXOoYleNo/HCE5vsQBRY8TfCYQfywYqS8Oa+NQatGlUvhqO sERhGcsPaY0K1rbjV6y4y5lpw1EZh2iT2PP1SddHmdxM3NQkHIFTdhPHRl4pg1G+ln pupweLOsk2rDdOkXNuh/k0c9vPZExHrBr05q8CMlt5SmZ5aG9ns147rRc3BVDXeEQU I9WbAuVQALl8RXtNKzsrN5WgvIH1QM/p2gwHUWBnT73TR9rSw3SdC0SjXDB6UBbP/R w4Ij2/P+BKKqh/jlOwi2oAc9ZOnidvDhHtt7LdahS8Fc7pGeZZsEMHTXkYfW97UsQ0 OWApvPcSTq/UA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Rrs7M3fZBz6v0x; Thu, 21 Sep 2023 12:28:31 +0200 (CEST) In-Reply-To: <83led1aqnq.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310908 Archived-At: Eli Zaretskii writes: >> AFAIU, long-lines performance is largely problematic when running Elisp. > > No, the slow parts are pure C. > >> (Also, isn't it solved already?) > > Not solved, but "bypassed". The solution does have its disadvantages, > although we found them to be a much lesser evil than the original > problem. May you point to the xdisp.c function that is being slow? >> Another one you mentioned is displaying many frames. But isn't it >> optimized by the part of the code that delays redisplay of frames that >> are not visible? Or does Stefan (or anyone) tend to have so many >> _visible_ frames? > > The latter. Ok. But is it possible to redisplay the whole frame without ever calling Elisp? >> > There's more than one reason, that's true. But it doesn't change the >> > fact that all those problems have to be resolved before we have >> > reasonably usable threads. >> >> I disagree. Yes, _all_ the problems are to be solved eventually. But >> solving _some_ of the problems will already be an improvement. IMHO, it >> is not all-or-nothing; we can split the problem into several >> sub-problems and solve them one by one. > > You've lost context, and effectively changed the subject, so now this > sub-thread is not useful anymore. To recap, I was trying to explain > why the display aspects of any concurrency cannot be disregarded if we > want to have a workable solution that can be used in practice. I believe that I did not lose the context. Unless I misunderstand something. What I suggested is to defer the redisplay concurrency and leave it synchronous (interlocked) for now. Concurrency of Elisp that does not trigger redisplay can also be useful. It looks to me that we just disagree about the relative importance of redisplay concurrency. >> I don't forget that. However, we do not have to make each and every >> thread _fully_ asynchronous. It is often enough to process the >> performance bottlenecks asynchronously. After that processing, we can go >> ahead and present the results synchronously to user. > > This assumes the display is always in the end. But that is a false > assumption in Emacs: there are progress messages, there are prompts > and requests for confirmation, there are display updates to show the > stuff processed so far, etc. Again, not always. I do not think that the _initial_ goal should be making every aspect of Elisp working asynchronously without interlocking. We certainly want all Elisp to work in threads, possibly with global lock. But if we get at least some part of useful Elisp to run truly concurrently, it will already be a win. >> Let me provide a more concrete example. >> Consider something as simple as grepping across project files. >> The process of grepping involves: (1) opening and searching many files; >> (2) presenting results to the user. Stage (1) does not really involve >> user interaction or redisplay and can greatly benefit from asynchronous >> threads - we can simply search multiple files at the same time. Then, >> even if stage (2) has to be synchronous, it does not matter - stage (1) >> is what takes most of the time and makes the user wait. > > You describe an Emacs without async subprocesses -- this is how it > works on MSDOS, for example. On more capable systems we display in > parallel with running Grep. I think you misunderstood. I did not mean calling GNU grep. I meant calling M-x grep - Elisp code searching across many Emacs buffers. It would be useful if such code could run concurrently. Another example is org-agenda that is running a large number of regexp search across many buffers. Some real-world users search across as many as 500 buffers, with results accumulated into agenda. It would certainly be useful to run that regexp search concurrently, in multiple buffers at once. Or maybe even on several regions of a single, large buffer. >> > I'm not talking about async redisplay, I'm talking about the ability >> > of non-main threads to display something or do something that would >> > cause redisplay change the stuff on the glass. >> >> Then, how will it be possible without first having async Elisp threads? > > Async Lisp threads is a much harder problem to solve. If we solve it, > this one will also be solved; but the opposite is not true. I agree here. But do note that the interest (and some trial code by Po Lu) so far has been focused on Elisp threads. The problem with display code, even if it is easier to transform it to concurrent, is that understanding display code is by itself is a time-consuming task. Making changes in it (even small changes) is no less trivial (I am referring to bug#64596). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at