You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider `HashSet<u8>` on x86_64 with SSE with various bucket sizes and
how many bytes the allocation ends up being:
| buckets | capacity | allocated bytes |
| ------- | -------- | --------------- |
| 4 | 3 | 36 |
| 8 | 7 | 40 |
| 16 | 14 | 48 |
| 32 | 28 | 80 |
In general, doubling the number of buckets should roughly double the
number of bytes used. However, for small bucket sizes for these small
TableLayouts (4 -> 8, 8 -> 16), it doesn't happen. This is an edge case
which happens because of padding of the control bytes and adding the
Group::WIDTH. Taking the buckets from 4 to 16 (4x) only takes the
allocated bytes from 36 to 48 (~1.3x).
This platform isn't the only one with edges. Here's aarch64 on an M1
for the same `HashSet<u8>`:
| buckets | capacity | allocated bytes |
| ------- | -------- | --------------- |
| 4 | 3 | 20 |
| 8 | 7 | 24 |
| 16 | 14 | 40 |
Notice 4 -> 8 buckets leading to only 4 more bytes (20 -> 24) instead
of roughly doubling.
Generalized, `buckets * table_layout.size` needs to be at least as big
as `table_layout.ctrl_align`. For the cases I listed above, we'd get
these new minimum bucket sizes:
- x86_64 with SSE: 16
- aarch64: 8
This is a niche optimization. However, it also removes possible
undefined behavior edge case in resize operations. In addition, it
may be a useful property to utilize over-sized allocations (see
#523).
0 commit comments