From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Thu, 10 Aug 2023 19:49:49 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> <83fs4rjq9j.fsf@gnu.org> Reply-To: esr@thyrsus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9551"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 11 01:50:46 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 1qUFQU-0002LV-Ph for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Aug 2023 01:50:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUFPf-0007Ug-2y; Thu, 10 Aug 2023 19:49:55 -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 1qUFPd-0007UE-1t for emacs-devel@gnu.org; Thu, 10 Aug 2023 19:49:53 -0400 Original-Received: from thyrsus.com ([71.162.243.5] helo=snark.thyrsus.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUFPa-0003RY-Ut; Thu, 10 Aug 2023 19:49:52 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 3ED1C18A469C; Thu, 10 Aug 2023 19:49:49 -0400 (EDT) Content-Disposition: inline In-Reply-To: <83fs4rjq9j.fsf@gnu.org> X-Eric-Conspiracy: There is no conspiracy Received-SPF: pass client-ip=71.162.243.5; envelope-from=esr@thyrsus.com; helo=snark.thyrsus.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:308550 Archived-At: 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 need to be shared, but what about the buffer's mode set and mode-specific kemaps? 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 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. :-) 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