- 24 Jun, 2024 3 commits
-
-
windows_clangcl_bazel.bat includes a change from --copt to --cxxopt to only pass /std:c++XX to C++ compiles PiperOrigin-RevId: 646157298 Change-Id: Ib6d9861a2b2d45eb0d664f23b6f3a7426f8e0ab3
Derek Mauro committed -
PiperOrigin-RevId: 646105357 Change-Id: Ia76c1ce33faf811e988d36747f187c112ccb967e
Anthony Lai committed -
PiperOrigin-RevId: 646031348 Change-Id: I212e34a0b89293bd9f0081047bb5a1eba5d04bcb
Tanvi Jagtap committed
-
- 22 Jun, 2024 2 commits
-
-
`optimization.h` needs to be compatible with C. `#include <utility>` is C++-only. PiperOrigin-RevId: 645651894 Change-Id: I55ebc3369b05788346cd0ab684b50bdfc2345fd4
Abseil Team committed -
Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/1692 `optimization.h` uses `std::unreachable()` if available but does not include `<utility>`, causing errors in `absl/strings/ascii.cc`. Merge bf912bb4e38341d6152ee145ec2be00251c42552 into 8a28a0c8 Merging this change closes #1692 COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1692 from poconn:optimization_missing_include bf912bb4e38341d6152ee145ec2be00251c42552 PiperOrigin-RevId: 645643983 Change-Id: I3966984afa81f2f6bce65dd872d326f0af114bfa
Patrick O'Connell committed
-
- 21 Jun, 2024 2 commits
-
-
PiperOrigin-RevId: 645286828 Change-Id: I00efdf1bf774daafbd34c898cf4a524852b638e0
Vitaly Goldshteyn committed -
We decided to not allow reentrance in absl::erase_if and absl::container_internal::c_for_each_fast. PiperOrigin-RevId: 645273965 Change-Id: I75dfc73b93ba10f0e051bf0833723af887e1bb36
Vitaly Goldshteyn committed
-
- 20 Jun, 2024 3 commits
-
-
This function is aimed to achieve faster iteration through the entire hash table. It is not ready to be used by the public and stays in `container_internal` namespace. Differences with `absl::c_for_each`: 1. No guarantees on order of iteration. Although for the hash table it is partially not guaranteed already. But we do not even guarantee that it is the same order as in the for loop range. De facto, the order is the same at the moment. 2. No mutating reentrance is allowed. Most notably erasing from the hash_table is not allowed. Based on microbenchmarks, there are following conclusions: 1. c_for_each_fast is clearly faster on big tables with 20-60% speedup. 2. Microbenchmarks show regression on a full small table without any empty slots. We should avoid recommending that for small tables. 3. It seems reasonable to use `c_for_each_fast` in places, where `skip_empty_or_deleted` has significant GCU usage. `skip_empty_or_deleted` usage signals that there are "gaps" between elements, so `c_for_each_fast` should be an improvement. PiperOrigin-RevId: 645142512 Change-Id: I279886b8c8b2545504c2bf7e037d27b2545e044d
Vitaly Goldshteyn committed -
PiperOrigin-RevId: 645054874 Change-Id: Ic4a820b47edfa71bd3e1f149d54f00ac3c1d16a6
Evan Brown committed -
For performance reasons, these containers are optimized for the case in which allocations/deallocations/comparisons/hashers can't throw exceptions. PiperOrigin-RevId: 645054627 Change-Id: I99be651b26f5bbb87da6ef246b92b20a375224d7
Evan Brown committed
-
- 18 Jun, 2024 1 commit
-
-
This is a replacement for the `absl_nullability_compatible` tag. The attribute has the advantage that, unlike the tag, it can be applied to forward declarations. This does not yet change the implementation of the nullability annotations -- that will come in a followup patch. As the nullability annotations themselves have not been changed, the `absl_nullability_compatible` tag is currently still used to check whether the annotations can be applied to a given type; see also the comments in the code. PiperOrigin-RevId: 644238698 Change-Id: I5882606f82ce7a6dd98e83e6d920573437561b50
Martin Brænne committed
-
- 17 Jun, 2024 2 commits
-
-
PiperOrigin-RevId: 644150551 Change-Id: I11f3f8463fcfdb8d0284b1ab320624bbce6d1e48
Abseil Team committed -
Add ABSL_INTERNAL_ATTRIBUTE_VIEW and ABSL_INTERNAL_ATTRIBUTE_OWNER attributes to more types in Abseil PiperOrigin-RevId: 643946867 Change-Id: Ia4fb583872dabd72c48cc4c20fe23a64dea517a6
Abseil Team committed
-
- 14 Jun, 2024 2 commits
-
-
PiperOrigin-RevId: 643418422 Change-Id: Ib16cfef8ddedc8366df49ca75ab02eb60af08f26
Chris Mihelich committed -
PiperOrigin-RevId: 643372086 Change-Id: I8fb2acc0e5ad35113e865bf008a531f3442a9295
Evan Brown committed
-
- 13 Jun, 2024 2 commits
-
-
This makes MockUniform fail if the action is specified to return an out of bounds value. Examples that will fail: absl::Uniform(gen, 1, 4) -> 42 absl::Uniform(gen, 1, 4) -> 4: [1, 4) absl::Uniform(absl::IntervalOpenClosed, gen, 1, 4) -> 1: (1, 4] Examples that will pass: absl::Uniform(gen, 1, 4) -> 3 absl::Uniform(gen, 1, 4) -> 1: [1, 4) absl::Uniform(absl::IntervalClosed, gen, 1, 4) -> 4: [1, 4] Special case: the empty range always returns its boundary, so this case passes: absl::Uniform(absl::IntervalOpen, 1, 1) -> 1: (1, 1) If this breaks your test, your test has a bug: it's relying on an absl::Uniform() call that returns an impossible value. The UnvalidatedMockingBitGen type temporarily exists to allow for disabling the validation to give a bit of time to fix the test, but this type will go away soon. PiperOrigin-RevId: 643090275 Change-Id: I23470fa9e1efbcb42fa3866237038414545c7be2
Justin Bassett committed -
PiperOrigin-RevId: 643024432 Change-Id: Id07aa18d186291442f7b6f3c68ef8dd6cc20b434
Derek Mauro committed
-
- 12 Jun, 2024 4 commits
-
-
PiperOrigin-RevId: 642757934 Change-Id: I6dffe81e5173201b80a107b951fe1c69b20972f5
Chris Mihelich committed -
PiperOrigin-RevId: 642696557 Change-Id: Ia6b8e174ddb55e44bd082bf0d81d2f9c53c94016
Chris Mihelich committed -
PiperOrigin-RevId: 642621989 Change-Id: I95efa4bd9fe8fe3c449304706401374f851f0fbe
Derek Mauro committed -
PiperOrigin-RevId: 642619703 Change-Id: I8d2e423a3c7f40709d0e8c82cac0395c75d601cf
Abseil Team committed
-
- 11 Jun, 2024 1 commit
-
-
Predicates should generally have no side effects since we do not guarantee the order or quantity for the calls. In this change we forbid one specific side effect: modification of the table we are iterating over. As a positive effect we have performance improvements (less computations and less branches). ``` name old cpu/op new cpu/op delta BM_EraseIf/num_elements:10/num_erased:0 3.02ns ± 2% 2.79ns ± 3% -7.44% (p=0.000 n=35+37) BM_EraseIf/num_elements:1000/num_erased:0 2.41ns ± 5% 2.05ns ± 4% -14.88% (p=0.000 n=37+37) BM_EraseIf/num_elements:10/num_erased:5 4.40ns ± 3% 4.22ns ± 3% -4.19% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:500 9.16ns ± 4% 9.13ns ± 3% ~ (p=0.307 n=37+37) BM_EraseIf/num_elements:10/num_erased:10 5.77ns ± 3% 5.50ns ± 4% -4.62% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:1000 7.84ns ± 3% 7.77ns ± 3% -0.94% (p=0.006 n=37+35) name old time/op new time/op delta BM_EraseIf/num_elements:10/num_erased:0 3.02ns ± 2% 2.79ns ± 3% -7.48% (p=0.000 n=35+36) BM_EraseIf/num_elements:1000/num_erased:0 2.41ns ± 5% 2.05ns ± 4% -14.89% (p=0.000 n=37+37) BM_EraseIf/num_elements:10/num_erased:5 4.42ns ± 3% 4.23ns ± 3% -4.22% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:500 9.18ns ± 4% 9.15ns ± 3% ~ (p=0.347 n=37+37) BM_EraseIf/num_elements:10/num_erased:10 5.79ns ± 3% 5.52ns ± 4% -4.61% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:1000 7.87ns ± 3% 7.79ns ± 3% -0.95% (p=0.007 n=37+35) name old INSTRUCTIONS/op new INSTRUCTIONS/op delta BM_EraseIf/num_elements:10/num_erased:0 14.9 ± 0% 12.9 ± 0% -13.46% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:0 12.7 ± 0% 10.3 ± 0% -18.76% (p=0.000 n=37+37) BM_EraseIf/num_elements:10/num_erased:5 30.9 ± 0% 28.9 ± 0% -6.48% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:500 37.6 ± 0% 35.3 ± 0% -6.33% (p=0.000 n=37+37) BM_EraseIf/num_elements:10/num_erased:10 46.9 ± 0% 44.9 ± 0% -4.27% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:1000 62.6 ± 0% 60.2 ± 0% -3.80% (p=0.000 n=37+36) name old CYCLES/op new CYCLES/op delta BM_EraseIf/num_elements:10/num_erased:0 4.91 ± 1% 4.11 ± 1% -16.35% (p=0.000 n=36+35) BM_EraseIf/num_elements:1000/num_erased:0 7.74 ± 2% 6.54 ± 2% -15.54% (p=0.000 n=37+37) BM_EraseIf/num_elements:10/num_erased:5 9.18 ± 3% 8.45 ± 3% -7.88% (p=0.000 n=37+35) BM_EraseIf/num_elements:1000/num_erased:500 29.5 ± 1% 29.3 ± 1% -0.82% (p=0.000 n=36+37) BM_EraseIf/num_elements:10/num_erased:10 13.5 ± 1% 12.6 ± 0% -7.06% (p=0.000 n=33+34) BM_EraseIf/num_elements:1000/num_erased:1000 25.1 ± 0% 24.9 ± 0% -0.90% (p=0.000 n=37+35) ``` PiperOrigin-RevId: 642318040 Change-Id: I78a4a5a9a5881db0818225f9c7c153c562009f66
Vitaly Goldshteyn committed
-
- 10 Jun, 2024 6 commits
-
-
There is no reason a temporary *shouldn't* be usable with BitGenRef (indeed, ABSL_ATTRIBUTE_LIFETIME_BOUND should catch errors) and it is useful when passing a temporary bitgen as an input argument. PiperOrigin-RevId: 642021132 Change-Id: I03e46f5f437e40a0c6225ea1f0361475a3501513
Abseil Team committed -
`EraseIf` itself is not very hot function, but I want to use that as demonstration of the speed of iteration via `IterateOverFullSlots`. Motivation: 1. We are still going to save some resources. 2. It is the first step to implement faster `absl::c_for_each` that may give larger benefits. Will require readability considerations. `BM_EraseIf/num_elements:1000/num_erased:0` is just iteration and it gives 60% speed up. On smaller tables removing all elements shows 25% speed up. Note that on small tables erasing is much faster due to cl/592272653. ``` name old cpu/op new cpu/op delta BM_EraseIf/num_elements:10/num_erased:0 3.41ns ± 5% 3.03ns ± 3% -11.14% (p=0.000 n=37+35) BM_EraseIf/num_elements:1000/num_erased:0 6.06ns ± 3% 2.42ns ± 3% -60.05% (p=0.000 n=34+37) BM_EraseIf/num_elements:10/num_erased:5 5.90ns ± 3% 4.44ns ± 4% -24.88% (p=0.000 n=36+37) BM_EraseIf/num_elements:1000/num_erased:500 11.0ns ± 2% 9.2ns ± 2% -16.60% (p=0.000 n=35+37) BM_EraseIf/num_elements:10/num_erased:10 8.03ns ± 3% 5.77ns ± 2% -28.19% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:1000 9.00ns ± 3% 7.83ns ± 2% -12.98% (p=0.000 n=37+37) name old time/op new time/op delta BM_EraseIf/num_elements:10/num_erased:0 3.42ns ± 5% 3.04ns ± 3% -11.13% (p=0.000 n=37+36) BM_EraseIf/num_elements:1000/num_erased:0 6.07ns ± 3% 2.42ns ± 3% -60.10% (p=0.000 n=34+37) BM_EraseIf/num_elements:10/num_erased:5 5.93ns ± 3% 4.45ns ± 4% -24.89% (p=0.000 n=36+37) BM_EraseIf/num_elements:1000/num_erased:500 11.1ns ± 2% 9.2ns ± 2% -16.61% (p=0.000 n=35+37) BM_EraseIf/num_elements:10/num_erased:10 8.06ns ± 3% 5.79ns ± 2% -28.19% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:1000 9.03ns ± 3% 7.85ns ± 2% -12.98% (p=0.000 n=37+37) name old INSTRUCTIONS/op new INSTRUCTIONS/op delta BM_EraseIf/num_elements:10/num_erased:0 19.5 ± 1% 14.9 ± 0% -23.79% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:0 19.9 ± 0% 12.7 ± 0% -36.20% (p=0.000 n=37+37) BM_EraseIf/num_elements:10/num_erased:5 36.9 ± 1% 30.9 ± 0% -16.47% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:500 44.8 ± 0% 37.6 ± 0% -16.06% (p=0.000 n=37+37) BM_EraseIf/num_elements:10/num_erased:10 53.0 ± 1% 46.9 ± 0% -11.61% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:1000 69.8 ± 0% 62.6 ± 0% -10.32% (p=0.000 n=36+37) name old CYCLES/op new CYCLES/op delta BM_EraseIf/num_elements:10/num_erased:0 6.10 ± 7% 4.91 ± 1% -19.49% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:0 19.4 ± 1% 7.7 ± 2% -60.04% (p=0.000 n=37+37) BM_EraseIf/num_elements:10/num_erased:5 13.9 ± 4% 9.2 ± 3% -33.80% (p=0.000 n=37+37) BM_EraseIf/num_elements:1000/num_erased:500 35.5 ± 0% 29.5 ± 1% -16.74% (p=0.000 n=37+37) BM_EraseIf/num_elements:10/num_erased:10 20.8 ± 5% 13.5 ± 0% -35.07% (p=0.000 n=37+30) BM_EraseIf/num_elements:1000/num_erased:1000 28.9 ± 0% 25.1 ± 0% -13.06% (p=0.000 n=37+37) ``` PiperOrigin-RevId: 642016364 Change-Id: I8be6af5916bd45fd110bb0398c3ffe932a6a083f
Vitaly Goldshteyn committed -
PiperOrigin-RevId: 641983507 Change-Id: Iad7933884aef6bfd90d159c049a1d698d19456c6
Chris Mihelich committed -
It’s not clear whether negative NaN floats are supposed to print as "-nan" or "nan" on RISC-V (https://cplusplus.github.io/LWG/issue4101). Until that’s resolved, don’t require that logging such a float with Abseil produce the same result as streaming it to an ostream does. Closes: https://github.com/abseil/abseil-cpp/issues/1684 PiperOrigin-RevId: 641942176 Change-Id: Iec7ef130cc15c114714f2d124cb37886b3c37ab4
Benjamin Barenblat committed -
Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/1689 Merge c755474cd03d3da0efa68ec0605b183d24bfd5d6 into 2f61aed1 Merging this change closes #1689 COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1689 from rschu1ze:missing-quotes c755474cd03d3da0efa68ec0605b183d24bfd5d6 PiperOrigin-RevId: 641896976 Change-Id: Iaf565a13ad639543c2f1ba698aefd18f8f48bede
Robert Schulze committed -
PiperOrigin-RevId: 641893938 Change-Id: I8a21e322c9cf1d5dab7477af5367aad134fbf2ab
Chris Mihelich committed
-
- 08 Jun, 2024 3 commits
-
-
PiperOrigin-RevId: 641418373 Change-Id: I2999228cccfd18a000725b938a692c0c9004867c
Chris Mihelich committed -
PiperOrigin-RevId: 641411131 Change-Id: Icba1307cccb8957e09f087a7b544f7fe8bfd8333
Chris Mihelich committed -
PiperOrigin-RevId: 641400156 Change-Id: Ib9f6e4f6c4bbd6d3234dfd322d1d14a59b08d88a
Chris Mihelich committed
-
- 07 Jun, 2024 6 commits
-
-
PiperOrigin-RevId: 641360162 Change-Id: Iabce55eb61feaa4dc099093a6496e26ab66906fa
Chris Mihelich committed -
PiperOrigin-RevId: 641324572 Change-Id: Ie266da9c8c702e62b89352d64870fb41d2ea76c3
Chris Mihelich committed -
PiperOrigin-RevId: 641310017 Change-Id: I0f10a2a1965e842db4efda455e0cdfbeb6656fa5
Chris Mihelich committed -
PiperOrigin-RevId: 641291188 Change-Id: I02f6bae62b05c8964a3b6e8f78299061ce57e01a
Chris Mihelich committed -
PiperOrigin-RevId: 641271471 Change-Id: Ibeedb4dea3b961955d073f048d293b19aa917792
Chris Mihelich committed -
PiperOrigin-RevId: 641249074 Change-Id: Id410ce6c3b7a9a2b10aedf9c70ec65d3e37af06d
Chris Mihelich committed
-
- 06 Jun, 2024 3 commits
-
-
PiperOrigin-RevId: 641046309 Change-Id: Iaa2564a60035421969c2cd6074a457980083cbd2
Chris Mihelich committed -
PiperOrigin-RevId: 641011959 Change-Id: I844d4eb99a9f9da160bb53e491dee753a70750df
Chris Mihelich committed -
PiperOrigin-RevId: 640993627 Change-Id: I84073099907a3634eca4b12cd2e633908465907a
Chris Mihelich committed
-