From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Fri, 11 Aug 2023 10:03:49 +0300 Message-ID: <83msyygiwa.fsf@gnu.org> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> <83fs4rjq9j.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1142"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 09:04:14 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 1qUMBx-000Ad8-Qp for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Aug 2023 09:04:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUMBC-0002K9-W7; Fri, 11 Aug 2023 03:03:27 -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 1qUMBB-0002Hl-Oz for emacs-devel@gnu.org; Fri, 11 Aug 2023 03:03:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUMBA-0007cV-JG; Fri, 11 Aug 2023 03:03:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=C6t/6PRIiRnip9ma7CEnu0ZYr4KxL7yXPgOAbRQ5VQc=; b=HX1gd0R4aBib zoVjwc9S5a1qhzinWM4Xq9QL8R+aLvwOfW8nBwaLAp2n6dQhWXF/PQCvV5aDU5X+mQunO4Zp2ZpqH 7PF79HfmYxI/9T1Mx22FudihpSSlBdRdevjOZdfmDd6/daQFbxQH4XKMyq3ImWYbMQ47h7DlEcsOU dYO5jhdfqzKFNDlpjRt8wPbK8yIWrc+iGClUAW4B2LVabWee5LpZ9M/s3XdbyFyrVUKAPWhbxVD/m oQzjeYhkoabAghSolIpAwXe59DAscAEsDVBRMWJ1EJ6VAFIuPKhW/QbcNZzPMMe200zPKLSxPdkUs ULPrqyKTmZuDDz5Pe1lw+w==; In-Reply-To: (esr@thyrsus.com) 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:308558 Archived-At: > Date: Thu, 10 Aug 2023 19:49:49 -0400 > From: "Eric S. Raymond" > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > > 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. > > 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. This stuff was discussed lately in several threads on this list. And yes, finding which parts of the global state to leave shared and which to make private to threads is a large part of the issue. My personal opinion is that introducing concurrency into Emacs will need redesign of the internals, not just some changes. But that's me. > > 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. First, I don't know where did you take the 3 orders of magnitude figure. During 1990s, PCs generally had 100 to 200 MHz clocks, and nowadays we have ~3.5 GHz clocks -- that's 1.5 order of magnitude, not 3. As we all know, chip clock speeds stalled around 2004; processing power continues growing due to multiprocessing, but that doesn't help Emacs, because Lisp mostly runs on a single execution unit. Second, the new display engine uses up many more GUI (Xlib, Cairo etc.) API calls than the old one did -- and that takes some significant additional processing. Moreover, no amount of Emacs devteam talent can do anything about the code quality and algorithms in those libraries and components of the OS. Third, the new display engine was not just a rewrite of the old capabilities: it _added_ quite a lot of functionalities that were either very hard to implement or plainly not possible with the old one. These additional functionalities are nowadays used very widely, and they do eat CPU power. And finally, there are plain facts: users do complain about slow operation, including during redisplay, in some (fortunately, usually rare) situations. As an example perhaps closer to your heart: certain VC-related operations are slow enough (hundreds of milliseconds to seconds, and sometimes minutes!) to annoy users. VCS repositories can be very large these days, and that could be part of the problem. We just had a long discussion here about the fastest possible way of collecting all the files in a deep directory tree, see bug#64735 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64735). The somewhat surprising findings there aside, one conclusion that stands out is the time spent in GC takes a significant fraction of the elapsed time, and that flies in the face of moving code from C to Lisp. So even if the theoretical considerations don't convince you, the facts should: we do have performance problems in Emacs, and they are real enough for us to attempt to solve them by introducing non-trivial complexity, such as the native-compilation feature. We wouldn't be doing that (in fact, IMO it would have been madness to do that) unless the performance of Lisp programs was not a real issue. > > 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. People did benchmarks, you can find them in the archives. When the native-compilation was considered for inclusion, we did benchmark some representative code to assess the gains. The above-mentioned bug discussion about traversing directories also includes benchmarks. If you want to sample this further, try benchmarking shr.el when it performs layout of HTML with variable-pitch fonts. It basically does what the display engine does all the time in C, but you can see how much slower is this in Lisp, even after several iterations where we looked for and found the fastest possible ways of doing the job in Lisp. You might be surprised and even astonished by these facts, to the degree that you are reluctant to accept them, but they are facts nonetheless. > > Please be more patient, > > That *was* patient. I didn't aim for his head until the *second* > time he poked me. :-) Well, then please be *more* patient. People here are generally well-meant, and certainly have the Emacs's best interests in their minds, so shooting them too early is not the best idea, to put it mildly.