From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Sun, 27 Aug 2023 17:14:41 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13766"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 27 18:12:44 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 1qaINV-0003GY-MZ for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Aug 2023 18:12:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaIMW-00008Q-3v; Sun, 27 Aug 2023 12:11:40 -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 1qaHYQ-0002zc-1x for emacs-devel@gnu.org; Sun, 27 Aug 2023 11:19:54 -0400 Original-Received: from mail-vi1eur05olkn20825.outbound.protection.outlook.com ([2a01:111:f400:7d00::825] helo=EUR05-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qaHYM-0006oX-Vb for emacs-devel@gnu.org; Sun, 27 Aug 2023 11:19:53 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XjBjW+pOsseHd3aTJnXVW2PlG0lEzz1sWDYtbwympDDTEdIG1rU3Jxf9X/mc9RiryGjPLsQVTUhgyOr6JPAOLudTGzhAc77dCB2bJWC4IMqllMa4An95pRVdonTrGsUUTQ7Rr/iUwsf+bQ4V3kf779LPco7aB058+vs/z8NXXsyZosKvlA28xG1q6ELMBOM6tHNAmejUnDgN3ht+vO1tKuIxPZwoG1+dsTPmJ78MulEM6Nfr55NEUhsEQ2WgckPtOsH6o/tzNm8ZGkcpftv/227mX98rPQ/vPgJbf6GoPSvnYDEfLERHzxC5RkSk/6cOHSbZ6AsRY8eZVZu0X7Sqnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1Iej2lH4imrtW9Q+esLlYAzC4bq4kS3hVWe3eafaI1Y=; b=LmyjcOuBoYRO6fONKZOCUphIzZFYXXAH1nRurxsnoysV0hpI/2g8s/DrwVg5s+gLDcCmO0lA4ijgKCfvv9Tg7q5nDELLP/3Fy22ETJpZVI43MULS6gmEf3fy86E8dkccpO9YeoeIW3P5FdRQLvF7V+Mwhz8Pg2/Z3Fq3BKAwafh96UbfQurndHHKdZupr1rUnwUyyccq5Qksii4OXFvj2GLNpH5tLe6QvKrgWtpcJm0UHunHvKjs+gc6CRZf7hgCsaEhC8B1TpEqGTa8AU6HGp/binpt++CCcLBeTt9ex5FUZf8IK9gZP7xUHDqTPsrQdnPyGIu61XkhTwkOiGVV1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1Iej2lH4imrtW9Q+esLlYAzC4bq4kS3hVWe3eafaI1Y=; b=Rg5PMeJQbUrcRq8qYoYGqIO1iDNNNSRrsUXBueNq2kKK/3N0stZdtZV6RkIWKB8zP4qHyL0Owl72QPEZOETks+GIIb143vlHsuDwnA9uvBWLkKyCr1f2n4hWVZgtQm+N8jnlrcjZ/1us68BkZqagDirEehwcjTIXHSxmShLeKSm1pf2qkOSPRBShKCjVD/8zFnzmMWLcBUetQhRQEwGnH1gzfm8Ww6UZnHXQIF0n33K5+Tldi+yS1TIw8L/+UdCpZlp+dgjeosj9caSH94MiVeMIC+JU033v11JbZRWBu59+/BgYhbVmL9MrOnnJT15kvPNcxTF3aRolhFMjDWi6HA== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by GV2PR09MB5771.eurprd09.prod.outlook.com (2603:10a6:150:a8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.34; Sun, 27 Aug 2023 15:14:43 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::df56:b1b1:64b1:6122]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::df56:b1b1:64b1:6122%7]) with mapi id 15.20.6699.034; Sun, 27 Aug 2023 15:14:43 +0000 X-TMN: [/68x/H7jUgBH+wKRriAIzxuQbGuigG+iDqMDTA2k/po=] X-ClientProxiedBy: MM0P280CA0106.SWEP280.PROD.OUTLOOK.COM (2603:10a6:190:9::25) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87h6okh5zy.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|GV2PR09MB5771:EE_ X-MS-Office365-Filtering-Correlation-Id: 01b897da-b46d-435b-323f-08dba710578d X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UarGfjUEVGbopRYla+IF/5jBrUNFX8ZZCHVoQk/WVW2qRjZnXCE38wFF2MGB/YBdeu5pjOmG84PzpUui4AttLvrFLyGLQBxX7h6Eu1LLk/3Gdjhn1htOPn9e0yZJ7VgrameILF8Kvdg6HJ1XgTasFH1xnWU8zh4SdiOPqKFh0nHZfZ25/a483R8MZy8r6VqYfi6U+vFM+J5r/Jw7tYxYVUVMaYJsoxO+n4Mbr55I+Wkk7WEvnCqXShQDXxjMDLC+zhsuCL0PlCg2K9Dm6OIhxA9zMqDBIT2ll2cf7uNu3bd01Z1UkYyPnlMdCT7XnjmEmzkiBf+j8VOAI4Cg4cdK5o0fMx6AEcUsR0nZH9GtIWtQ2oI/RXXJE7L/lDFI5Ejq9X76d1BBCMFxw0EtP6V1wtyU9BoryjjDPkZdLoJjkKdtM12J89OzANNRsNY7yESGkwFfMQe8gzDcx04zmanVERt/6RD8k1c3cu4+jUeDn938Gl0BFzA352IGA8HLK2oOi+gbwZfFsk4PSQcgD1XBhw8bsMOANpn4kuDQ6oUJOLG1ivZN0LXR5S7irceMwkRK X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?lVOFd2JhAVc52hOqATxCU54zkHvr/FZ8aMBcLOKxRnOg6S3bQdIkD+ltwW4G?= =?us-ascii?Q?zdMrVtEYDe8E3HGGRBzSc3vc1iQ04RytnZQHT4yh1wMEnc6Tm8J14Lb5ynPt?= =?us-ascii?Q?+LDJwz0x5c4dNUmE3kUYiIWApsj82tqkGSHGlRyKThbxB2hvKpvvn09JENE6?= =?us-ascii?Q?pIJzBwyJxAUC+Lc8hFGWU3hiu+j8PBMVBIXup+EFm3/trbcZ5HAoRv7LaQ1X?= =?us-ascii?Q?vNyJNiMGGiKhcBMBp8ueA5yn1PJ8SqGLl3uaOCYlHOBf4ex0bs02mM+07BUX?= =?us-ascii?Q?qcfQxvucJVCVVxIdzD9t5uK/NKPOguANY6ffSXhmNTpKfhQC97i6HWdmzqUv?= =?us-ascii?Q?dH0tRcQogJHc5+fNfxENGw0QogjaD8m313LMyT4C6cK6t9bAII1aZyIloDWM?= =?us-ascii?Q?7ljG121ovGB6NHga1S1Gv8BuNldwA0JHN18h6w5aPUlH9OVua2ayjLriIIDR?= =?us-ascii?Q?407/I1V1qzpehk9wRqSir3sIQCCDXLAKLEmRyqqVFKLQoID0CdSdRjT4c2wu?= =?us-ascii?Q?nzMknRLgg5QRsPKqqNUKovYL/2PjpJWwwznlPJDvjZc8RUPuBGpTBT0FwXgL?= =?us-ascii?Q?8yG8FYd9jaTez1mE6kOV22LuzSkjMxGZS2IKAV4NftEZr9F40nxPkcHJ24Wm?= =?us-ascii?Q?ih X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 01b897da-b46d-435b-323f-08dba710578d X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2023 15:14:43.8927 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR09MB5771 Received-SPF: pass client-ip=2a01:111:f400:7d00::825; envelope-from=arthur.miller@live.com; helo=EUR05-VI1-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 27 Aug 2023 12:11:38 -0400 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:309355 Archived-At: >> Date: Wed, 9 Aug 2023 21:19:11 -0400 >> From: "Eric S. Raymond" >> Cc: emacs-devel@gnu.org >> >> Po Lu : >> > "Eric S. Raymond" writes: >> > >> > > When I first worked on Emacs code in the 1980s Lisp was already fast >> > > enough, and machine speeds have gone up by something like 10^3 since. >> > > I plain don't believe the "slower" part can be an issue on modern >> > > hardware, not even on tiny SBCs. >> > >> > Can you promise the same, if your changes are not restricted to one or >> > two functions in fileio.c, but instead pervade throughout C source? >> >> Yes, in fact, I can. Because if by some miracle we were able to >> instantly rewrite the entirety of Emacs in Python (which I'm not >> advocating, I chose it because it's the slowest of the major modern >> scripting languages) basic considerations of clocks per second would >> predict it to run a *dead minimum* of two orders of magnitude faster >> than the Emacs of, say, 1990. >> >> And 1990 Emacs was already way fast enough for the human eye and >> brain, which can't even register interface lag of less than 0.17 >> seconds (look up the story of Jef Raskin and how he exploited this >> psychophysical fact in the design of the Canon Cat sometime; it's very >> instructive). The human auditory system can perceive finer timeslices, >> down to about 0.02s in skilled musicians, but we're not using elisp >> for audio signal processing. > > This kind of argument is inherently flawed: it's true that today's > machines are much faster than those in, say, 1990, but Emacs nowadays > demands much more horsepower from the CPU than it did back then. > 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. > > 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. > > We are trying to make Lisp programs faster all the time, precisely > because users do complain about annoying delays and slowness. Various > optimizations in the byte-compiler and the whole native-compilation > feature are parts of this effort, and are another evidence that the > performance concerns are not illusory in Emacs. And we are still not > there yet: people still do complain from time to time, and not always > because someone selected a sub-optimal algorithm where better ones > exist. > > The slowdown caused by moving one primitive to Lisp might be > insignificant, but these slowdowns add up and eventually do show in > user-experience reports. Rewriting code in Lisp also increases the GC > pressure, and GC cycles are known as one of the significant causes of > slow performance in quite a few cases. We are currently tracking the > GC performance (see the emacs-gc-stats@gnu.org mailing list) for that > reason, in the hope that we can modify GC and/or its thresholds to > improve performance. > >> If you take away nothing else from this conversation, at least get it >> through your head that "more Lisp might make Emacs too slow" is a >> deeply, *deeply* silly idea. It's 2023 and the only ways you can make >> a user-facing program slow enough for response lag to be noticeable >> are disk latency on spinning rust, network round-trips, or operations >> with a superlinear big-O in critical paths. Mere interpretive overhead >> won't do it. > > We found this conclusion to be false in practice, at least in Emacs > practice. > >> > Finally, you haven't addressed the remainder of the reasons I itemized. >> >> They were too obvious, describing problems that competent software >> engineers know how to prevent or hedge against, and you addressed me >> as though I were a n00b that just fell off a cabbage truck. My >> earliest contributions to Emacs were done so long ago that they >> predated the systematic Changelog convention; have you heard the >> expression "teaching your grandmother to suck eggs"? My patience for >> that sort of thing is limited. > > Please be more patient, and please consider what others here say to be > mostly in good-faith and based on non-trivial experience. If > something in what others here say sounds like an offense to your > intelligence, it is most probably a misunderstanding: for most people > here English is not their first language, so don't expect them to > always be able to find the best words to express what they want to > say. Very interesting discussion going on for a long time. I think you are all correct, and wrong to an extent, but I believe that nobody has touched the fundamental issue: emacs design is flawed beyond repair for todays machines. Not necessarily in pejorative meaning, but to repair Emacs you would have to significantly rework internals, to the point of entire design rewrite. Emacs is a child of its time (like everything else). It was designed for the time of single-core slow machine, and its design makes sense in that perspective. However, for todays multicore machines, the fact that a lisp machine is slapped on top of an existing text editor (Gosslings I guess), and everything is shared via global state, can't be addressed in any other way but to rewrite Emacs core from ground up. No amount of patch slapping onto the current design can compensate for the lack of appropriate desing. RMS has one abandoned TECO design to adapt Emacs to new times; perhaps the time has come to do it again. Sure, you can rework the C core completely, and implement better GC, threads, and what not, but it seems signficant less work to re-implement Emacs in a language that already has proper infrastructure in the place, such as Common Lisp on ccl/sbcl, instead of duplicating all the work. I understand machines of the time were to slow for a language as big as Common Lisp when Emacs switched from TECO to C, but today the situation is different. I am quite sure that sbcl would offer enough speed for a text editor implementation. As you all have already noticed, speed is limited by a human factor anyway. We also see many projects that are duplicating Emacs idea, and with all right; the ideas of Emacs are indeed sound and very good. But it is a shame to abandon 40 years of development and the community that Emacs has, something other projects can't compete with. Emacs Lisp is de facto, *the* best documented Lisp out there, and Emacs is one of the best documented open source projects available, kudos for that to everyone involved. It would be a pittiful waste to just throw away all that documentation and work done, as well as the vivid community that Emacs has. In my personal opinon, those are *the* qualities of Emacs as a project. I personally believe that Emacs as a project would benefit of complete core rewrite, as well as unifying the extension and the implementation language for several reasons. Yes, it is a lot of work, but even rewriting C core to adapt Emacs to modern machines is a lot of work in itself, if it is even possible. You can either let it be, and slowly but surely see Emacs usage decline, or you can rewrite Emacs core (again) to better suit modern multicore machines.