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.bugs Subject: bug#65491: [PATCH] Improve performance allocating vectors Date: Sun, 17 Sep 2023 19:15:42 +0300 Message-ID: <83o7i0g4i9.fsf@gnu.org> References: <6B2EDD07-AAEB-40E8-B369-F634296BD3D9@gmail.com> <83v8cagkqv.fsf@gnu.org> <83ttrugkj2.fsf@gnu.org> <83r0mygi4y.fsf@gnu.org> <8af6fa1c-4873-bd6e-e896-ab5bb8d012a2@cs.ucla.edu> <83led5gyxa.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1455"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65491@debbugs.gnu.org, mattias.engdegard@gmail.com, monnier@iro.umontreal.ca To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 17 18:17:21 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qhuSX-0000AL-PL for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Sep 2023 18:17:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhuSF-0001Hi-Dq; Sun, 17 Sep 2023 12:17:03 -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 1qhuS7-0001HA-Fl for bug-gnu-emacs@gnu.org; Sun, 17 Sep 2023 12:16:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qhuS7-0007DX-1X for bug-gnu-emacs@gnu.org; Sun, 17 Sep 2023 12:16:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qhuSE-0004ni-Cm for bug-gnu-emacs@gnu.org; Sun, 17 Sep 2023 12:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Sep 2023 16:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65491 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 65491-submit@debbugs.gnu.org id=B65491.169496737418390 (code B ref 65491); Sun, 17 Sep 2023 16:17:02 +0000 Original-Received: (at 65491) by debbugs.gnu.org; 17 Sep 2023 16:16:14 +0000 Original-Received: from localhost ([127.0.0.1]:51260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhuRP-0004mV-3E for submit@debbugs.gnu.org; Sun, 17 Sep 2023 12:16:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhuRJ-0004lp-2G for 65491@debbugs.gnu.org; Sun, 17 Sep 2023 12:16:09 -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 1qhuR0-0006vh-8B; Sun, 17 Sep 2023 12:15:48 -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=NL9zBmXbMl4X8pFiVplqyroQDJwLwPXDGyZxwxoeiNs=; b=qlaD6YiTB6XA fuJHlQpIyO90JE2Xe/FNEuglx8kM4eC0bW4oinhZBIcHqngMwevhxpJFfQbsCs6BjOOndr2T/DNKh MtOAtx5zd32PKEv7fa9CYrSLgxIJVUaSPbOS/4IrN0ZfQWdE+0P1g89HkJW/RBhLCGKSs6SKdPCc5 eRQVfIZHfVkzBbBhY65XmFHexRzvyybg8asignKg/bHwRnPJBbuzTJNO86YhS6+pRwHGmwCDOMKUV DFdIcvY/esu/XyMjGCz8I2AVOQnjBAlJNPiYtT4cJMo4NKr7NSmjRmHTqRZC368zvKVPRCFlz93vs S4vRb6hg6HmzfocKlAMT1A==; In-Reply-To: (message from Paul Eggert on Sun, 17 Sep 2023 08:22:01 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270710 Archived-At: > Date: Sun, 17 Sep 2023 08:22:01 -0700 > Cc: mattias.engdegard@gmail.com, 65491@debbugs.gnu.org, > monnier@iro.umontreal.ca > From: Paul Eggert > > On 2023-09-16 22:18, Eli Zaretskii wrote: > > > It seems to me that in a 32-bit build with wide > > ints just > > > > #define XUNTAG(a, type, ctype) ((ctype *) XLP (a)) > > > > should be enough, since XLP yields a 'void *', no? > > That would complicate the code unnecessarily. Let's not go there. Patch > P works as-is, and it's simpler. Let's do that instead. Even though the code is so completely obfuscated and hard to understand? Where do we draw the line between complications and code readability (and thus maintainability)? We don't want to depend on you personally each time we need to make some change in this stuff. > > what I > > meant was to have a separate definition of XUNTAG for 32-bit builds > > with wide ints (which could still remove the undefined behavior), > > Yes, that's exactly what I suggest not to do. Why complicate the source > code unnecessarily? It isn't "unnecessarily" in this case, IMO. > And if we complicate it here, why not complicate it in similar ways > in dozens of other places? Because in general I agree: we should not have several different implementations of a macro if a single one will do. But not at a price of such obfuscation, where even reasoning about the code requires very high level of understanding of the intricacies of C and what is and isn't UB (something that also changes with time). > I went through a lot of this when adding support for --with-wide-int in > the first place, years ago. When doing so, I strove to avoid having > multiple copies of the code whenever I could. And I pretty much > succeeded: there are only two WITH_WIDE_INT conditionals in lisp.h (and > only three in other source files, all introduced relatively recently by > others to work around compiler bugs, and all which should be rewritten > without the #if). I will be the last one to push for more WIDE_EMACS_INT conditions, but let's not forget that they are not the only conditions we have, okay? We also have USE_LSB_TAG and LISP_WORDS_ARE_POINTERS, and those are no easier (and maybe even harder) to figure out in each and every configuration. At least with WIDE_EMACS_INT all you need is to look at config.log, whereas with others you need to follow the convoluted ways of their definition in lisp.h and maybe err a few times. It will maybe make you laugh, but I frequently find it easier to fire up GDB and ask it to show me the values of these macros, to make sure I'm not making a mistake. This is a developer's plight we are better off without, don't you agree? > It's an obvious win to have just one copy of the code instead of two, > when one copy works and is just as efficient. As much as possible, > --with-wide-int should not be a special case. We should not have > "#ifdef WITH_WIDE_INT" scattered all over the place. Keep it simple. I agree in general, but the case of XUNTAG seems like this principle taken ad absurdum: subtraction with no fewer than 3 type-casts (not counting those in XLP and LISP_WORD_TAG) and a needless subtraction of zero, when a single type-cast should suffice! But if both you and Mattias still think a single definition of XUNTAG is better, all the downsides notwithstanding, I won't mount the barricades. Just let it be known that I agree under protest.