|
From: | GNU bug Tracking System |
Subject: | bug#36597: closed (27.0.50; rehash hash tables eagerly in pdumper) |
Date: | Tue, 11 Aug 2020 09:34:02 +0000 |
Your message dated Tue, 11 Aug 2020 02:33:34 -0700 with message-id <c1aad0e7-6416-2327-24a2-fc5c916a87b8@cs.ucla.edu> and subject line Re: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper has caused the debbugs.gnu.org bug report #36597, regarding 27.0.50; rehash hash tables eagerly in pdumper to be marked as done. (If you believe you have received this mail in error, please contact help-debbugs@gnu.org.) -- 36597: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36597 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems
--- Begin Message ---Subject: 27.0.50; rehash hash tables eagerly in pdumper Date: Thu, 11 Jul 2019 14:05:14 +0000 This is a follow-up to bug#36447, which has been fixed. Lazy rehashing for hash tables should be removed. This patch does that. Lazy rehashing makes all code that accesses hash tables a little more complicated; in at least one case, we forgot to do that, resulting in bug#36596. The sole benefit of lazy rehashing to be mentioned so far is that start-up time is reduced a little (by less than a millisecond on this system), and that for certain usage patterns (many short Emacs sessions that don't do very much, I think), this might outweigh the negative consequences of lazy rehashing. Lazy rehashing means less maintainable code, more code, and, at run-time, slightly slower code. In particular, it means that we have to have a comment in lisp.h which distracts from the code and has to be marked as "IMPORTANT!!!!!!!", which I think is nearly as annoying as having to jump through special hoops before accessing a hash table. I'm posting this as a separate bug so we can have a, hopefully, brief discussion about it and then either move away from lazy rehashing or continue using it; if we decide to continue using it, it should be documented in much more detail. (We should keep in mind that conditional branches, even ones that are well-predicted and don't cause cache misses, aren't free: they use execution units, and preparing their arguments in registers increases register pressure, and of course they increase code size.)0001-Rehash-hash-tables-eagerly-after-loading-a-portable-.patch
Description: Text Data
--- End Message ---
--- Begin Message ---Subject: Re: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper Date: Tue, 11 Aug 2020 02:33:34 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 On 8/10/20 6:04 AM, Lars Ingebrigtsen wrote:time make -j32 compile-always ... Er... It's weird that there's so much difference in time between runsI think I get less variance if I do a sequential 'make' (i.e., without -j). Of course this takes longer.if we just take the mean from these numbers, it seems that your patch is making compilation faster. :-)It also simplifies the code a bit, so I took the liberty of installing it, after updating its commit message a bit and changing it to keep a comment that was updated recently (I figure this was a merge error). The patch I installed is the first patch attached. While reviewing the patch I noticed some relatively minor things in the neighborhood that could easily be fixed, so I did so by installing some followup patches, also attached (the last patch is the only one that's at all nontrivial). I'll mark the bug as done. Thanks to both of you for following up on this.0001-Rehash-hash-tables-eagerly-after-loading-a-dump.patch
Description: Text Data0002-src-fns.c-hash_table_rehash-Help-the-compiler-a-bit.patch
Description: Text Data0003-src-pdumper.c-pdumper_load-XSETVECTOR-make_lisp_ptr.patch
Description: Text Data0004-Don-t-needlessly-convert-to-unsigned-in-pdumper.patch
Description: Text Data0005-In-pdumper-simplify-INT_MAX-computation.patch
Description: Text Data0006-pdumper-speed-tweeks-for-hash-tables.patch
Description: Text Data0007-pdumper-avoid-listing-hash-table-contents.patch
Description: Text Data
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |