Status: closed — implementation tested NEGATIVE on i9-9900K (2026-05-25)
| fixture |
main bcd1f7d (post-#261) |
branch perf/#262-overlap-copy8-userslice @ 4ee32c5 |
change |
decompress/level_-1_fast/decodecorpus-z000033/c_stream/matrix/pure_rust_direct |
~1.685 ms |
1.984 ms (median, range 1.749..2.262 ms) |
+17.58% (p<0.05) |
decompress/level_-1_fast/low-entropy-1m/rust_stream/matrix/pure_rust_direct |
~235 µs |
291.77 µs (median, range 247.17..341.49 µs) |
+24.03% (p<0.05) |
Wide variance bands indicate noisy measurement but the trend is clearly negative.
Why hypothesis failed
The thesis was that repeat_in_chunks with chunksize=offset (8..=15) paid expensive per-chunk dispatch through extend_from_within_unchecked → copy_bytes_overshooting, and that an inline 8-byte u64 loop would bypass it for a win.
Tracing the actual hot path under WILDCOPY_OVERLENGTH = 32 (post-#261):
repeat_in_chunks chunks at offset bytes (8..=15)- Each chunk calls
extend_from_within_unchecked(start, offset)
- That calls
copy_bytes_overshooting(src, dst, offset)
- The
copy_at_least <= 16 && min_buffer_size >= 16 branch fires (32-byte slack guarantees it)
single_op_copy_16 does one 16-byte SSE2 store (overshoot OK)
So the existing path already emits 16-byte SSE2 SIMD per chunk, not 8-byte. Donor ZSTD_wildcopy (zstd_internal.h:215-230 overlap arm) uses 8-byte MEM_read64/MEM_write64 — portable C that's suboptimal on x86 where SSE2 is universal. Replacing our 16-byte-SIMD-per-chunk with an inline 8-byte u64 loop downgraded the SIMD width and cost time.
Right cost to attack (if revisited)
The recoverable overhead is the dispatcher's compare chain in copy_bytes_overshooting (the if copy_at_least <= 16 && min_buffer_size >= 16 branch), not the 16-byte SIMD store itself. An optimal fix would inline single_op_copy_16 directly into the chunk loop body, bypassing the dispatcher but keeping 16-byte SIMD per iter. That's a separate, narrower hypothesis worth a future issue if profiling still shows copy_bytes_overshooting self time > 2-3% after Tier 9 work lands.
Closing this issue. Negative result + diagnosis recorded in memory.
Status: closed — implementation tested NEGATIVE on i9-9900K (2026-05-25)
perf/#262-overlap-copy8-userslice@ 4ee32c5decompress/level_-1_fast/decodecorpus-z000033/c_stream/matrix/pure_rust_directdecompress/level_-1_fast/low-entropy-1m/rust_stream/matrix/pure_rust_directWide variance bands indicate noisy measurement but the trend is clearly negative.
Why hypothesis failed
The thesis was that
repeat_in_chunkswith chunksize=offset (8..=15) paid expensive per-chunk dispatch throughextend_from_within_unchecked→copy_bytes_overshooting, and that an inline 8-byte u64 loop would bypass it for a win.Tracing the actual hot path under
WILDCOPY_OVERLENGTH = 32(post-#261):repeat_in_chunkschunks at offset bytes (8..=15)extend_from_within_unchecked(start, offset)copy_bytes_overshooting(src, dst, offset)copy_at_least <= 16 && min_buffer_size >= 16branch fires (32-byte slack guarantees it)single_op_copy_16does one 16-byte SSE2 store (overshoot OK)So the existing path already emits 16-byte SSE2 SIMD per chunk, not 8-byte. Donor
ZSTD_wildcopy(zstd_internal.h:215-230 overlap arm) uses 8-byteMEM_read64/MEM_write64— portable C that's suboptimal on x86 where SSE2 is universal. Replacing our 16-byte-SIMD-per-chunk with an inline 8-byte u64 loop downgraded the SIMD width and cost time.Right cost to attack (if revisited)
The recoverable overhead is the dispatcher's compare chain in
copy_bytes_overshooting(theif copy_at_least <= 16 && min_buffer_size >= 16branch), not the 16-byte SIMD store itself. An optimal fix would inlinesingle_op_copy_16directly into the chunk loop body, bypassing the dispatcher but keeping 16-byte SIMD per iter. That's a separate, narrower hypothesis worth a future issue if profiling still showscopy_bytes_overshootingself time > 2-3% after Tier 9 work lands.Closing this issue. Negative result + diagnosis recorded in memory.