mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 11:10:11 +01:00
Replaces the callback-based `ForEach` methods on `RawHashtable`, `Map`,
and
`Set` with a range object supporting range-for loops, structured
bindings, and
the standard range concepts.
- Adds `.entries()` on `Map`, `Set`, and `RawHashtable`, returning a
range that
models `std::ranges::forward_range` and `std::ranges::common_range`.
Obtaining one is an explicit call rather than `begin()`/`end()` on the
container, as scanning a whole table is costly and shouldn't be hidden.
- Iterating a `Map` yields a `std::pair` of key and value references,
which
fits in two registers and is returned without being materialized in
memory.
- `Map::Range` and `Set::Range` are aliases of the raw hashtable's range
rather
than wrappers around it. The raw iterator produces the user-facing
reference
itself -- a `KeyT&` for a set, a pair of references for a map -- picked
by
`StorageEntry`, which is already specialized on whether there is a value
type. That leaves one iterator to reason about instead of three.
- Deletes the rvalue `.entries()` overloads on the owning containers, as
a
range built from a temporary table would dangle. Views don't own their
storage, so the operation remains available on them.
- In release builds, the walk over the groups is a single induction
variable: a
negative byte offset counting up to zero, anchored at the ends of the
metadata and entry arrays. Both arrays are then reached by indexed
addressing
off a base that stays put, and the entry pointer is formed only once a
group
with a present entry has been found.
- In debug builds, the range hashes the table's metadata when it is
built and
re-checks that hash when it is destroyed, catching mutation of the table
while a range is live. It also picks a random starting group and a
random odd
group stride, which varies the traversal order between ranges while
still
visiting every group exactly once. That entropy is drawn when the range
is
built rather than in `begin()`, so `begin()` stays a pure function of
the
range and the multi-pass guarantee holds.
- Removes `ForEachEntry` and all of its callers.
Measured against the iteration benchmark added in its own commit, a
traversal is at or ahead of what the callback compiled to across nearly
the
whole size range. The largest tables spend 3-5% fewer cycles, small
`Set`s as
much as 24% fewer, and instruction counts stay within about 1%. What
remains
behind is a handful of mid-sized `Map`s by up to 1%, and `Set` at 65536,
which
sits at exactly half its load factor, by 2%.
Both revisions were built with `-c opt --copt=-march=x86-64-v3` and
compared
with:
```
./scripts/bench_runner.py --exp_benchmark=... --base_benchmark=... \
--benchmark_args=--benchmark_perf_counters=INSTRUCTIONS,CYCLES \
--benchmark_args='--benchmark_filter=(Set|Map)Iterate<(Set|Map)<' \
--extra_metrics_filter='(INSTRUCTIONS|CYCLES)'
```
Trimmed below to the primary integer configurations and to the two
counters;
the pointer- and string-keyed configurations follow the same pattern.
```
Benchmark ┃ CYCLES ┃ INSTRUCTIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
BM_MapIterate<Map<int, int>>/1....... │ 👍 -6.032% p=1.14e-05 │ ?? p=0.752
baseline: │ 12.06 ± 1.520% │ 64 ± 3.125%
experiment: │ 11.33 ± 2.765% │ 65.5 ± 3.817%
│ │
BM_MapIterate<Map<int, int>>/2....... │ ?? p=0.155 │ ?? p=0.343
baseline: │ 7.587 ± 1.285% │ 41 ± 0.000%
experiment: │ 7.652 ± 0.865% │ 41 ± 2.439%
│ │
BM_MapIterate<Map<int, int>>/3....... │ ?? p=0.343 │ 👍 -1.020% p=0.0039
baseline: │ 6.663 ± 4.260% │ 32.67 ± 2.041%
experiment: │ 6.368 ± 12.224% │ 32.33 ± 2.062%
│ │
BM_MapIterate<Map<int, int>>/4....... │ ?? p=0.343 │ 👍 -1.786% p=0.0297
baseline: │ 6.091 ± 15.470% │ 28 ± 3.571%
experiment: │ 5.957 ± 8.932% │ 27.5 ± 3.636%
│ │
BM_MapIterate<Map<int, int>>/8....... │ ?? p=0.323 │ 👍 -1.220% p=0.000148
baseline: │ 4.845 ± 0.800% │ 20.5 ± 0.000%
experiment: │ 4.814 ± 3.585% │ 20.25 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/16...... │ 👍 -2.195% p=0.00908 │ 👍 0.769% p=6.58e-06
baseline: │ 4.312 ± 0.187% │ 16.25 ± 0.000%
experiment: │ 4.218 ± 2.368% │ 16.13 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/32...... │ ?? p=0.236 │ 👍 0.442% p=9.53e-06
baseline: │ 4.051 ± 1.084% │ 14.13 ± 0.000%
experiment: │ 4.063 ± 0.737% │ 14.06 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/64...... │ ?? p=0.693 │ 👎 0.227% p=4.52e-06
baseline: │ 4.021 ± 0.239% │ 13.75 ± 0.000%
experiment: │ 4.019 ± 0.417% │ 13.78 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/256..... │ 👍 0.360% p=0.00119 │ 👎 0.754% p=1.37e-05
baseline: │ 3.996 ± 0.173% │ 13.47 ± 0.000%
experiment: │ 3.982 ± 0.272% │ 13.57 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/4096.... │ 👍 0.581% p=1.96e-05 │ 👎 0.923% p=1.96e-05
baseline: │ 4.005 ± 0.816% │ 13.38 ± 0.000%
experiment: │ 3.981 ± 0.192% │ 13.5 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/65536... │ 👍 -4.957% p=1.14e-05 │ 👎 0.934% p=1.14e-05
baseline: │ 5.307 ± 0.501% │ 13.38 ± 0.000%
experiment: │ 5.044 ± 1.746% │ 13.5 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/1048576. │ 👍 -3.947% p=9.09e-05 │ 👎 0.935% p=3.3e-05
baseline: │ 6.074 ± 0.807% │ 13.38 ± 0.000%
experiment: │ 5.834 ± 2.159% │ 13.5 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/16777216 │ ?? p=0.155 │ 👎 0.935% p=2.11e-05
baseline: │ 5.082 ± 3.650% │ 13.38 ± 0.000%
experiment: │ 5.012 ± 1.316% │ 13.5 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/56...... │ 👎 0.825% p=0.0268 │ 👍 0.270% p=1.14e-05
baseline: │ 3.918 ± 0.501% │ 13.21 ± 0.000%
experiment: │ 3.951 ± 0.342% │ 13.18 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/224..... │ 👎 0.788% p=0.000504 │ 👎 0.346% p=1.64e-05
baseline: │ 3.895 ± 0.111% │ 12.89 ± 0.000%
experiment: │ 3.926 ± 0.285% │ 12.94 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/3584.... │ 👎 1.028% p=0.000148 │ 👎 0.545% p=1.14e-05
baseline: │ 3.913 ± 0.427% │ 12.79 ± 0.000%
experiment: │ 3.954 ± 0.325% │ 12.86 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/57344... │ ?? p=0.236 │ 👎 0.558% p=2.55e-06
baseline: │ 4.574 ± 0.721% │ 12.79 ± 0.000%
experiment: │ 4.51 ± 3.709% │ 12.86 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/917504.. │ 👍 -3.826% p=6.58e-06 │ 👎 0.559% p=2.33e-05
baseline: │ 5.221 ± 0.507% │ 12.79 ± 0.000%
experiment: │ 5.021 ± 0.556% │ 12.86 ± 0.000%
│ │
BM_MapIterate<Map<int, int>>/14680064 │ 👍 -3.839% p=1.37e-05 │ 👎 0.559% p=3.31e-05
baseline: │ 5.129 ± 1.194% │ 12.79 ± 0.000%
experiment: │ 4.932 ± 1.475% │ 12.86 ± 0.000%
│ │
Benchmark ┃ CYCLES ┃ INSTRUCTIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
BM_SetIterate<Set<int>>/1....... │ 👍 -3.104% p=0.000583 │ ?? p=0.206
baseline: │ 11.2 ± 6.323% │ 60 ± 3.333%
experiment: │ 10.85 ± 5.820% │ 61 ± 3.279%
│ │
BM_SetIterate<Set<int>>/2....... │ 👍 -7.037% p=0.0362 │ ?? p=0.155
baseline: │ 7.086 ± 16.857% │ 37 ± 0.000%
experiment: │ 6.587 ± 0.479% │ 36 ± 4.167%
│ │
BM_SetIterate<Set<int>>/3....... │ 👎 1.400% p=2.34e-05 │ 👍 -1.163% p=0.00136
baseline: │ 5.363 ± 0.463% │ 28.67 ± 2.326%
experiment: │ 5.438 ± 32.763% │ 28.33 ± 1.176%
│ │
BM_SetIterate<Set<int>>/4....... │ ?? p=0.968 │ ?? p=0.286
baseline: │ 4.642 ± 32.751% │ 23.5 ± 2.128%
experiment: │ 4.658 ± 38.416% │ 23.63 ± 3.704%
│ │
BM_SetIterate<Set<int>>/8....... │ 👍 -23.823% p=3.74e-06 │ 👍 -1.515% p=5.52e-05
baseline: │ 4.701 ± 6.589% │ 16.5 ± 0.000%
experiment: │ 3.581 ± 7.790% │ 16.25 ± 0.000%
│ │
BM_SetIterate<Set<int>>/16...... │ 👍 -4.502% p=1.37e-05 │ 👍 -1.020% p=3.31e-05
baseline: │ 3.124 ± 0.585% │ 12.25 ± 0.000%
experiment: │ 2.983 ± 0.625% │ 12.13 ± 0.000%
│ │
BM_SetIterate<Set<int>>/32...... │ 👍 -4.032% p=5.46e-06 │ 👍 0.617% p=1.96e-05
baseline: │ 2.957 ± 0.260% │ 10.13 ± 0.000%
experiment: │ 2.838 ± 0.434% │ 10.06 ± 0.000%
│ │
BM_SetIterate<Set<int>>/64...... │ 👍 -5.054% p=4.52e-06 │ 👎 0.321% p=1.37e-05
baseline: │ 2.937 ± 0.301% │ 9.75 ± 0.000%
experiment: │ 2.788 ± 1.143% │ 9.781 ± 0.000%
│ │
BM_SetIterate<Set<int>>/256..... │ 👍 -5.325% p=1.14e-05 │ 👎 1.073% p=6.58e-06
baseline: │ 2.916 ± 0.220% │ 9.469 ± 0.000%
experiment: │ 2.761 ± 0.142% │ 9.57 ± 0.000%
│ │
BM_SetIterate<Set<int>>/4096.... │ 👍 -4.865% p=4.52e-06 │ 👎 1.317% p=2.34e-05
baseline: │ 2.921 ± 0.194% │ 9.381 ± 0.000%
experiment: │ 2.779 ± 0.224% │ 9.504 ± 0.000%
│ │
BM_SetIterate<Set<int>>/65536... │ 👎 1.961% p=3.93e-05 │ 👎 1.332% p=1.49e-05
baseline: │ 4.015 ± 0.482% │ 9.375 ± 0.000%
experiment: │ 4.094 ± 0.613% │ 9.5 ± 0.000%
│ │
BM_SetIterate<Set<int>>/1048576. │ 👍 -4.843% p=1.14e-05 │ 👎 1.333% p=5.38e-06
baseline: │ 5.239 ± 0.144% │ 9.375 ± 0.000%
experiment: │ 4.986 ± 0.139% │ 9.5 ± 0.000%
│ │
BM_SetIterate<Set<int>>/16777216 │ 👍 0.840% p=0.0362 │ 👎 1.333% p=2.52e-06
baseline: │ 3.719 ± 1.420% │ 9.375 ± 0.000%
experiment: │ 3.688 ± 1.308% │ 9.5 ± 0.000%
│ │
BM_SetIterate<Set<int>>/56...... │ 👍 -2.857% p=9.53e-06 │ 👍 0.388% p=3.31e-05
baseline: │ 2.942 ± 0.439% │ 9.214 ± 0.000%
experiment: │ 2.858 ± 0.619% │ 9.179 ± 0.000%
│ │
BM_SetIterate<Set<int>>/224..... │ 👍 -2.161% p=2.34e-05 │ 👎 0.502% p=4.52e-06
baseline: │ 2.888 ± 0.347% │ 8.893 ± 0.000%
experiment: │ 2.826 ± 0.450% │ 8.938 ± 0.000%
│ │
BM_SetIterate<Set<int>>/3584.... │ 👍 -1.750% p=6.58e-06 │ 👎 0.793% p=2.34e-05
baseline: │ 2.89 ± 0.261% │ 8.792 ± 0.000%
experiment: │ 2.84 ± 0.411% │ 8.862 ± 0.000%
│ │
BM_SetIterate<Set<int>>/57344... │ ?? p=0.502 │ 👎 0.812% p=2.78e-05
baseline: │ 3.684 ± 4.246% │ 8.786 ± 0.000%
experiment: │ 3.644 ± 4.431% │ 8.857 ± 0.000%
│ │
BM_SetIterate<Set<int>>/917504.. │ 👍 -2.629% p=0.000148 │ 👎 0.813% p=3.08e-06
baseline: │ 4.372 ± 0.693% │ 8.786 ± 0.000%
experiment: │ 4.257 ± 0.210% │ 8.857 ± 0.000%
│ │
BM_SetIterate<Set<int>>/14680064 │ 👍 -2.927% p=0.0219 │ 👎 0.813% p=3.03e-06
baseline: │ 4.154 ± 3.286% │ 8.786 ± 0.000%
experiment: │ 4.032 ± 3.198% │ 8.857 ± 0.000%
│ │
```
Assisted-by: Antigravity with Opus
579 lines
22 KiB
C++
579 lines
22 KiB
C++
// Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
|
// Exceptions. See /LICENSE for license information.
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
#include <benchmark/benchmark.h>
|
|
|
|
#include <boost/unordered/unordered_flat_map.hpp>
|
|
#include <type_traits>
|
|
|
|
#include "absl/container/flat_hash_map.h"
|
|
#include "common/map.h"
|
|
#include "common/raw_hashtable_benchmark_helpers.h"
|
|
#include "llvm/ADT/DenseMap.h"
|
|
|
|
namespace Carbon {
|
|
namespace {
|
|
|
|
using RawHashtable::CarbonHashDI;
|
|
using RawHashtable::GetKeysAndHitKeys;
|
|
using RawHashtable::GetKeysAndMissKeys;
|
|
using RawHashtable::HitArgs;
|
|
using RawHashtable::LowZeroBitInt;
|
|
using RawHashtable::ReportTableMetrics;
|
|
using RawHashtable::SizeArgs;
|
|
using RawHashtable::ValueToBool;
|
|
|
|
// Helpers to synthesize some value of one of the three types we use as value
|
|
// types.
|
|
template <typename T>
|
|
auto MakeValue() -> T {
|
|
if constexpr (std::is_same_v<T, llvm::StringRef>) {
|
|
return "abc";
|
|
} else if constexpr (std::is_pointer_v<T>) {
|
|
static std::remove_pointer_t<T> x;
|
|
return &x;
|
|
} else {
|
|
return 42;
|
|
}
|
|
}
|
|
template <typename T>
|
|
auto MakeValue2() -> T {
|
|
if constexpr (std::is_same_v<T, llvm::StringRef>) {
|
|
return "qux";
|
|
} else if constexpr (std::is_pointer_v<T>) {
|
|
static std::remove_pointer_t<T> y;
|
|
return &y;
|
|
} else {
|
|
return 7;
|
|
}
|
|
}
|
|
|
|
template <typename MapT>
|
|
struct IsCarbonMapImpl : std::false_type {};
|
|
template <typename KT, typename VT, int MinSmallSize>
|
|
struct IsCarbonMapImpl<Map<KT, VT, MinSmallSize>> : std::true_type {};
|
|
|
|
template <typename MapWrapperT>
|
|
static constexpr bool IsCarbonMap =
|
|
IsCarbonMapImpl<typename MapWrapperT::MapT>::value;
|
|
|
|
// A wrapper around various map types that we specialize to implement a common
|
|
// API used in the benchmarks for various different map data structures that
|
|
// support different APIs. The primary template assumes a roughly
|
|
// `std::unordered_map` API design, and types with a different API design are
|
|
// supported through specializations.
|
|
template <typename InMapT>
|
|
struct MapWrapperImpl {
|
|
using MapT = InMapT;
|
|
using KeyT = MapT::key_type;
|
|
using ValueT = MapT::mapped_type;
|
|
|
|
MapT m;
|
|
|
|
auto BenchContains(KeyT k) -> bool { return m.find(k) != m.end(); }
|
|
|
|
auto BenchLookup(KeyT k) -> bool {
|
|
auto it = m.find(k);
|
|
if (it == m.end()) {
|
|
return false;
|
|
}
|
|
return ValueToBool(it->second);
|
|
}
|
|
|
|
auto BenchInsert(KeyT k, ValueT v) -> bool {
|
|
auto result = m.insert({k, v});
|
|
return result.second;
|
|
}
|
|
|
|
auto BenchUpdate(KeyT k, ValueT v) -> bool {
|
|
auto result = m.insert({k, v});
|
|
result.first->second = v;
|
|
return result.second;
|
|
}
|
|
|
|
auto BenchErase(KeyT k) -> bool { return m.erase(k) != 0; }
|
|
|
|
// Visits every entry in the map, calling `cb` with the key and value of each
|
|
// one. Each map type is expected to traverse using whatever API it provides
|
|
// for this, so that the benchmark measures iterating the map rather than any
|
|
// specific iteration API.
|
|
template <typename CallbackT>
|
|
auto BenchIterate(CallbackT cb) -> void {
|
|
for (const auto& entry : m) {
|
|
cb(entry.first, entry.second);
|
|
}
|
|
}
|
|
};
|
|
|
|
// Explicit (partial) specialization for the Carbon map type that uses its
|
|
// different API design.
|
|
template <typename KT, typename VT, int MinSmallSize>
|
|
struct MapWrapperImpl<Map<KT, VT, MinSmallSize>> {
|
|
using MapT = Map<KT, VT, MinSmallSize>;
|
|
using KeyT = KT;
|
|
using ValueT = VT;
|
|
|
|
MapT m;
|
|
|
|
auto BenchContains(KeyT k) -> bool { return m.Contains(k); }
|
|
|
|
auto BenchLookup(KeyT k) -> bool {
|
|
auto result = m.Lookup(k);
|
|
if (!result) {
|
|
return false;
|
|
}
|
|
return ValueToBool(result.value());
|
|
}
|
|
|
|
auto BenchInsert(KeyT k, ValueT v) -> bool {
|
|
auto result = m.Insert(k, v);
|
|
return result.is_inserted();
|
|
}
|
|
|
|
auto BenchUpdate(KeyT k, ValueT v) -> bool {
|
|
auto result = m.Update(k, v);
|
|
return result.is_inserted();
|
|
}
|
|
|
|
auto BenchErase(KeyT k) -> bool { return m.Erase(k); }
|
|
|
|
template <typename CallbackT>
|
|
auto BenchIterate(CallbackT cb) -> void {
|
|
for (auto [k, v] : m.entries()) {
|
|
cb(k, v);
|
|
}
|
|
}
|
|
};
|
|
|
|
// Provide a way to override the Carbon Map specific benchmark runs with another
|
|
// hashtable implementation. When building, you can use one of these enum names
|
|
// in a macro define such as `-DCARBON_MAP_BENCH_OVERRIDE=Name` in order to
|
|
// trigger a specific override for the `Map` type benchmarks. This is used to
|
|
// get before/after runs that compare the performance of Carbon's Map versus
|
|
// other implementations.
|
|
enum class MapOverride : uint8_t {
|
|
None,
|
|
Abseil,
|
|
Boost,
|
|
LLVM,
|
|
LLVMAndCarbonHash,
|
|
};
|
|
#ifndef CARBON_MAP_BENCH_OVERRIDE
|
|
#define CARBON_MAP_BENCH_OVERRIDE None
|
|
#endif
|
|
|
|
template <typename MapT, MapOverride Override>
|
|
struct MapWrapperOverride : MapWrapperImpl<MapT> {};
|
|
|
|
template <typename KeyT, typename ValueT, int MinSmallSize>
|
|
struct MapWrapperOverride<Map<KeyT, ValueT, MinSmallSize>, MapOverride::Abseil>
|
|
: MapWrapperImpl<absl::flat_hash_map<KeyT, ValueT>> {};
|
|
|
|
template <typename KeyT, typename ValueT, int MinSmallSize>
|
|
struct MapWrapperOverride<Map<KeyT, ValueT, MinSmallSize>, MapOverride::Boost>
|
|
: MapWrapperImpl<boost::unordered::unordered_flat_map<KeyT, ValueT>> {};
|
|
|
|
template <typename KeyT, typename ValueT, int MinSmallSize>
|
|
struct MapWrapperOverride<Map<KeyT, ValueT, MinSmallSize>, MapOverride::LLVM>
|
|
: MapWrapperImpl<llvm::DenseMap<KeyT, ValueT>> {};
|
|
|
|
template <typename KeyT, typename ValueT, int MinSmallSize>
|
|
struct MapWrapperOverride<Map<KeyT, ValueT, MinSmallSize>,
|
|
MapOverride::LLVMAndCarbonHash>
|
|
: MapWrapperImpl<llvm::DenseMap<KeyT, ValueT, CarbonHashDI<KeyT>>> {};
|
|
|
|
template <typename MapT>
|
|
using MapWrapper =
|
|
MapWrapperOverride<MapT, MapOverride::CARBON_MAP_BENCH_OVERRIDE>;
|
|
|
|
template <typename MapT>
|
|
auto ReportMetrics(const MapWrapper<MapT>& m_wrapper, benchmark::State& state)
|
|
-> void {
|
|
// Report some extra statistics about the Carbon type.
|
|
if constexpr (IsCarbonMap<MapWrapper<MapT>>) {
|
|
ReportTableMetrics(m_wrapper.m, state);
|
|
}
|
|
}
|
|
|
|
// NOLINTBEGIN(bugprone-macro-parentheses): Parentheses are incorrect here.
|
|
#define MAP_BENCHMARK_ONE_OP_SIZE(NAME, APPLY, KT, VT) \
|
|
BENCHMARK(NAME<Map<KT, VT>>)->Apply(APPLY); \
|
|
BENCHMARK(NAME<absl::flat_hash_map<KT, VT>>)->Apply(APPLY); \
|
|
BENCHMARK(NAME<boost::unordered::unordered_flat_map<KT, VT>>)->Apply(APPLY); \
|
|
BENCHMARK(NAME<llvm::DenseMap<KT, VT>>)->Apply(APPLY); \
|
|
BENCHMARK(NAME<llvm::DenseMap<KT, VT, CarbonHashDI<KT>>>)->Apply(APPLY)
|
|
// NOLINTEND(bugprone-macro-parentheses)
|
|
|
|
#define MAP_BENCHMARK_ONE_OP(NAME, APPLY) \
|
|
MAP_BENCHMARK_ONE_OP_SIZE(NAME, APPLY, int, int); \
|
|
MAP_BENCHMARK_ONE_OP_SIZE(NAME, APPLY, int*, int*); \
|
|
MAP_BENCHMARK_ONE_OP_SIZE(NAME, APPLY, int, llvm::StringRef); \
|
|
MAP_BENCHMARK_ONE_OP_SIZE(NAME, APPLY, llvm::StringRef, int)
|
|
|
|
// Benchmark the minimal latency of checking if a key is contained within a map,
|
|
// when it *is* definitely in that map. Because this is only really measuring
|
|
// the *minimal* latency, it is more similar to a throughput benchmark.
|
|
//
|
|
// While this is structured to observe the latency of testing for presence of a
|
|
// key, it is important to understand the reality of what this measures. Because
|
|
// the boolean result testing for whether a key is in a map is fundamentally
|
|
// provided not by accessing some data, but by branching on data to a control
|
|
// flow path which sets the boolean to `true` or `false`, the result can be
|
|
// speculatively provided based on predicting the conditional branch without
|
|
// waiting for the results of the comparison to become available. And because
|
|
// this is a small operation and we arrange for all the candidate keys to be
|
|
// present, that branch *should* be predicted extremely well. The result is that
|
|
// this measures the un-speculated latency of testing for presence which should
|
|
// be small or zero. Which is why this is ultimately more similar to a
|
|
// throughput benchmark.
|
|
//
|
|
// Because of these measurement oddities, the specific measurements here may not
|
|
// be very interesting for predicting real-world performance in any way, but
|
|
// they are useful for comparing how 'cheap' the operation is across changes to
|
|
// the data structure or between similar data structures with similar
|
|
// properties.
|
|
template <typename MapT>
|
|
static void BM_MapContainsHit(benchmark::State& state) {
|
|
using MapWrapperT = MapWrapper<MapT>;
|
|
using KT = MapWrapperT::KeyT;
|
|
using VT = MapWrapperT::ValueT;
|
|
MapWrapperT m;
|
|
auto [keys, lookup_keys] =
|
|
GetKeysAndHitKeys<KT>(state.range(0), state.range(1));
|
|
for (auto k : keys) {
|
|
m.BenchInsert(k, MakeValue<VT>());
|
|
}
|
|
ssize_t lookup_keys_size = lookup_keys.size();
|
|
|
|
while (state.KeepRunningBatch(lookup_keys_size)) {
|
|
for (ssize_t i = 0; i < lookup_keys_size;) {
|
|
// We block optimizing `i` as that has proven both more effective at
|
|
// blocking the loop from being optimized away and avoiding disruption of
|
|
// the generated code that we're benchmarking.
|
|
benchmark::DoNotOptimize(i);
|
|
|
|
bool result = m.BenchContains(lookup_keys[i]);
|
|
CARBON_DCHECK(result);
|
|
// We use the lookup success to step through keys, establishing a
|
|
// dependency between each lookup. This doesn't fully allow us to measure
|
|
// latency rather than throughput, as noted above.
|
|
i += static_cast<ssize_t>(result);
|
|
}
|
|
}
|
|
|
|
ReportMetrics(m, state);
|
|
}
|
|
MAP_BENCHMARK_ONE_OP(BM_MapContainsHit, HitArgs);
|
|
|
|
// Similar to `BM_MapContainsHit`, while this is structured as a latency
|
|
// benchmark, the critical path is expected to be well predicted and so it
|
|
// should turn into something closer to a throughput benchmark.
|
|
template <typename MapT>
|
|
static void BM_MapContainsMiss(benchmark::State& state) {
|
|
using MapWrapperT = MapWrapper<MapT>;
|
|
using KT = MapWrapperT::KeyT;
|
|
using VT = MapWrapperT::ValueT;
|
|
MapWrapperT m;
|
|
auto [keys, lookup_keys] = GetKeysAndMissKeys<KT>(state.range(0));
|
|
for (auto k : keys) {
|
|
m.BenchInsert(k, MakeValue<VT>());
|
|
}
|
|
ssize_t lookup_keys_size = lookup_keys.size();
|
|
|
|
while (state.KeepRunningBatch(lookup_keys_size)) {
|
|
for (ssize_t i = 0; i < lookup_keys_size;) {
|
|
benchmark::DoNotOptimize(i);
|
|
|
|
bool result = m.BenchContains(lookup_keys[i]);
|
|
CARBON_DCHECK(!result);
|
|
i += static_cast<ssize_t>(!result);
|
|
}
|
|
}
|
|
|
|
ReportMetrics(m, state);
|
|
}
|
|
MAP_BENCHMARK_ONE_OP(BM_MapContainsMiss, SizeArgs);
|
|
|
|
// This is a genuine latency benchmark. We lookup a key in the hashtable and use
|
|
// the value associated with that key in the critical path of loading the next
|
|
// iteration's key. We still ensure the keys are always present, and so we
|
|
// generally expect the data structure branches to be well predicted. But we
|
|
// vary the keys aggressively to avoid any prediction artifacts from repeatedly
|
|
// examining the same key.
|
|
//
|
|
// This latency can be very helpful for understanding a range of data structure
|
|
// behaviors:
|
|
// - Many users of hashtables are directly dependent on the latency of this
|
|
// operation, and this micro-benchmark will reflect the expected latency for
|
|
// them.
|
|
// - Showing how latency varies across different sizes of table and different
|
|
// fractions of the table being accessed (and thus needing space in the
|
|
// cache).
|
|
//
|
|
// However, it remains an ultimately synthetic and unrepresentative benchmark.
|
|
// It should primarily be used to understand the relative cost of these
|
|
// operations between versions of the data structure or between related data
|
|
// structures.
|
|
//
|
|
// We vary both the number of entries in the table and the number of distinct
|
|
// keys used when doing lookups. As the table becomes large, the latter dictates
|
|
// the fraction of the table that will be accessed and thus the working set size
|
|
// of the benchmark. Querying the same small number of keys in even a large
|
|
// table doesn't actually encounter any cache pressure, so only a few of these
|
|
// benchmarks will show any effects of the caching subsystem.
|
|
template <typename MapT>
|
|
static void BM_MapLookupHit(benchmark::State& state) {
|
|
using MapWrapperT = MapWrapper<MapT>;
|
|
using KT = MapWrapperT::KeyT;
|
|
using VT = MapWrapperT::ValueT;
|
|
MapWrapperT m;
|
|
auto [keys, lookup_keys] =
|
|
GetKeysAndHitKeys<KT>(state.range(0), state.range(1));
|
|
for (auto k : keys) {
|
|
m.BenchInsert(k, MakeValue<VT>());
|
|
}
|
|
ssize_t lookup_keys_size = lookup_keys.size();
|
|
|
|
while (state.KeepRunningBatch(lookup_keys_size)) {
|
|
for (ssize_t i = 0; i < lookup_keys_size;) {
|
|
benchmark::DoNotOptimize(i);
|
|
|
|
bool result = m.BenchLookup(lookup_keys[i]);
|
|
CARBON_DCHECK(result);
|
|
i += static_cast<ssize_t>(result);
|
|
}
|
|
}
|
|
|
|
ReportMetrics(m, state);
|
|
}
|
|
MAP_BENCHMARK_ONE_OP(BM_MapLookupHit, HitArgs);
|
|
|
|
// We also do some minimal benchmarking with integers that have a
|
|
// large number of low zero bits shifted into them. These present particular
|
|
// challenges to the hashing strategy Carbon's hash tables use and so they help
|
|
// form stress tests and benchmark to make sure the hash function quality
|
|
// remains reasonable even under adverse conditions. We can't go past a certain
|
|
// limit here without our hash tables becoming impossibly slow due to complete
|
|
// collapse of the hash functions -- if we ever need to hash integers with more
|
|
// than 32 low zero bits, we'll ask that code to use a custom hash algorithm.
|
|
//
|
|
// We don't benchmark these everywhere as they only provide marginal information
|
|
// beyond the core types, and checking just this operation covers that
|
|
// sufficiently.
|
|
MAP_BENCHMARK_ONE_OP_SIZE(BM_MapLookupHit, HitArgs, LowZeroBitInt<12>, int);
|
|
MAP_BENCHMARK_ONE_OP_SIZE(BM_MapLookupHit, HitArgs, LowZeroBitInt<24>, int);
|
|
MAP_BENCHMARK_ONE_OP_SIZE(BM_MapLookupHit, HitArgs, LowZeroBitInt<32>, int);
|
|
|
|
// This is an update throughput benchmark in practice. While whether the key was
|
|
// a hit is kept in the critical path, we only use keys that are hits and so
|
|
// expect that to be fully predicted and speculated.
|
|
//
|
|
// However, we expect this fairly closely matches how user code interacts with
|
|
// an update-style API. It will have some conditional testing (even if just an
|
|
// assert) on whether the key was a hit and otherwise continue executing. As a
|
|
// consequence the actual update is expected to not be in a meaningful critical
|
|
// path.
|
|
//
|
|
// This still provides a basic way to measure the cost of this operation,
|
|
// especially when comparing between implementations or across different hash
|
|
// tables.
|
|
template <typename MapT>
|
|
static void BM_MapUpdateHit(benchmark::State& state) {
|
|
using MapWrapperT = MapWrapper<MapT>;
|
|
using KT = MapWrapperT::KeyT;
|
|
using VT = MapWrapperT::ValueT;
|
|
MapWrapperT m;
|
|
auto [keys, lookup_keys] =
|
|
GetKeysAndHitKeys<KT>(state.range(0), state.range(1));
|
|
for (auto k : keys) {
|
|
m.BenchInsert(k, MakeValue<VT>());
|
|
}
|
|
ssize_t lookup_keys_size = lookup_keys.size();
|
|
|
|
while (state.KeepRunningBatch(lookup_keys_size)) {
|
|
for (ssize_t i = 0; i < lookup_keys_size; ++i) {
|
|
benchmark::DoNotOptimize(i);
|
|
|
|
bool inserted = m.BenchUpdate(lookup_keys[i], MakeValue2<VT>());
|
|
CARBON_DCHECK(!inserted);
|
|
}
|
|
}
|
|
|
|
ReportMetrics(m, state);
|
|
}
|
|
MAP_BENCHMARK_ONE_OP(BM_MapUpdateHit, HitArgs);
|
|
|
|
// First erase and then insert the key. The code path will always be the same
|
|
// here and so we expect this to largely be a throughput benchmark because of
|
|
// branch prediction and speculative execution.
|
|
//
|
|
// We don't expect erase followed by insertion to be a common user code
|
|
// sequence, but we don't have a good way of benchmarking either erase or insert
|
|
// in isolation -- each would change the size of the table and thus the next
|
|
// iteration's benchmark. And if we try to correct the table size outside of the
|
|
// timed region, we end up trying to exclude too fine grained of a region from
|
|
// timers to get good measurement data.
|
|
//
|
|
// Our solution is to benchmark both erase and insertion back to back. We can
|
|
// then get a good profile of the code sequence of each, and at least measure
|
|
// the sum cost of these reliably. Careful profiling can help attribute that
|
|
// cost between erase and insert in order to understand which of the two
|
|
// operations is contributing most to any performance artifacts observed.
|
|
template <typename MapT>
|
|
static void BM_MapEraseUpdateHit(benchmark::State& state) {
|
|
using MapWrapperT = MapWrapper<MapT>;
|
|
using KT = MapWrapperT::KeyT;
|
|
using VT = MapWrapperT::ValueT;
|
|
MapWrapperT m;
|
|
auto [keys, lookup_keys] =
|
|
GetKeysAndHitKeys<KT>(state.range(0), state.range(1));
|
|
for (auto k : keys) {
|
|
m.BenchInsert(k, MakeValue<VT>());
|
|
}
|
|
ssize_t lookup_keys_size = lookup_keys.size();
|
|
|
|
while (state.KeepRunningBatch(lookup_keys_size)) {
|
|
for (ssize_t i = 0; i < lookup_keys_size; ++i) {
|
|
benchmark::DoNotOptimize(i);
|
|
|
|
m.BenchErase(lookup_keys[i]);
|
|
benchmark::ClobberMemory();
|
|
|
|
bool inserted = m.BenchUpdate(lookup_keys[i], MakeValue2<VT>());
|
|
CARBON_DCHECK(inserted);
|
|
}
|
|
}
|
|
}
|
|
MAP_BENCHMARK_ONE_OP(BM_MapEraseUpdateHit, HitArgs);
|
|
|
|
// NOLINTBEGIN(bugprone-macro-parentheses): Parentheses are incorrect here.
|
|
#define MAP_BENCHMARK_OP_SEQ_SIZE(NAME, KT, VT) \
|
|
BENCHMARK(NAME<Map<KT, VT>>)->Apply(SizeArgs); \
|
|
BENCHMARK(NAME<absl::flat_hash_map<KT, VT>>)->Apply(SizeArgs); \
|
|
BENCHMARK(NAME<boost::unordered::unordered_flat_map<KT, VT>>) \
|
|
->Apply(SizeArgs); \
|
|
BENCHMARK(NAME<llvm::DenseMap<KT, VT>>)->Apply(APPLY); \
|
|
BENCHMARK(NAME<llvm::DenseMap<KT, VT, CarbonHashDI<KT>>>)->Apply(SizeArgs)
|
|
// NOLINTEND(bugprone-macro-parentheses)
|
|
|
|
#define MAP_BENCHMARK_OP_SEQ(NAME) \
|
|
MAP_BENCHMARK_OP_SEQ_SIZE(NAME, int, int); \
|
|
MAP_BENCHMARK_OP_SEQ_SIZE(NAME, int*, int*); \
|
|
MAP_BENCHMARK_OP_SEQ_SIZE(NAME, int, llvm::StringRef); \
|
|
MAP_BENCHMARK_OP_SEQ_SIZE(NAME, llvm::StringRef, int)
|
|
|
|
// This is an interesting, somewhat specialized benchmark that measures the cost
|
|
// of inserting a sequence of key/value pairs into a table with no collisions up
|
|
// to some size and then inserting a colliding key and throwing away the table.
|
|
//
|
|
// This can give an idea of the cost of building up a map of a particular size,
|
|
// but without actually using it. Or of algorithms like cycle-detection which
|
|
// for some reason need an associative container.
|
|
//
|
|
// It also covers both the insert-into-an-empty-slot code path that isn't
|
|
// covered elsewhere, and the code path for growing a table to a larger size.
|
|
//
|
|
// Because this benchmark operates on whole maps, we also compute the number of
|
|
// probed keys for Carbon's set as that is both a general reflection of the
|
|
// efficacy of the underlying hash function, and a direct factor that drives the
|
|
// cost of these operations.
|
|
template <typename MapT>
|
|
static void BM_MapInsertSeq(benchmark::State& state) {
|
|
using MapWrapperT = MapWrapper<MapT>;
|
|
using KT = MapWrapperT::KeyT;
|
|
using VT = MapWrapperT::ValueT;
|
|
constexpr ssize_t LookupKeysSize = 1 << 8;
|
|
auto [keys, lookup_keys] =
|
|
GetKeysAndHitKeys<KT>(state.range(0), LookupKeysSize);
|
|
|
|
// Note that we don't force batches that use all the lookup keys because
|
|
// there's no difference in cache usage by covering all the different lookup
|
|
// keys.
|
|
ssize_t i = 0;
|
|
for (auto _ : state) {
|
|
benchmark::DoNotOptimize(i);
|
|
|
|
MapWrapperT m;
|
|
for (auto k : keys) {
|
|
bool inserted = m.BenchInsert(k, MakeValue<VT>());
|
|
CARBON_DCHECK(inserted, "Must be a successful insert!");
|
|
}
|
|
|
|
// Now insert a final random repeated key.
|
|
bool inserted = m.BenchInsert(lookup_keys[i], MakeValue2<VT>());
|
|
CARBON_DCHECK(!inserted, "Must already be in the map!");
|
|
|
|
// Rotate through the shuffled keys.
|
|
i = (i + static_cast<ssize_t>(!inserted)) & (LookupKeysSize - 1);
|
|
}
|
|
|
|
// It can be easier in some cases to think of this as a key-throughput rate of
|
|
// insertion rather than the latency of inserting N keys, so construct the
|
|
// rate counter as well.
|
|
state.counters["KeyRate"] = benchmark::Counter(
|
|
keys.size(), benchmark::Counter::kIsIterationInvariantRate);
|
|
|
|
// Report some extra statistics about the Carbon type.
|
|
if constexpr (IsCarbonMap<MapWrapperT>) {
|
|
// Re-build a map outside of the timing loop to look at the statistics
|
|
// rather than the timing.
|
|
MapWrapperT m;
|
|
for (auto k : keys) {
|
|
bool inserted = m.BenchInsert(k, MakeValue<VT>());
|
|
CARBON_DCHECK(inserted, "Must be a successful insert!");
|
|
}
|
|
|
|
ReportMetrics(m, state);
|
|
|
|
// Uncomment this call to print out statistics about the index-collisions
|
|
// among these keys for debugging:
|
|
//
|
|
// RawHashtable::DumpHashStatistics(keys);
|
|
}
|
|
}
|
|
MAP_BENCHMARK_ONE_OP(BM_MapInsertSeq, SizeArgs);
|
|
|
|
// Benchmark visiting every entry in a map.
|
|
//
|
|
// Unlike the lookup benchmarks, this walks the table's storage from end to end
|
|
// rather than probing it, so it is largely a measure of how densely entries are
|
|
// packed and how cheaply empty slots can be skipped. There is no dependency
|
|
// between the entries visited, and so this is a throughput measurement.
|
|
//
|
|
// Each batch is a single complete traversal of the map, with the batch size set
|
|
// to the number of entries so that the reported time is the per-entry cost.
|
|
template <typename MapT>
|
|
static void BM_MapIterate(benchmark::State& state) {
|
|
using MapWrapperT = MapWrapper<MapT>;
|
|
using KT = typename MapWrapperT::KeyT;
|
|
using VT = typename MapWrapperT::ValueT;
|
|
MapWrapperT m;
|
|
auto [keys, _] = GetKeysAndMissKeys<KT>(state.range(0));
|
|
for (auto k : keys) {
|
|
bool inserted = m.BenchInsert(k, MakeValue<VT>());
|
|
CARBON_DCHECK(inserted, "Must be a successful insert!");
|
|
}
|
|
|
|
while (state.KeepRunningBatch(keys.size())) {
|
|
ssize_t sum = 0;
|
|
m.BenchIterate([&sum](const KT& k, const VT& v) {
|
|
// Consume both the key and the value so that neither the traversal nor
|
|
// the loads out of the entries can be optimized away.
|
|
sum += ValueToBool(k) + ValueToBool(v);
|
|
});
|
|
benchmark::DoNotOptimize(sum);
|
|
}
|
|
|
|
// The time is already per-entry, so an iteration-invariant rate of one gives
|
|
// the throughput of entries visited.
|
|
state.counters["KeyRate"] =
|
|
benchmark::Counter(1, benchmark::Counter::kIsIterationInvariantRate);
|
|
|
|
ReportMetrics(m, state);
|
|
}
|
|
MAP_BENCHMARK_ONE_OP(BM_MapIterate, SizeArgs);
|
|
|
|
} // namespace
|
|
} // namespace Carbon
|