From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Immanuel Litzroth <immanuel.litzroth@gmail.com>
Newsgroups: gmane.emacs.devel
Subject: Re: Shrinking the C core
Date: Fri, 11 Aug 2023 10:24:15 +0200
Message-ID: <CAM1nAcxQi-steBYTuEx9Dk3XJQbJXCyrUyxa0pbHGahBRvmUug@mail.gmail.com>
References: <20230809094655.793FC18A4654@snark.thyrsus.com>
 <87il9owg0f.fsf@yahoo.com> <ZNO2EGpxGH9gexpp@thyrsus.com>
 <s0d1qgb93d9.fsf@yahoo.com>
 <ZNQ7D+bokRsekJJE@thyrsus.com> <83fs4rjq9j.fsf@gnu.org>
 <ZNV3ndfLzkVL32N8@thyrsus.com>
 <trinity-776ec954-037b-4222-be5f-1ae04d7a5eec-1691712224182@3c-app-mailcom-bs14>
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 <eliz@gnu.org>, luangruo@yahoo.com,
 emacs-devel@gnu.org
To: Christopher Dimech <dimech@gmx.com>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 11 10:25:52 2023
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	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 <emacs-devel-bounces@gnu.org>)
	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 <immanuel.litzroth@gmail.com>)
 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 <immanuel.litzroth@gmail.com>)
 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: <trinity-776ec954-037b-4222-be5f-1ae04d7a5eec-1691712224182@3c-app-mailcom-bs14>
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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=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: <http://permalink.gmane.org/gmane.emacs.devel/308564>

On Fri, Aug 11, 2023 at 2:04=E2=80=AFAM Christopher Dimech <dimech@gmx.com>=
 wrote:
>
>
>
>
> > Sent: Friday, August 11, 2023 at 11:49 AM
> > From: "Eric S. Raymond" <esr@thyrsus.com>
> > To: "Eli Zaretskii" <eliz@gnu.org>
> > Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> > Subject: Re: Shrinking the C core
> >
> > Eli Zaretskii <eliz@gnu.org>:
> > > 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