carbon-language/carbon-lang
1
0
Fork 0
mirror of https://github.com/carbon-language/carbon-lang.git synced 2026-10-03 20:55:49 +01:00
Code Issues Packages Projects Releases 10 Wiki Activity
3,339 Commits 3 Branches 811 Tags
81dfb2b29b115df27f22cd7e8564d40c360d4e22
Commit Graph
10 Commits
Author SHA1 Message Date
Jon Ross-Perkins 82a346730a Fix clang-tidy issues (#4786) 
Both of these I noticed from testing #4785, but they occur at head.

```
(elided)/execroot/_main/common/raw_hashtable.h:532:40: error: do not use nested 'std::max' calls, use an initializer list instead [modernize-min-max-use-initializer-list,-warnings-as-errors]
  532 |   static constexpr ssize_t Alignment = std::max<ssize_t>(
      |                                        ^
  533 |       {alignof(MetadataGroup), alignof(StorageEntry<KeyT, ValueT>)});
      |        ~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |        static_cast<long>(alignof(MetadataGroup)) static_cast<long>(alignof(StorageEntry<KeyT, ValueT>))

(elided)/execroot/_main/toolchain/install/busybox_info_test.cpp:259:8: error: unused local variable 'usr_prefix' of type 'std::filesystem::path' [bugprone-unused-local-non-trivial-variable,-warnings-as-errors]
  259 |   auto usr_prefix = MakeInstallTree(dir_ / "usr");
      |        ^
(elided)/execroot/_main/toolchain/install/busybox_info_test.cpp:260:8: error: unused local variable 'usr_local_prefix' of type 'std::filesystem::path' [bugprone-unused-local-non-trivial-variable,-warnings-as-errors]
  260 |   auto usr_local_prefix = MakeInstallTree(dir_ / "usr/local");
      |        ^
```

The std::max diagnostic seems a little confused, but the initializer
list seems like it can be dropped without any loss. The unused locals
diagnostic is correct.

Neither of these seem like they should be newer than my last clang-tidy
pass, maybe I just missed them in other sweeps.
 2025-01-10 00:22:04 +00:00
Vitaly GoldshteynChandler CarruthCarbon Infra Bot
 		624950c62c Store hash in the probed_indices array in common/raw_hashtable.h to avoid its recomputation. (#4726) 
Store hash in probed_indices array to avoid its recomputation.

Benchmarks on ARM (altra, aarch64).
```
name                                                  old CYCLES/op        new CYCLES/op        delta
BM_MapInsertSeq<Map<int, int>>/1                         119 ± 2%             119 ± 1%     ~     (p=0.961 n=55+54)
BM_MapInsertSeq<Map<int, int>>/2                         133 ± 1%             134 ± 1%     ~     (p=0.342 n=56+57)
BM_MapInsertSeq<Map<int, int>>/3                         150 ± 1%             150 ± 1%     ~     (p=0.856 n=56+57)
BM_MapInsertSeq<Map<int, int>>/4                         167 ± 2%             167 ± 2%     ~     (p=0.430 n=56+57)
BM_MapInsertSeq<Map<int, int>>/8                         234 ± 5%             234 ± 3%     ~     (p=0.957 n=57+57)
BM_MapInsertSeq<Map<int, int>>/16                        368 ± 4%             368 ± 4%     ~     (p=0.762 n=57+57)
BM_MapInsertSeq<Map<int, int>>/32                        650 ± 4%             650 ± 4%     ~     (p=0.955 n=57+57)
BM_MapInsertSeq<Map<int, int>>/64                      1.93k ± 4%           1.98k ± 4%   +2.35%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/256                     9.68k ± 5%           9.85k ± 3%   +1.74%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/4096                     177k ± 3%            163k ± 2%   -8.17%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/65536                   3.99M ± 3%           3.87M ± 4%   -3.12%  (p=0.000 n=56+56)
BM_MapInsertSeq<Map<int, int>>/1048576                 90.5M ± 5%           91.3M ± 6%   +0.87%  (p=0.025 n=55+55)
BM_MapInsertSeq<Map<int, int>>/16777216                2.77G ± 8%           2.74G ± 9%     ~     (p=0.076 n=57+57)
BM_MapInsertSeq<Map<int, int>>/56                      1.05k ± 5%           1.05k ± 5%     ~     (p=0.727 n=57+57)
BM_MapInsertSeq<Map<int, int>>/224                     6.29k ± 5%           6.37k ± 4%   +1.32%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/3584                     124k ± 4%            109k ± 3%  -12.46%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/57344                   2.67M ± 4%           2.50M ± 4%   -6.40%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/917504                  65.3M ± 6%           65.8M ± 6%   +0.89%  (p=0.050 n=55+56)
BM_MapInsertSeq<Map<int, int>>/14680064                2.17G ±10%           2.14G ± 9%   -1.55%  (p=0.032 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/1                       122 ± 1%             122 ± 1%     ~     (p=0.415 n=56+56)
BM_MapInsertSeq<Map<int*, int*>>/2                       136 ± 1%             136 ± 1%     ~     (p=0.861 n=56+57)
BM_MapInsertSeq<Map<int*, int*>>/3                       153 ± 1%             153 ± 1%     ~     (p=0.607 n=56+57)
BM_MapInsertSeq<Map<int*, int*>>/4                       170 ± 2%             174 ± 3%   +2.34%  (p=0.001 n=56+57)
BM_MapInsertSeq<Map<int*, int*>>/8                       238 ± 4%             242 ± 3%   +1.59%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/16                      382 ± 4%             383 ± 4%     ~     (p=0.977 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/32                      701 ± 7%             682 ± 5%   -2.69%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/64                    2.13k ± 6%           2.09k ± 3%   -1.89%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/256                   10.3k ± 3%           10.2k ± 3%   -0.94%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/4096                   184k ± 2%            179k ± 2%   -2.62%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/65536                 3.63M ± 2%           3.68M ± 3%   +1.22%  (p=0.000 n=54+57)
BM_MapInsertSeq<Map<int*, int*>>/1048576                129M ±10%            129M ±10%     ~     (p=0.874 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/16777216              3.27G ±11%           3.24G ±10%     ~     (p=0.451 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/56                    1.18k ± 9%           1.10k ± 5%   -6.52%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/224                   6.76k ± 5%           6.59k ± 4%   -2.55%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/3584                   117k ± 2%            115k ± 3%   -1.93%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/57344                 2.22M ± 3%           2.24M ± 2%   +0.87%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/917504                95.0M ± 8%           94.8M ± 9%     ~     (p=0.894 n=55+57)
BM_MapInsertSeq<Map<int*, int*>>/14680064              2.42G ±14%           2.40G ±13%     ~     (p=0.852 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/1             124 ± 1%             124 ± 1%     ~     (p=0.604 n=56+55)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/2             140 ± 1%             140 ± 1%     ~     (p=0.181 n=56+56)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/3             158 ± 1%             158 ± 3%     ~     (p=1.000 n=56+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/4             176 ± 2%             176 ± 3%     ~     (p=0.125 n=56+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/8             247 ± 4%             247 ± 2%     ~     (p=0.614 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/16            391 ± 3%             391 ± 2%     ~     (p=0.993 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/32            690 ± 3%             691 ± 3%     ~     (p=0.224 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/64          2.17k ± 3%           2.22k ± 3%   +1.94%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/256         11.1k ± 3%           11.3k ± 3%   +1.58%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/4096         204k ± 2%            193k ± 2%   -5.65%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/65536       5.19M ± 3%           5.09M ± 3%   -2.05%  (p=0.000 n=56+56)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/1048576      124M ±10%            123M ± 6%     ~     (p=0.626 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/16777216    3.30G ± 9%           3.25G ± 8%   -1.39%  (p=0.019 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/56          1.12k ± 3%           1.12k ± 3%     ~     (p=0.482 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/224         7.04k ± 4%           7.14k ± 3%   +1.36%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/3584         138k ± 2%            126k ± 2%   -8.89%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/57344       3.48M ± 4%           3.34M ± 4%   -3.93%  (p=0.000 n=56+56)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/917504      84.4M ± 7%           84.9M ± 6%     ~     (p=0.159 n=56+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/14680064    2.42G ± 9%           2.40G ±10%     ~     (p=0.300 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/1             168 ± 0%             168 ± 0%     ~     (p=0.555 n=56+55)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/2             208 ± 0%             208 ± 0%     ~     (p=0.722 n=52+53)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/3             248 ± 0%             248 ± 0%     ~     (p=0.248 n=53+54)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/4             288 ± 0%             288 ± 0%     ~     (p=0.185 n=54+55)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/8             457 ± 0%             457 ± 0%     ~     (p=0.665 n=53+53)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/16            867 ± 1%             867 ± 1%     ~     (p=0.174 n=47+52)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/32          1.61k ± 3%           1.62k ± 4%     ~     (p=0.402 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/64          4.96k ± 9%           4.89k ± 5%   -1.37%  (p=0.046 n=57+54)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/256         26.9k ± 8%           26.5k ± 8%   -1.51%  (p=0.004 n=56+55)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/4096         600k ± 3%            588k ± 2%   -2.07%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/65536       13.9M ± 3%           13.5M ± 2%   -2.99%  (p=0.000 n=55+56)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/1048576      407M ± 7%            393M ± 5%   -3.27%  (p=0.000 n=56+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/16777216    10.2G ± 8%            9.9G ± 5%   -3.50%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/56          2.81k ± 5%           2.81k ± 4%     ~     (p=0.809 n=56+56)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/224         17.9k ± 6%           17.6k ± 5%   -1.20%  (p=0.035 n=57+52)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/3584         374k ± 3%            367k ± 3%   -1.80%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/57344       8.64M ± 3%           8.53M ± 2%   -1.29%  (p=0.000 n=55+55)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/917504       247M ± 6%            244M ± 5%   -1.19%  (p=0.021 n=56+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/14680064    6.81G ± 8%           6.64G ± 6%   -2.46%  (p=0.000 n=57+57)
```

Benchmarks on x86
```
name                                                  old cpu/op   new cpu/op   delta
BM_MapInsertSeq<Map<int, int>>/1                      32.9ns ± 3%  32.6ns ± 3%   -0.84%  (p=0.027 n=54+51)
BM_MapInsertSeq<Map<int, int>>/2                      35.9ns ± 3%  35.7ns ± 4%     ~     (p=0.123 n=54+54)
BM_MapInsertSeq<Map<int, int>>/3                      39.7ns ± 3%  47.4ns ± 4%  +19.40%  (p=0.000 n=55+56)
BM_MapInsertSeq<Map<int, int>>/4                      52.7ns ± 3%  52.1ns ± 4%   -1.22%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/8                      78.1ns ± 3%  78.3ns ± 3%     ~     (p=0.141 n=50+57)
BM_MapInsertSeq<Map<int, int>>/16                      135ns ± 3%   135ns ± 4%     ~     (p=0.936 n=53+57)
BM_MapInsertSeq<Map<int, int>>/32                      249ns ± 3%   241ns ± 3%   -3.28%  (p=0.000 n=55+57)
BM_MapInsertSeq<Map<int, int>>/64                      631ns ± 3%   618ns ± 3%   -2.21%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/256                    2.62µs ± 3%  2.36µs ± 4%  -10.02%  (p=0.000 n=52+53)
BM_MapInsertSeq<Map<int, int>>/4096                   39.2µs ± 3%  37.9µs ± 4%   -3.40%  (p=0.000 n=57+56)
BM_MapInsertSeq<Map<int, int>>/65536                   972µs ± 3%   955µs ± 3%   -1.76%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/1048576                16.2ms ± 4%  16.3ms ± 5%     ~     (p=0.231 n=52+54)
BM_MapInsertSeq<Map<int, int>>/16777216                651ms ± 3%   648ms ± 2%   -0.42%  (p=0.048 n=57+56)
BM_MapInsertSeq<Map<int, int>>/56                      418ns ± 3%   401ns ± 3%   -4.10%  (p=0.000 n=54+57)
BM_MapInsertSeq<Map<int, int>>/224                    1.79µs ± 3%  1.61µs ± 3%  -10.20%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, int>>/3584                   26.0µs ± 3%  24.9µs ± 4%   -4.13%  (p=0.000 n=57+56)
BM_MapInsertSeq<Map<int, int>>/57344                   560µs ± 3%   549µs ± 3%   -2.11%  (p=0.000 n=56+57)
BM_MapInsertSeq<Map<int, int>>/917504                 10.4ms ± 3%  10.4ms ± 3%     ~     (p=0.805 n=56+56)
BM_MapInsertSeq<Map<int, int>>/14680064                422ms ± 2%   421ms ± 3%     ~     (p=0.269 n=57+56)
BM_MapInsertSeq<Map<int*, int*>>/1                    33.7ns ± 3%  33.7ns ± 3%     ~     (p=0.620 n=55+55)
BM_MapInsertSeq<Map<int*, int*>>/2                    36.7ns ± 3%  36.5ns ± 3%     ~     (p=0.160 n=55+56)
BM_MapInsertSeq<Map<int*, int*>>/3                    41.1ns ± 2%  41.0ns ± 4%     ~     (p=0.284 n=54+56)
BM_MapInsertSeq<Map<int*, int*>>/4                    45.0ns ± 3%  53.9ns ± 4%  +19.70%  (p=0.000 n=57+56)
BM_MapInsertSeq<Map<int*, int*>>/8                    77.1ns ± 3%  80.9ns ± 4%   +4.98%  (p=0.000 n=55+57)
BM_MapInsertSeq<Map<int*, int*>>/16                    130ns ± 3%   136ns ± 4%   +4.42%  (p=0.000 n=56+57)
BM_MapInsertSeq<Map<int*, int*>>/32                    244ns ± 3%   246ns ± 4%   +0.95%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/64                    620ns ± 3%   674ns ± 3%   +8.83%  (p=0.000 n=55+57)
BM_MapInsertSeq<Map<int*, int*>>/256                  2.93µs ± 3%  2.88µs ± 3%   -1.73%  (p=0.000 n=56+56)
BM_MapInsertSeq<Map<int*, int*>>/4096                 54.0µs ± 3%  50.8µs ± 4%   -6.01%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/65536                1.18ms ± 2%  1.17ms ± 4%     ~     (p=0.083 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/1048576              28.9ms ± 4%  29.1ms ± 5%   +0.91%  (p=0.007 n=55+56)
BM_MapInsertSeq<Map<int*, int*>>/16777216              914ms ± 2%   919ms ± 3%   +0.56%  (p=0.015 n=56+57)
BM_MapInsertSeq<Map<int*, int*>>/56                    404ns ± 3%   427ns ± 4%   +5.60%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/224                  1.88µs ± 3%  1.87µs ± 4%   -0.68%  (p=0.013 n=55+53)
BM_MapInsertSeq<Map<int*, int*>>/3584                 34.2µs ± 3%  32.9µs ± 4%   -4.02%  (p=0.000 n=56+57)
BM_MapInsertSeq<Map<int*, int*>>/57344                 768µs ± 3%   756µs ± 3%   -1.53%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int*, int*>>/917504               16.4ms ± 5%  16.5ms ± 7%     ~     (p=0.303 n=56+57)
BM_MapInsertSeq<Map<int*, int*>>/14680064              607ms ± 2%   613ms ± 3%   +0.92%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/1          34.1ns ± 3%  34.2ns ± 4%     ~     (p=0.288 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/2          37.4ns ± 3%  37.5ns ± 3%     ~     (p=0.316 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/3          41.8ns ± 4%  49.1ns ± 3%  +17.45%  (p=0.000 n=57+56)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/4          54.6ns ± 3%  53.9ns ± 5%   -1.35%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/8          81.4ns ± 3%  81.4ns ± 4%     ~     (p=0.956 n=56+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/16          139ns ± 3%   139ns ± 3%     ~     (p=0.754 n=57+56)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/32          256ns ± 3%   250ns ± 4%   -2.32%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/64          705ns ± 4%   687ns ± 3%   -2.56%  (p=0.000 n=53+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/256        2.95µs ± 5%  3.05µs ± 3%   +3.42%  (p=0.000 n=52+55)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/4096       49.6µs ± 3%  50.8µs ± 4%   +2.44%  (p=0.000 n=55+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/65536      1.39ms ± 3%  1.40ms ± 3%   +0.65%  (p=0.004 n=57+56)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/1048576    37.7ms ± 4%  38.1ms ± 4%   +1.07%  (p=0.001 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/16777216    1.20s ± 3%   1.20s ± 3%   +0.50%  (p=0.040 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/56          432ns ± 3%   414ns ± 3%   -3.99%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/224        1.92µs ± 4%  1.89µs ± 4%   -1.48%  (p=0.000 n=52+55)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/3584       31.5µs ± 4%  32.1µs ± 4%   +1.89%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/57344       757µs ± 3%   748µs ± 3%   -1.28%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/917504     21.9ms ± 4%  22.1ms ± 5%     ~     (p=0.096 n=57+57)
BM_MapInsertSeq<Map<int, llvm::StringRef>>/14680064    735ms ± 3%   737ms ± 3%     ~     (p=0.208 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/1          41.5ns ± 3%  41.4ns ± 4%     ~     (p=0.790 n=54+56)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/2          50.6ns ± 4%  50.6ns ± 5%     ~     (p=0.684 n=53+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/3          59.7ns ± 4%  59.4ns ± 4%     ~     (p=0.277 n=55+53)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/4          68.5ns ± 5%  68.2ns ± 5%     ~     (p=0.623 n=54+55)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/8           107ns ± 5%   107ns ± 9%     ~     (p=0.359 n=54+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/16          200ns ± 6%   200ns ± 6%     ~     (p=0.772 n=56+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/32          373ns ± 8%   371ns ± 7%     ~     (p=0.541 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/64         1.11µs ± 9%  1.09µs ± 8%   -2.09%  (p=0.003 n=56+56)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/256        5.61µs ± 5%  5.48µs ± 7%   -2.42%  (p=0.000 n=54+56)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/4096        153µs ± 4%   147µs ± 6%   -3.80%  (p=0.000 n=54+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/65536      3.24ms ± 3%  3.10ms ± 3%   -4.19%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/1048576     100ms ± 2%    98ms ± 3%   -1.97%  (p=0.000 n=56+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/16777216    2.45s ± 2%   2.40s ± 3%   -2.09%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/56          637ns ± 8%   630ns ± 8%     ~     (p=0.101 n=56+56)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/224        3.77µs ± 6%  3.68µs ± 6%   -2.42%  (p=0.000 n=56+56)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/3584       92.1µs ± 7%  88.4µs ± 6%   -4.04%  (p=0.000 n=57+56)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/57344      1.99ms ± 4%  1.92ms ± 3%   -3.47%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/917504     62.1ms ± 4%  60.9ms ± 3%   -1.93%  (p=0.000 n=57+57)
BM_MapInsertSeq<Map<llvm::StringRef, int>>/14680064    1.53s ± 3%   1.50s ± 3%   -1.85%  (p=0.000 n=57+57)
```

---------

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
 2024-12-31 05:44:37 +00:00
Chandler Carruth a2af7ad8f0 Improve hashtable prefetching (#4585) 
I had removed most but not all of the hashtable prefetching during
development because I wasn't confident in the benchmarking results.
However, I never revisited this once the benchmarking infrastructure
improved and there were solid and stable results.

This factors the two interesting prefetch patterns I've seen for this
style of hashtable into helpers that are always called, and provides
macros that can be used during the build to configure exactly which
prefetch strategies are enabled.

Benchmarking these and gaining confidence is very frustrating -- even
now with the improved infrastructure, the noise is much higher than I
would like. But it seems clear that *some* prefetching is a significant
win. It also seems like enabling both results in too much prefetch
traffic. And the entry group prefetch appears to be significantly more
effective, both for the most interesting of the microbenchmarks and
maybe most importantly for our compilation benchmarks. There, AMD is
helped substantially and M1 seems to be helped some (although harder to
measure).

AMD server benchmark numbers:
```
name                                              old cpu/op   new cpu/op   delta
BM_CompileAPIFileDenseDecls<Phase::Lex>/256       35.0µs ± 2%  34.2µs ± 2%  -2.40%  (p=0.000 n=20+19)
BM_CompileAPIFileDenseDecls<Phase::Lex>/1024       156µs ± 2%   151µs ± 2%  -3.18%  (p=0.000 n=20+19)
BM_CompileAPIFileDenseDecls<Phase::Lex>/4096       625µs ± 1%   605µs ± 1%  -3.22%  (p=0.000 n=19+18)
BM_CompileAPIFileDenseDecls<Phase::Lex>/16384     2.79ms ± 1%  2.69ms ± 2%  -3.67%  (p=0.000 n=17+19)
BM_CompileAPIFileDenseDecls<Phase::Lex>/65536     12.1ms ± 1%  11.6ms ± 1%  -4.30%  (p=0.000 n=17+18)
BM_CompileAPIFileDenseDecls<Phase::Lex>/262144    56.6ms ± 1%  53.8ms ± 1%  -5.00%  (p=0.000 n=18+17)
BM_CompileAPIFileDenseDecls<Phase::Parse>/256     61.1µs ± 2%  61.7µs ± 1%  +0.87%  (p=0.000 n=19+19)
BM_CompileAPIFileDenseDecls<Phase::Parse>/1024     288µs ± 1%   290µs ± 1%  +0.55%  (p=0.004 n=20+20)
BM_CompileAPIFileDenseDecls<Phase::Parse>/4096    1.16ms ± 1%  1.16ms ± 1%  -0.54%  (p=0.000 n=17+19)
BM_CompileAPIFileDenseDecls<Phase::Parse>/16384   4.98ms ± 1%  4.91ms ± 1%  -1.39%  (p=0.000 n=20+19)
BM_CompileAPIFileDenseDecls<Phase::Parse>/65536   20.9ms ± 1%  20.5ms ± 1%  -1.86%  (p=0.000 n=20+19)
BM_CompileAPIFileDenseDecls<Phase::Parse>/262144  92.1ms ± 1%  90.2ms ± 1%  -2.12%  (p=0.000 n=18+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/256     1.16ms ± 2%  1.16ms ± 1%    ~     (p=0.931 n=19+19)
BM_CompileAPIFileDenseDecls<Phase::Check>/1024    2.17ms ± 2%  2.16ms ± 1%    ~     (p=0.247 n=20+19)
BM_CompileAPIFileDenseDecls<Phase::Check>/4096    6.07ms ± 1%  6.04ms ± 1%  -0.48%  (p=0.007 n=19+19)
BM_CompileAPIFileDenseDecls<Phase::Check>/16384   22.4ms ± 1%  22.2ms ± 1%  -0.99%  (p=0.000 n=20+19)
BM_CompileAPIFileDenseDecls<Phase::Check>/65536   93.3ms ± 1%  92.2ms ± 1%  -1.23%  (p=0.000 n=20+18)
BM_CompileAPIFileDenseDecls<Phase::Check>/262144   400ms ± 1%   391ms ± 1%  -2.15%  (p=0.000 n=20+18)
```
 2024-11-26 10:14:14 +00:00
Chandler CarruthRichard Smithjosh11b
 		4845f40dff Switch CARBON_CHECK to a format string API (#4285) 
This switches `DCHECK` and `FATAL` as well.

The goal is to reduce the code size impact of these assertions so that
we can keep more of them enabled. Currently, the largest cost I see from
`CHECK` is not the actual check or the cold code itself, but actually
the failure to inline trivial functions due to the presence of the cold
code. This means that our goal isn't to reduce apparent code size in the
final binary but the LLVM IR cost assessed for these routines in the
inliner, which closely correlates with code size but is a bit different.

As discussed in #4283, experimentation shows that a single function call
with a minimal number of arguments is the lowest cost model for these.
This is easily achieved with a format-string API that internally uses
`llvm::formatv`. This PR is essentially the `CHECK` version of #4283.

However, the check macros are substantially harder to make work with
both format strings and streaming because they also take a condition.
Also, unexpectedly, I was very successful at devising a regular
expression based automated rewrite from the streaming to the format
string form with only low 10s of manual fixes. This includes compacting
strings broken up across lines, etc. Given how well that went, I've
prepared this PR which just directly switches to the format string API
and migrate everything to use it.

One nice side-effect is that the format string approach ends up greatly
simplifying the implementation here as well.

This is ... *shockingly* effective. Parsing speeds up by more than 3%
with just this change. And checking speeds up by **8%** with this change
alone:
```
BM_CompileAPIFileDenseDecls<Phase::Parse>/256      86.3µs ± 1%  82.9µs ± 1%  -3.94%  (p=0.000 n=17+19)
BM_CompileAPIFileDenseDecls<Phase::Parse>/1024      431µs ± 1%   415µs ± 1%  -3.76%  (p=0.000 n=18+19)
BM_CompileAPIFileDenseDecls<Phase::Parse>/4096     1.77ms ± 1%  1.71ms ± 1%  -3.18%  (p=0.000 n=18+19)
BM_CompileAPIFileDenseDecls<Phase::Parse>/16384    7.44ms ± 1%  7.17ms ± 2%  -3.56%  (p=0.000 n=18+20)
BM_CompileAPIFileDenseDecls<Phase::Parse>/65536    30.7ms ± 1%  29.7ms ± 1%  -3.15%  (p=0.000 n=18+20)
BM_CompileAPIFileDenseDecls<Phase::Parse>/262144    131ms ± 1%   127ms ± 1%  -2.81%  (p=0.000 n=18+18)
BM_CompileAPIFileDenseDecls<Phase::Check>/256       878µs ± 2%   800µs ± 1%  -8.91%  (p=0.000 n=19+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/1024     1.88ms ± 2%  1.72ms ± 1%  -8.56%  (p=0.000 n=19+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/4096     5.78ms ± 2%  5.28ms ± 1%  -8.70%  (p=0.000 n=20+18)
BM_CompileAPIFileDenseDecls<Phase::Check>/16384    21.9ms ± 1%  20.1ms ± 1%  -8.02%  (p=0.000 n=18+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/65536    90.4ms ± 2%  83.1ms ± 1%  -8.04%  (p=0.000 n=19+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/262144    381ms ± 2%   352ms ± 1%  -7.79%  (p=0.000 n=19+19)
```

---------

Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
 2024-09-12 16:42:08 +00:00
Chandler Carruth a8748f3e2d Key context improvements (#4095) 
This injects a customization point for hashtable-specific equality
testing that the key context uses by default. While this is rarely
needed, there are LLVM types where it is necessary and it seems a good
general tool to have to avoid unnecessary complexity from custom key
contexts when a simple customization of equality is all that is
required.

This also adds a CRTP mixin for implementing a common pattern of key
contexts where the context provides translation of some key types into
another type, potentially using state. Rather than having to implement
the entire key context API, code can derive from this template and
simply provide a set of overloads for the types it wants to translate.
Any key types used which can be passed to one of those overloads will
get translated before following the same logic as the default key
context. While this updates the only usage so far of this pattern, a
subsequent PR will add several more users making the pattern worth
abstracting here.
 2024-07-02 21:20:14 +00:00
Chandler Carruth 6310293330 Fix some subtle UB found by MSan. (#4093) 
Technically, any small size buffer's lifetime has ended by the time we
get to the base's destructor. This means its no longer valid to access
table contents if stored there from the base destructor. We need to
handle destruction in the table class instead.

This ends up being a trivial change because the logic is already
factored out, we just need to call it from a different point.
 2024-06-29 07:44:34 +00:00
Chandler CarruthandRichard Smith af6312a3aa Add assignment support to the hashtables. (#4066) 
This lets copy and move assignment work. While it's a bit suboptimal to
do assignment with these tables, it still seems like an unreasonable
burden to not allow the basics to work. Even the toolchain ended up
doing this in a few places.

---------

Co-authored-by: Richard Smith <richard@metafoo.co.uk>
 2024-06-21 21:49:56 +00:00
Chandler Carruthandjosh11b 07fadc6474 Add growth API to the new hashtables. (#4044) 
This adds two different growth APIs. This is instead of the more
conventional STL `reserve` method. One allows users that aren't trying
to grow in anticipation of an *exact* count of insertions, but generally
trying to size the table to the correct ballpark with a power-of-two
estimate.

The other API allows pre-growing to allow a specific number of
insertions to be performed without further growth. This API takes the
maximum load factor and other implementation details into account.

---------

Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
 2024-06-12 19:38:35 +00:00
Chandler CarruthandRichard Smith 3be57b71e0 Collect more detailed metrics on hashtables. (#4046) 
Previously we just looked at the raw count of probed keys. Now, we
compute the average and max of both the probe _distance_ measured in the
number of _groups_ probed, and the number of probe _compares_ measured
in the compares required _before_ finding the matching entry.

This lets us understand the relative impact of probe-distance vs. tag
collisions on a given set of benchmark keys. Some of this is motivated
by considering additional optimization techniques similar to those used
in Boost's table and the F14 table from Facebook/Meta.

---------

Co-authored-by: Richard Smith <richard@metafoo.co.uk>
 2024-06-10 21:43:13 +00:00
Chandler Carruthandjosh11b 21a81bc59e Introduce custom hash table data structures. (#3940) 
The hash table design is heavily based on Abseil's ["Swiss
Tables"][swiss-tables] design. It uses an array of bytes storing
metadata about each entry and an array of entries where each is a pair
of key and value. The metadata byte consists of 7-bits of hash of the
key (distinct from the bits used to index the table), and one bit
indicating the presence of a special entry -- either empty or deleted.

[swiss-tables]: https://abseil.io/about/design/swisstables

There are a large range of optimizations and other nuanced aspects of
this hash table design and implementation, a good point to understand
that context is `raw_hashtable.h` which has an overview of the design
and references to various other files for relevant details.

---------

Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
 2024-06-08 01:50:02 +00:00