From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Immanuel Litzroth Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Fri, 11 Aug 2023 10:24:15 +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="8008"; mail-complaints-to="usenet@ciao.gmane.io" Cc: esr@thyrsus.com, Eli Zaretskii , luangruo@yahoo.com, emacs-devel@gnu.org To: Christopher Dimech Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 11 10:25:52 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 1qUNSx-0001u8-Ou for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Aug 2023 10:25:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUNS6-0007Iv-BR; Fri, 11 Aug 2023 04:24:58 -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 1qUNS5-0007Ih-4d for emacs-devel@gnu.org; Fri, 11 Aug 2023 04:24:57 -0400 Original-Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qUNS3-0006gR-DN; Fri, 11 Aug 2023 04:24:56 -0400 Original-Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2b95d5ee18dso26367881fa.1; Fri, 11 Aug 2023 01:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691742292; x=1692347092; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=r8SaC76YPC4LvWc2eYt0BdXxAorAClHAbJqVHnmC68Y=; b=L2e5H7rdaL/aqgRb0K/zOtxNpLDrlPhRdsqqcwR49ZEBwWh3Ql3AbDNRgu5Wo+aLVV Ga5mkVR/clMYiqdMuSkZysT/25dlqP5XcKhh0oYJgNTEXsBLiY/kbBihc8gyDUnjoTlL zz+5wBlKjrsMfy/LZAYQymu3iBz9bWboznbjixWeCYIgp9tnf3ORVUzt27NMz4t6iJN1 wWC2McN0dZG2Gcc+XH9OtHAmN/5W/rbWVgrNNEdAXgGUoEydreDYqo0ueY8CifhjdFb1 /cJD4V0x5iiDX8S1ZYZbRFHFUlFHp5vSqpe55esKx9lsJCF2Zi2zGck9Ag3sChIAfBR8 f3wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691742292; x=1692347092; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=r8SaC76YPC4LvWc2eYt0BdXxAorAClHAbJqVHnmC68Y=; b=NgJ2BmhSt49Ocf2n1/E0w8M2kavyobsIFLuHeokPoRFjUwU/9ExLpTpThbRGaIApDG ar6LCuFPBJ93yDtt7bfYF5ecVfj7khO1TjuMbMJLVAw24PyxddxMH0HlE4Btm/N4sLHT ED2pLgIg5ilL0zYhk0yzXaSKEP/wig59eyJrYTJoVdzzcwJlmq8VnV1WdohnC2k9L88N pCJ7QJahmXuSokFLzGbu+qYJN93las9GgvSrAzj8GprrME0Bsa+PI4aDSYXUllowygM/ Uf5UKtOIvger1w4H9B8QSFsW/CiQqEOrLY0R7FXeh30bvqZb/WFRmPEv9gwpFRoDT998 2cmQ== X-Gm-Message-State: AOJu0YzQw1oCPmq1uYJQ+tTm7h49wv6XOF1ldmRVPeBh9T/iYjwMh0Nc NnQdPlgaPRZJqtrMU7pYiEtwfL8EYl8Mbu3fJA== X-Google-Smtp-Source: AGHT+IF63SAfiSV4qCcRXNn5v3BWsU5WPRNTZuCgfdLY7/KYRDo69EGijCXOfHTiqy1Y6L7BZohfB4LE5lXU3xqlw14= X-Received: by 2002:a2e:b616:0:b0:2b6:ea3b:f082 with SMTP id r22-20020a2eb616000000b002b6ea3bf082mr1027009ljn.38.1691742291464; Fri, 11 Aug 2023 01:24:51 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::236; envelope-from=immanuel.litzroth@gmail.com; helo=mail-lj1-x236.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 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_NONE=-0.0001, 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:308564 Archived-At: On Fri, Aug 11, 2023 at 2:04=E2=80=AFAM Christopher Dimech = wrote: > > > > > > 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 directio= n > > > 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 notic= e > > 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 stat= e; > > like, *some* keymaps definitely need to be session and buffers still ne= ed > > to be shared, but what about the buffer's mode set and mode-specific ke= maps? > > 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 rewritte= n > > > 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 = ate > > *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 = conduct. > Did you know that there are tribes in the Amazon River Basin who simply k= ill > you if they see you ? How did those tribes get to know about Eric? i --=20 -- A man must either resolve to point out nothing new or to become a slave to defend it. -- Sir Isaac Newton