From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Thu, 21 Sep 2023 07:29:07 +0300 Message-ID: <83wmwk9mjw.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11269"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 21 06:29:38 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 1qjBJp-0002jE-2R for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Sep 2023 06:29:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjBJH-0005jG-Sg; Thu, 21 Sep 2023 00:29:03 -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 1qjBJG-0005i0-Im for emacs-devel@gnu.org; Thu, 21 Sep 2023 00:29:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjBJF-0006XQ-AC; Thu, 21 Sep 2023 00:29:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=LN2pUQ021428SOvOey8LhoZ2Eo7gFrwe2o3INmskApU=; b=hZhQpKbbgR3H NU/27OSfSLHYNQyOVYdvHjF7ErlJnysTzJ9pZy8lTymQHdFMy/WxtPj3Au5BAVL5q0I9Yc0LcNSgQ fmLb5gNNyyayxV/1Vaibl6Phe/lID0kjK5gqMOLPzc13J+rxA1m/50OXtQsAqcK51uWA3/HiNLmr5 N++qbc2FQ6MOMJ3sij0+WvQEEXYDyBSM/CnpNLpTwLixPOzPHAkNsj4xFnzixKR5c20xoXNuTw1gE XPrggvjBs0AY1tffjxY0rwT3Vjm3zx8Jiqr9Wa646g02G8EaBmYhovGNrjLceDykVGhDpvu3y2qxD j8Mgb07qHYhq2YvT5Wz1gg==; In-Reply-To: (message from Dmitry Gutov on Wed, 20 Sep 2023 22:22:53 +0300) 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:310863 Archived-At: > Date: Wed, 20 Sep 2023 22:22:53 +0300 > Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > From: Dmitry Gutov > > Okay, here's a question that I should have started with: what kind of > parallelism are we discussing? Not clear yet. > 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. All of the above need some fundamental issues to be resolved to enable any of them. I think at this point it is best to try to look for solutions for those fundamental issues, and only after that see which of the above are possible and worth our while.