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: Wed, 20 Sep 2023 09:47:46 +0000 Message-ID: <87ttrp89bx.fsf@localhost> References: <83edizjn0v.fsf@gnu.org> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24269"; 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 Wed Sep 20 11:47:24 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 1qitnn-00068e-Nk for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 11:47:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qitn9-0002RP-Lg; Wed, 20 Sep 2023 05:46:43 -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 1qitn4-0002RC-HA for emacs-devel@gnu.org; Wed, 20 Sep 2023 05:46:38 -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 1qitn0-0000UJ-SU for emacs-devel@gnu.org; Wed, 20 Sep 2023 05:46:38 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 92E1A240101 for ; Wed, 20 Sep 2023 11:46:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695203192; bh=oF4VLgH9RIk+kmeOCaG5nF7ROotLaAJPNOpbIWfGBCY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=INCE0TkY01yT8QjULoTpRXyilQQh6vaVraAjuFp0C59MhlWOgljuzAoJhK1OideVX gJMon3brkI9JY6VnzhqVTdZ5W3neKxrkqznZSMdFZIOBFg+4Hgl7dZ+zopv97leT01 yKltytzYDK4MJSnTit/NY5yG+qPyr+sArVeEbfFp3v7jz2+9N+Ujkg2UmnFLFW/Ij1 ArL74w6QaqOLJdZ0PpgZPM8fjL15WkcG15/m/aqPT8q6ywwiSKAfbAa9F8qMaG5IiP lZaXNVhxFAAIagvP4EUbsLuKSVqSJGwGD9j4T6GOBXs0KL6cCnpPZ8eQigLf4l9wOH cqyfdxNe00nVg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RrDFM3nbKz6v1B; Wed, 20 Sep 2023 11:46:31 +0200 (CEST) In-Reply-To: <83fs3ackrq.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=ham 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:310809 Archived-At: Eli Zaretskii writes: >> (I suggest this because I feel that xdisp is a rabbit hole we may sink >> in instead of doing something more productive) > > I'm actually of the opposite opinion. I think trying to parallelize > redisplay is a lower-hanging fruit, and if successful, it could bring > non-trivial gains to Emacs even if the rest remains single-threaded. Without having Elisp async threads, what you suggest is only possible for the non-Elisp parts of the redisplay. May you list which C-level parts of the redisplay are known to be slow? AFAIU, long-lines performance is largely problematic when running Elisp. (Also, isn't it solved already?) 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? >> I am particularly worried about scenarios when window geometry changes >> by asynchronous threads. Or, say, face definitions. Imagine that it >> happens at point when we are already drawing the now obsolete geometry >> onto glass? > > xdisp.c has solutions for these two (and other similar) situations. > The problems have nothing to do with parallelism, they happen today > because we call Lisp at certain places in the display engine. Yes, but now we know exactly in which segments of the code the geometry might change. And check for it in strategic places. In the case of asynchronous threads, the geometry may change any time (when another threads happens to run something that affects geometry), which is not accounted for by the current code. >> > We tried that already, with the existing Lisp threads. One reason why >> > those are almost never used is that the display issue was left >> > unresolved. >> >> That might be one reason, but not the only reason. And certainly not the >> most important reason for the use cases where I did try to use threads >> myself. > > 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. >> As we discussed previously, a number of Elisp programs can benefit from >> async threads even when redisplay is not asynchronous - network queries >> (gnus), text parsing (org-mode, slow LSP server communication, xml >> processing). > > You forget that almost every Lisp program in Emacs either displays > something or affects stuff that affects redisplay. It's easy to > forget, I know, because in Emacs redisplay "just happens" by some > magic. 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. 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. >> To be clear, it would indeed be nice to have async redisplay. > > 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? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at