NUMA-aware shard selection and work stealing

[emeryberger]

Summary

This PR improves Hoard's performance on NUMA systems by making the sharded global heap NUMA-aware:

1. NUMA-aware shard selection

Instead of just masking the CPU number (cpu & (NumShards - 1)), we now use syscall(SYS_getcpu) to get both the CPU and NUMA node, then compute:

shard = (node * shardsPerNode) + (cpu % shardsPerNode)

This ensures threads on different NUMA nodes use different shard ranges. With 8 shards and 2 NUMA nodes: node 0 uses shards 0-3, node 1 uses shards 4-7.

2. NUMA-aware work stealing

Modified get() to search for superblocks in priority order:

1. Local shard first
2. Power-of-two random choices within same NUMA node
3. Remaining same-node shards
4. Other NUMA nodes (last resort)

This reduces cross-node memory traffic when stealing superblocks from the global heap.

Benchmark Results

NUMA stress test (20 touches per object to isolate NUMA effects)

At 128 threads on a 2-node NUMA system:

Allocator	Throughput	Hoard Speedup
Hoard	19.5M ops/sec	1.00x
mimalloc	13.6M ops/sec	1.43x
jemalloc	14.1M ops/sec	1.38x
glibc	12.1M ops/sec	1.61x

Hardware performance counter verification

Used AMD perf counters to measure actual NUMA locality at 64 threads:

Counter	Description
ls_dmnd_fills_from_sys.mem_io_local	Memory I/O fulfilled locally
ls_dmnd_fills_from_sys.mem_io_remote	Memory I/O fulfilled from remote NUMA node
ls_dmnd_fills_from_sys.ext_cache_local	L3 cache fills from local node
ls_dmnd_fills_from_sys.ext_cache_remote	L3 cache fills from remote node

Results: Hoard's NUMA optimization reduces remote memory access from 40.6% to 33.4% (memory I/O) and 45.5% to 37.1% (cache fills), while improving throughput by 9%:

Allocator	Throughput	Remote Memory I/O	Remote Cache Fills
Hoard (NUMA opt)	83.3M ops/s	33.4%	37.1%
Hoard (no NUMA)	76.4M ops/s	40.6%	45.5%
mimalloc	87.0M ops/s	18.3%	33.4%
jemalloc	53.6M ops/s	15.5%	40.8%
glibc	68.7M ops/s	51.4%	47.8%

Note: mimalloc and jemalloc have lower remote access percentages because they use per-thread arenas (less sharing), but this comes at the cost of higher memory usage. glibc shows the highest remote access (51.4%) and throughput suffers accordingly.

Standard benchmarks (no regression)

Compared against hoard_opt_work branch:

Benchmark	Threads	hoard_opt_work	numa-aware-sharding
threadtest	16	14.3s	11.3s (faster)
threadtest	64	2.9s	2.9s (same)
threadtest	128	6.6s	6.6s (same)
threadtest	256	1.8s	1.8s (same)

Test plan

• NUMA stress test at 16-128 threads with 20 touches per object
• Verified NUMA effects with hardware performance counters
• Standard benchmarks (threadtest, linux-scalability, Phong)
• Verified no regression vs hoard_opt_work branch
• Tested on 192-core, 2-node NUMA system (AMD EPYC, node 0: CPUs 0-95, node 1: CPUs 96-191)

🤖 Generated with Claude Code