Performance bottleneck due to cache contention

[jacob-greenfield]

I have been investigating the performance of concurrent data structures as part of an ongoing research project. A key finding is that under heavy parallel workloads, data structures like crossbeam-skiplist often suffer from bottlenecks caused by a small number of frequently-modified shared variables due to cache contention (aka cache thrashing).

With skip lists in general, any two operations on different keys in a large set are highly unlikely to modify any shared cache line. However, with crossbeam-skiplist, HotData is modified on every insertion and removal. hot_data.len is updated using an atomic fetch-and-add, which is particularly expensive for highly-conteded variables on some architectures. Simply switching to a thread-local random seed and removing the atomic length variable dramatically improves performance under heavy parallel workloads.

This PR demonstrates the performance improvements with a simple benchmark. The benefit scales with thread count; on an x86-64 CPU with 64 virtual cores (32 physical cores, hyperthreading enabled), this optimization increases total throughput by >3.6x at 64 threads (with throughput measured as # of set operations per second).

Implementing this optimization would unfortunately mean sacrificing the accuracy of the len() method; while I suspect the performance boost would easily justify the loss for most users, this would be a breaking change and removes potentially important functionality. One option could be adding new, alternative versions of certain methods; e.g. create new fast_insert() and fast_remove() methods which don't modify the length variable, and leave the existing insert()/remove() methods intact. I am not sure what the best approach is, but I believe it is ultimately worth implementing, and I am open to suggestions for alternative options.

Benchmarks

Tested with rustc 1.97.0-nightly (ff9a9ea07 2026-05-13).

Baseline revision: d0cb16a
Less-contended revision: 4fefec9

Dual-socket Intel Xeon Gold 5218 (x86-64, 64 virtual cores)

lscpu output

Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          46 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   64
  On-line CPU(s) list:    0-63
Vendor ID:                GenuineIntel
  Model name:             Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
    CPU family:           6
    Model:                85
    Thread(s) per core:   2
    Core(s) per socket:   16
    Socket(s):            2
    Stepping:             7
    CPU max MHz:          3900.0000
    CPU min MHz:          1000.0000
    BogoMIPS:             4600.00
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp 
                          lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2
                           ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch c
                          puid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbas
                          e tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl x
                          saveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke avx512_vnni md_clear flush_l1d a
                          rch_capabilities
Virtualization features:  
  Virtualization:         VT-x
Caches (sum of all):      
  L1d:                    1 MiB (32 instances)
  L1i:                    1 MiB (32 instances)
  L2:                     32 MiB (32 instances)
  L3:                     44 MiB (2 instances)
NUMA:                     
  NUMA node(s):           2
  NUMA node0 CPU(s):      0-15,32-47
  NUMA node1 CPU(s):      16-31,48-63
Vulnerabilities:          
  Gather data sampling:   Mitigation; Microcode
  Itlb multihit:          KVM: Mitigation: VMX disabled
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Mitigation; Clear CPU buffers; SMT vulnerable
  Reg file data sampling: Not affected
  Retbleed:               Mitigation; Enhanced IBRS
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI SW loop, KVM SW loop
  Srbds:                  Not affected
  Tsx async abort:        Mitigation; TSX disabled

cargo run -p crossbeam-skiplist --example parallel --release -- 1 2 4 8 16 32 48 60 64

Throughput (operations/second):

threads	baseline	less-contended	speedup
1	1425299	1407394	0.99x
2	2616482	2677422	1.02x
4	4747247	5121696	1.08x
8	5873693	7671461	1.31x
16	6853475	12705138	1.85x
32	7274837	22727032	3.12x
48	8956789	30210372	3.37x
60	10018060	36439080	3.64x
64	10527560	38291880	3.64x

MacBook Pro (aarch64, M1 Pro, 10 cores)

cargo run -p crossbeam-skiplist --example parallel --release -- 1 2 4 8 10

Throughput (operations/second):

threads	baseline	less-contended	speedup
1	1851189	1816741	0.98x
2	3583047	3729654	1.06x
4	6333425	7212682	1.28x
8	8624892	13132332	1.48x
10	9427303	14239139	1.55x