Accelerate dense bitmap decoding in ToArray - #556
Conversation
|
Ths is promising. We use a similar approach in simdjson. |
| //go:noescape | ||
| func _hasAVX512() bool | ||
|
|
||
| // AVX-512 is used only when the operating system saves the ZMM state and the |
There was a problem hiding this comment.
Yeah. This will be a problem, however.
There was a problem hiding this comment.
Addressed in 74b708afddae. Response to this feedback.
The repaired source retains the OS and CPU feature gate before executing AVX-512 instructions, and keeps the ordered ToArray cursor and existing allocation path unchanged. This limits the new path to supported dense inputs.
|
@perfloop-agent I found something better. Perfloop is credited |
207aca3 to
74b708a
Compare
|
Addressed in The repaired source keeps the same block-wise compress-store approach and rebuilds it on the current base. Dense containers use the AVX-512 path, while sparse and unsupported targets retain the scalar fallback. |
bitmapContainer.fillLeastSignificant16bits walks set bits with a scalar
TZCNT/BLSR loop. On CPUs with AVX512_VBMI2 a single VPCOMPRESSB turns a
whole 64-bit word into 64 byte-sized bit positions; those are widened
with VPMOVZXBD and written with masked stores, so exactly popcount(word)
values are written and ToArray's exactly-sized output slice needs no
padding.
ToArray over the real-data corpus (Xeon Gold 6548N, Emerald Rapids):
census-income 8.48 ms -> 4.60 ms (1.84x)
weather_sept_85 16.19 ms -> 7.83 ms (2.07x)
The other ten datasets hold no bitmap containers and are unchanged.
Feature detection goes through golang.org/x/sys/cpu, so the OSXSAVE and
XCR0 opmask/ZMM checks are handled upstream and GODEBUG=cpu.avx512vbmi2=off
disables the path at run time. Containers below 4096 values, CPUs without
VBMI2, appengine builds and non-amd64 targets keep the scalar loop.
The compress-then-widen kernel follows simdjson's bit_indexer::write.
Based on the approach explored in RoaringBitmap#556 by Perfloop.
Claude-Session: https://claude.ai/code/session_0123ePBefqPjrCvhxdwWFakj
2 participants
Description
Speed up
Bitmap.ToArrayfor dense bitmap containers on amd64 CPUs with AVX-512 support.Type of Change
Changes Made
What was changed?
Bitmap.ToArraybenchmark covering four dense containers and allocation behavior.Why was it changed?
How was it changed?
Testing
go test ./...go build -tags appengine ./...go test -tags appengine ./...go tool unconvert ./...Checks: 9 passed.
Formatting
Ran
gofmtand verified that no Go files require formatting changes.Fuzzing
Ran the generated smat corpus and smat-hit tests:
Performance Impact
The fast path applies only to dense bitmap containers on supported amd64 CPUs. Sparse containers, appengine builds, and unsupported targets keep the existing fallback. The change keeps
ToArrayallocation and container traversal in their existing owners.Workload:
ToArray over four dense bitmap containersns/opBreaking Changes
None.
Related Issues
None.
Additional Notes
The output remains ordered and the portable implementation remains available as the fallback.
Generated by Perfloop. Measurements and checks.