From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Wed, 20 Sep 2023 22:22:53 +0300 Message-ID: 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> <99e84ae7-b3aa-a009-5cb8-a75826343196@gutov.dev> <838r92cgxp.fsf@gnu.org> <837comcam8.fsf@gnu.org> <6946e6f0-c6ef-186c-35d4-c09935c05a07@gutov.dev> <83y1h1axtq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32345"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: yantar92@posteo.net, 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 21:23:55 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 1qj2ni-0008Fd-Q8 for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 21:23:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qj2mx-0000le-PU; Wed, 20 Sep 2023 15:23:07 -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 1qj2mr-0000kp-Ag for emacs-devel@gnu.org; Wed, 20 Sep 2023 15:23:02 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qj2mo-0003As-P2; Wed, 20 Sep 2023 15:23:00 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E468B5C00E5; Wed, 20 Sep 2023 15:22:56 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 20 Sep 2023 15:22:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1695237776; x=1695324176; bh=cXRIH2CuNlrztkf67gnFH6GxwSxuNukN9NX B9we5XZU=; b=A8WFkA0QxNIHUFLMIlc+EPO9mpKOzAR8oFUMdNlPM+sToHV1OhV l9HWpPsJ/Av461J+97RjO+NB7NhZuUWnVCVJTFesdqSNRkSYwV2NQxNzWmfeOsQe GgRMruQzuZ00MH6vvWJwzTQcRxKo1/+Acw2DPLgWCzXZFsXX6XWw24NsNvAjoBaq lm+QWRzt6KNzUqkxVNeiBg8zGpLRbfLU6dJgjACmfyrqBqvpMqlgrWfvSINrfxvt pvi9W8zIV68woRQcpp7cHd6DHceLyWrPFejXr2r3CcaUUh+VVxKr+2fELrZjeMex ztGY8Pr9yxUXC+4emvDLepgHe4/KAjr0JgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695237776; x=1695324176; bh=cXRIH2CuNlrztkf67gnFH6GxwSxuNukN9NX B9we5XZU=; b=XSfB1XOkhQ9fS6EAVdjfyMG1dAhxmeyb5I0dQ6QRSx0VdlOLlMt tB33B3OSj2W/xTlA+sY03NseaivgCXPXtB7HZa6OJ47amxSkx64y8P5cZgIagK6I apdVG8Ktq+jxDRp5Ti/yJ/YeiZmemtmPNIMssWdPmqXavhKkWkeReF0DXBLT+knl anhTwxEW3X0mR+M0u7gtfNxC5Yj0yq7peNK1D87pyILb+aTJ1qcdRHnQVR74WZsk kAqcMXjJDIjdNodDToSO2uEJAmDB6v2R83kjai6O1CRZRFP5gxqg0ytPu76mHMgN QepjZSf/UfSUPhvW4vS9+Abi9XvE2gs62jg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekfedgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 20 Sep 2023 15:22:55 -0400 (EDT) Content-Language: en-US In-Reply-To: <83y1h1axtq.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.27; envelope-from=dmitry@gutov.dev; helo=out3-smtp.messagingengine.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 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, NICE_REPLY_A=-1.473, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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:310852 Archived-At: On 20/09/2023 14:28, Eli Zaretskii wrote: >> Date: Tue, 19 Sep 2023 23:21:46 +0300 >> Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org >> From: Dmitry Gutov >> >> On 19/09/2023 20:54, Eli Zaretskii wrote: >>> >>> How do you know that parallel redisplay will not solve this? This can >>> only be obvious when the detailed design of that is presented. Until >>> then, it's anyone's guess. >> >> It's not 100%, but seems logical: the problem with long lines is that >> displaying a single line took non-linear amount of time proportional to >> its length. To be able to layout it in parallel, we would somehow have >> to be able to split it into independent pieces (perhaps using some >> caching mechanism?, IDK). If we are actually able to do that (which >> seems difficult), a non-parallel redisplay algorithm should happily use >> the same mid-line checkpoint information to work on smaller pieces of >> the line, likewise increasing the speed. > > You are considering only the redisplay of that single window which has > long lines. But what about the other windows, which perhaps don't > have long lines? And what about the main thread of Emacs itself, > which freezes for as long as redisplay didn't finish, thus preventing > user interaction and responsiveness in general? These factors should > not be neglected. Splitting an N^3 program in two to run in half the time won't make it have adequate performance. When the problem is algorithmic, we'll have to fix it as such. >> But I think we've much improved on the issue by reducing the complexity >> instead (correct me if I'm wrong here). > > If you mean the long-lines improvements in Emacs 29, then we traded > off correctness in at least some cases. It wasn't for free. I see. Well, we definitely did that WRT to font-lock (the part which we might tweak or roll back in the future). I wasn't sure if that's also what happened in the deep of the display engine as well. >>> Anyway, you asked for evidence that redisplay could benefit from >>> performance boost, and I gave you some. Now you for some reason want >>> to claim that my evidence doesn't convince you, but it still is >>> evidence, right? >> >> I was looking for other examples, to be honest. Like, for example, >> evidence that redisplay is something that keeps an average Emacs session >> from running at 60fps. Or even at 30fps. That would make it a bottleneck. > > With enough text properties and overlays, you can definitely see a > tangible slowdown in frame rate. E.g., Org developers don't want to > use text properties because they slow down redisplay, and thus they > consider them not scalable enough. > >>> You seem to be opposed to attempts to explore ways of making Emacs >>> less single-threaded than it is today, unless someone provides a >>> proof, up front, that this will necessarily solve some particular >>> problem? Why? what harm could that possibly do, if it succeeds? And >>> if it doesn't succeed, at least we will have learned something >>> probably useful for the future. >> >> It is my experience that good benchmarking often helps with changing the >> design as well. Or coming up with a new one (there are a lot of options >> for how one could proceed). > > On the high-level design level, it should be clear without any need > for benchmarking that separating redisplay from the main thread could > bring benefits. Isn't that what every GUI application out there does? > So trying to think about that is always a good thing, IMO. Okay, here's a question that I should have started with: what kind of parallelism are we discussing? A) Initially I figured it's the ability to render a single window using multiple threads of execution. It's the one my mind immediately went to, but might the hardest of the bunch because it would require us to parallelize the display algorithm for a single buffer. B) Being able to render different windows/buffers fully in parallel. I think that requires us to implement concurrent Lisp threads, at the very least. That's likely to drag down the single-thread performance (though it's hard to predict by how much). C) Having only a separate (not Lisp) thread for GUI might help with responsiveness somewhat (by throttling certain expensive windows down, for example), but overall it might not improve by much. Though I suppose it could render in parallel those buffers which don't need to run Lisp to display? Anyway it would be synchronized to the one Lisp interpreter.