| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
PiperOrigin-RevId: 647359155
Change-Id: I5aba1169b01a74c4431f5ee3788b490124eeaa65
|
|
|
|
|
| |
PiperOrigin-RevId: 647340145
Change-Id: I4b0076595dbda1f81ffdc32adad2dc1e35cb9e04
|
|
|
|
|
|
|
|
|
| |
`absl::erase_if`.
Since we have potential plans to use this function more widely including `absl::c_for_each`, we need to have good error detection.
PiperOrigin-RevId: 647236725
Change-Id: I5035bfb8cef24f80f1bbed83a42380e57d84e428
|
|
|
|
|
| |
PiperOrigin-RevId: 647093624
Change-Id: Ic76bfa4aa8fb616cb23095ce7bfa30c3812dcb21
|
|
|
|
|
|
|
| |
These functions are based on the C++23's `std::ranges::contains()` and `std::ranges::contains_subrange()` functions, see: https://en.cppreference.com/w/cpp/algorithm/ranges/contains
PiperOrigin-RevId: 647084955
Change-Id: If5a01784e3cf1cc4d88e7f2fef92a3701fafc886
|
|
|
|
|
|
|
| |
This is portable because cord already has `operator<` etc., which will be unaffected. This just allows C++ >= 20 users to explicitly call `operator<=>`.
PiperOrigin-RevId: 646951415
Change-Id: I1432e224bd5dc09b99d56a1d27e95078463adf45
|
|
|
|
|
| |
PiperOrigin-RevId: 646949076
Change-Id: I0d3fc57aee38e5b3a5b85e2301f5035bfd0e388b
|
|
|
|
|
| |
PiperOrigin-RevId: 646614152
Change-Id: Iee853bdc6f753d758c850a529a6adb05d0d0b1a7
|
|
|
|
|
|
|
| |
The motivation is to make destroyed/moved-from objects cause crashes when they are accessed.
PiperOrigin-RevId: 646229564
Change-Id: I68d9c189b542df0933af08f5ad63dc1f5764d856
|
|
|
|
|
| |
PiperOrigin-RevId: 646172195
Change-Id: I089f1d84f2d73b663f12e6818f96436e054e71ae
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PiperOrigin-RevId: 646105357
Change-Id: Ia76c1ce33faf811e988d36747f187c112ccb967e
|
|
|
|
|
| |
PiperOrigin-RevId: 646031348
Change-Id: I212e34a0b89293bd9f0081047bb5a1eba5d04bcb
|
|
|
|
|
|
|
|
| |
`optimization.h` needs to be compatible with C.
`#include <utility>` is C++-only.
PiperOrigin-RevId: 645651894
Change-Id: I55ebc3369b05788346cd0ab684b50bdfc2345fd4
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 8a28a0c8732ba3bf0191fb6292fcad6e5948a047
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
|
|
|
|
|
| |
PiperOrigin-RevId: 645286828
Change-Id: I00efdf1bf774daafbd34c898cf4a524852b638e0
|
|
|
|
|
|
|
|
|
| |
IterateOverFullSlots.
We decided to not allow reentrance in absl::erase_if and absl::container_internal::c_for_each_fast.
PiperOrigin-RevId: 645273965
Change-Id: I75dfc73b93ba10f0e051bf0833723af887e1bb36
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PiperOrigin-RevId: 645054874
Change-Id: Ic4a820b47edfa71bd3e1f149d54f00ac3c1d16a6
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PiperOrigin-RevId: 644150551
Change-Id: I11f3f8463fcfdb8d0284b1ab320624bbce6d1e48
|
|
|
|
|
|
|
| |
attributes to more types in Abseil
PiperOrigin-RevId: 643946867
Change-Id: Ia4fb583872dabd72c48cc4c20fe23a64dea517a6
|
|
|
|
|
| |
PiperOrigin-RevId: 643418422
Change-Id: Ib16cfef8ddedc8366df49ca75ab02eb60af08f26
|
|
|
|
|
|
|
| |
continued flakiness.
PiperOrigin-RevId: 643372086
Change-Id: I8fb2acc0e5ad35113e865bf008a531f3442a9295
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PiperOrigin-RevId: 643024432
Change-Id: Id07aa18d186291442f7b6f3c68ef8dd6cc20b434
|
|
|
|
|
| |
PiperOrigin-RevId: 642757934
Change-Id: I6dffe81e5173201b80a107b951fe1c69b20972f5
|
|
|
|
|
| |
PiperOrigin-RevId: 642696557
Change-Id: Ia6b8e174ddb55e44bd082bf0d81d2f9c53c94016
|
|
|
|
|
| |
PiperOrigin-RevId: 642621989
Change-Id: I95efa4bd9fe8fe3c449304706401374f851f0fbe
|
|
|
|
|
|
|
| |
attributes to types in Abseil
PiperOrigin-RevId: 642619703
Change-Id: I8d2e423a3c7f40709d0e8c82cac0395c75d601cf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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
|
|
|
|
|
| |
PiperOrigin-RevId: 641983507
Change-Id: Iad7933884aef6bfd90d159c049a1d698d19456c6
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/1689
Merge c755474cd03d3da0efa68ec0605b183d24bfd5d6 into 2f61aed18c4affd3a75a2b2d2468d23f2f16192a
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
|
|
|
|
|
| |
PiperOrigin-RevId: 641893938
Change-Id: I8a21e322c9cf1d5dab7477af5367aad134fbf2ab
|
|
|
|
|
| |
PiperOrigin-RevId: 641418373
Change-Id: I2999228cccfd18a000725b938a692c0c9004867c
|
|
|
|
|
| |
PiperOrigin-RevId: 641411131
Change-Id: Icba1307cccb8957e09f087a7b544f7fe8bfd8333
|
|
|
|
|
| |
PiperOrigin-RevId: 641400156
Change-Id: Ib9f6e4f6c4bbd6d3234dfd322d1d14a59b08d88a
|
|
|
|
|
| |
PiperOrigin-RevId: 641360162
Change-Id: Iabce55eb61feaa4dc099093a6496e26ab66906fa
|
|
|
|
|
| |
PiperOrigin-RevId: 641324572
Change-Id: Ie266da9c8c702e62b89352d64870fb41d2ea76c3
|
|
|
|
|
| |
PiperOrigin-RevId: 641310017
Change-Id: I0f10a2a1965e842db4efda455e0cdfbeb6656fa5
|
|
|
|
|
| |
PiperOrigin-RevId: 641291188
Change-Id: I02f6bae62b05c8964a3b6e8f78299061ce57e01a
|
|
|
|
|
| |
PiperOrigin-RevId: 641271471
Change-Id: Ibeedb4dea3b961955d073f048d293b19aa917792
|
|
|
|
|
| |
PiperOrigin-RevId: 641249074
Change-Id: Id410ce6c3b7a9a2b10aedf9c70ec65d3e37af06d
|
|
|
|
|
| |
PiperOrigin-RevId: 641046309
Change-Id: Iaa2564a60035421969c2cd6074a457980083cbd2
|
|
|
|
|
| |
PiperOrigin-RevId: 641011959
Change-Id: I844d4eb99a9f9da160bb53e491dee753a70750df
|
|
|
|
|
| |
PiperOrigin-RevId: 640993627
Change-Id: I84073099907a3634eca4b12cd2e633908465907a
|