From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Dimech Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Fri, 11 Aug 2023 02:03:44 +0200 Message-ID: References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> <83fs4rjq9j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36554"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , luangruo@yahoo.com, emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 11 02:04:41 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 1qUFdx-0009F8-Nc for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Aug 2023 02:04:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUFdF-0001cQ-U5; Thu, 10 Aug 2023 20:03:57 -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 1qUFdE-0001cG-Lg for emacs-devel@gnu.org; Thu, 10 Aug 2023 20:03:56 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUFdC-0006hJ-IU; Thu, 10 Aug 2023 20:03:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.com; s=s31663417; t=1691712224; x=1692317024; i=dimech@gmx.com; bh=HMZp6kBS1Xm8jgyO7rydHbNIE5x3yCtPnr8K0tDTgXI=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=VgMdwWNzqwYDBlp2A1DmxzDTZ3M3RgAYLFpSEgT1darDqGso9RZNNpBmd4+svRgBV0lJxfp mRZa1hYIWwf3nWZF07jijIb3iJya//bAjK5dVQryEPb+t3cl64J3FxurD1CE28EeE2Boawj6y uhMyn9jCahtSqtkPWG7mHSJ2VV0KT3cSB466inXUrtNvbQmRzUzJjlnS4uUdPvK28+7q5VxHd Q4FBJUPijpE6dj5KnFm8RYPAtpNPk7Brr3t8iaStsIlsVDk3x9mP6TwYhQV1TxI4RRaNtb4vN hherAQ0hd+/RAWmFRZpmFvtf985tQbGblchw3Z/hE5o4/qEnFKlw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [141.8.81.247] ([141.8.81.247]) by web-mail.gmx.net (3c-app-mailcom-bs14.server.lan [172.19.170.182]) (via HTTP); Fri, 11 Aug 2023 02:03:44 +0200 Importance: normal Sensitivity: Normal In-Reply-To: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:n043TQ+PpGkFBhY65y79y3QTFIgYEI7jQD1n552tAejjTHL41nbh5C9bvih2ic/Qy23He vhck9ZDxmjg4czdfNT42B9wjfwLs7qf4CdHYtrQAUa6vemindl3UyLObP25Bd6s/zstufMp0jPjW 6inS/+y5E/KPxFGdC3Nws6bQG0DMstLA5vHPQW+NLHVf3CoPT7D0kIdZMMVjMGIVhTo79uAohICH 1Nv5bKbhnmu4Gn6Zy0z9i9XwOa/F2FRFzsDx3kWLZwcI1GeSPD5tIUcZysHsV0Gf0Icfz7MATL36 4U= UI-OutboundReport: notjunk:1;M01:P0:iuRh48vXlgA=;RBywHPFRcqjrAZfN+7iqGWHeXe3 gtxITts1SLZ6mLIjhGomuPA+JKdNRC9q3DFSgY5TWo2uIAd2L87Q5zO3o3sr9GiS1jfJ0IyvX MyA+I8W93nZQqq8Yivcv/bc3J9+t3qS/x1zEBc8C3VS86Ms/IJzoCtTtYoCusrgUQbA6Aa+Rv sE8j/bXOc60VA4Xz06T/v3Bhciz68NgEZQV6FmaGOygt47QXCrGnh6jTP889gnczwcHc9gMHe oA90A6Ctkksas2q8ZipjgbcSJR7gKhRFSx5+/LlRRDkri0NeQLosawLNM3d+xBAGp+7cpcs+A 8aRN6uqVjInO1dM1J4rFvtV4cpJHi+SJ4OWAb/HrGJON29YLwpT+fHP/bvthZfHY1faT2K0kg /Fc8j4+AzOAwHx5Ir1p7f6srI36ePm3STL5RVrS8ILjMY9m/4t/UPhBIeHMQ3OfcuRz/Uk0Mm 0xj0FHsijale5eeVIK+JlvBITm2T0qWYYlZaRU/T0S0v5vmMFPss58PQxUPRGPeXxHCF9vXUp gfqu7/UIkUy0HNx9d53Z2pxRwD/FmTq38aLkPI3skCTbyb+jlOheVzf0ElXoMfFLb4US7F73g 328e3YFPDUOIIirN8obNk3x1vMj1MqM90C3Iz+AjH+SzOY2uyJMMpOn5paKpKYV7WswvExf7e lZT6n+cO6oRyvILkfAqjlavgLfMEvAXF6RcU+oBsb44werfwm3luz2TKL0FY9Xsip9wlPY3+y 5VQRJnvai7MEePDIMJjotFjSz1wOWMuDJp00v0vwlHH3kvoRuACaLRJ2ZZRIyYVfuMr8A6YV Received-SPF: pass client-ip=212.227.15.19; envelope-from=dimech@gmx.com; helo=mout.gmx.net X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:308551 Archived-At: > Sent: Friday, August 11, 2023 at 11:49 AM > From: "Eric S. Raymond" > To: "Eli Zaretskii" > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Subject: Re: Shrinking the C core > > Eli Zaretskii : > > What's more, Emacs is still a single-threaded Lisp machine, although > > in the last 10 years CPU power develops more and more in the direction > > of multiple cores and execution units, with single execution units > > being basically as fast (or as slow) today as they were a decade ago. > > Yeah, I've been thinking hard about that single-threadedness in the > last couple of weeks. I have a design sketch in my head for a > re-partitioning of Emacs into a front-end/back-end pair communicating > via sockets, with the back end designed to handle multiple socket > sessions for collaborative editing. (No, this isn't my big secret idea, > it's something I think should be done *along with* my big secret idea.) > > For this to work, a lot of what is now global state would need to be > captured into a structure associated with each socket session. I notice > that it's difficult to find an obviously correct cut line between what > the session structure should own and what still needs to be shared state= ; > like, *some* keymaps definitely need to be session and buffers still nee= d > to be shared, but what about the buffer's mode set and mode-specific kem= aps? > Or marks? Or overlays? > > This is a difficult design problem because of some inherent features > of the Emacs Lisp language model. I did not fail to notice that those > same features would make exploiting concurrency difficult even in the > present single-user-only implementation. It is unclear what > could be done to fix this without significant language changes. > > > And if these theoretical arguments don't convince you, then there are > > facts: the Emacs display engine, for example, was completely rewritten > > since the 1990s, and is significantly more expensive than the old one > > (because it lifts several of the gravest limitations of the old > > redisplay). Similarly with some other core parts and internals. > > Are you seriously to trying to tell me that the display engine rewrite a= te > *three orders of magnitude* in machine-speed gains? No sale. I have > some idea of the amount of talent on the devteam and I plain do not > believe y'all are that incompetent. > > > We found this conclusion to be false in practice, at least in Emacs > > practice. > > I'm not persuaded, because your causal account doesn't pass my smell > test. I think you're misdiagnosing the performance problems through > being too close to them. It would take actual benchmark figures to > persuade me that Lisp interpretive overhead is the actual culprit. > > Your project, your choices. But I have a combination of experience > with the code going back nearly to its origins with an outside view of > its present strate, and I think you're seeing your own assumptions > about performance lag reflected back at you more than the reality. > > > Please be more patient, > > That *was* patient. > I didn't aim for his head until the *second* time he poked me. :-) Good you're not a general in a battlefield ! I don't have such rules of c= onduct. Did you know that there are tribes in the Amazon River Basin who simply ki= ll you if they see you ? > I'll stop trying to make preparatory changes. If I can allocate > enough bandwidth for the conversation, I may try on a couple of > hopefully thought-provoling design questions. > -- > Eric S. Raymond > > > >