Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

1 change: 1 addition & 0 deletions Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,7 @@ asyncband = { path = "asyncband" }

# Optional runtime dependencies
hashbrown = { version = "0.17.1", default-features = false }
scc = "3.8.6"

# Dev dependencies
async-channel = { version = "2.5.0" }
Expand Down
3 changes: 2 additions & 1 deletion asyncband/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ mpsc = []
mutex = []
once = ["semaphore"]
once-cell = ["semaphore"]
once-map = ["dep:hashbrown", "once-cell"]
once-map = ["dep:hashbrown", "dep:scc", "once-cell"]
oneshot = []
pool = ["semaphore"]
rwlock = []
Expand All @@ -66,6 +66,7 @@ waitgroup = []
hashbrown = { workspace = true, default-features = false, features = [
"inline-more",
], optional = true }
scc = { workspace = true, optional = true }

[dev-dependencies]
tokio = { workspace = true, features = ["full"] }
Expand Down
16 changes: 10 additions & 6 deletions asyncband/src/internal/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -38,12 +38,6 @@ mod arena;
#[allow(dead_code)]
pub(crate) mod countdown;

#[cfg(any(feature = "once-map", feature = "singleflight"))]
// `OnceMap` and `singleflight` use different subsets of `OnceTable`, so single-feature builds
// leave some operations in the shared implementation unused.
#[allow(dead_code)]
pub(crate) mod once_table;

#[cfg(any(feature = "lazy-cell", feature = "once-cell"))]
// `LazyCell` and `OnceCell` use different subsets of `ValueCell`, so single-feature builds leave
// some operations in the shared implementation unused.
Expand Down Expand Up @@ -91,3 +85,13 @@ pub(crate) mod waitlist;
// `new`. One constructor is therefore unused in every single-primitive build.
#[allow(dead_code)]
pub(crate) mod waitset;

#[cfg(any(feature = "once-map", feature = "singleflight"))]
pub fn default_shard_count() -> usize {
// Tested on a 32-core machine, the optimal shard count for `OnceMap` and `Singleflight` is 256.
// So I use 8 as the coefficient, which is 256 / 32.
// Need to test on other machines to see if this coefficient is optimal.
// Dashmap use 4.
(std::thread::available_parallelism().map_or(1, |parallelism| parallelism.get()) * 8)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Bound or expose the eager shard allocation

Eager CPU-scaled sharding has precedent, but this exact default is unusually aggressive for OnceMap and especially singleflight::Group. DashMap uses available_parallelism * 4, eagerly creates its shards, and exposes with_shard_amount constructors so callers can trade contention for footprint. The canonical Go singleflight implementation instead lazily initializes one mutex-protected map, and scc::HashIndex, already used by this PR, starts with zero capacity.

This implementation uses available_parallelism * 8 with no override. On this 14-way host that becomes 128 #[repr(align(64))] shards. An allocator probe measured:

  • OnceMap::new() and Group::new(): 1 allocation / 8,192 bytes, versus 0 allocations in 0.6.7.
  • OnceMap::with_capacity(1): 132 allocations / 14,592 bytes, versus 1 allocation / 44 bytes in 0.6.7.

On the 32-core machine used to choose the coefficient, every empty instance starts with 256 shards and at least 16 KiB of cache-line-padded storage. The throughput results establish the benefit for a hot shared table, but do not cover construction or workloads containing many empty/small maps and groups.

Could we add construction/allocation benchmarks and either expose an explicit shard-count constructor with a more conservative or capped default, or allocate shard storage lazily? The sharding optimization itself is justified; the concern is making its most aggressive configuration an unavoidable per-instance cost.

.next_power_of_two()
}
7 changes: 7 additions & 0 deletions asyncband/src/internal/mutex.rs
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,13 @@ impl<T> Mutex<T> {
}
}

#[cfg(any(feature = "once-map", feature = "singleflight"))]
/// Alignment uses 60% more memory (64/40) but improves write performance by 25% at 32 threads. (On
/// Zen 5 CPUs)
/// Need to test on other architectures.
#[repr(align(64))]
pub struct CachePaddedMutex<T>(pub Mutex<T>);

#[cfg(test)]
mod tests {
use std::sync::Arc;
Expand Down
167 changes: 0 additions & 167 deletions asyncband/src/internal/once_table.rs

This file was deleted.

Loading