uops.info — the popcount instructions, measured

uops.info (Andreas Abel and Jan Reineke, Saarland University; the method is published as arXiv:1810.04610) measures latency, throughput and port usage for x86 instructions by generating microbenchmarks and running them on real hardware. It is not a vendor table: Intel and AMD do not produce it, and where their own documentation disagrees with the measurement the page shows both. That makes it T2 — a third party measuring somebody else's product — and it is what coverage edge 6 asked for.

Read 2026-08-22 for POPCNT r64, r64, VPOPCNTQ ymm, ymm and VPOPCNTQ zmm, zmm.

The numbers

Every Intel microarchitecture from Ice Lake to Emerald Rapids gives the same answer, and it is a single answer: one 512-bit popcount per cycle, on one port, at three cycles of latency. One µop, one retire slot, no microcode.

What that settles

The width is free; the issue rate is not. Scalar POPCNT and 512-bit VPOPCNTQ both retire one per cycle. Going from a 64-bit register to a ZMM register multiplies throughput by eight and costs nothing in issue slots — 64 bits per cycle becomes 512. This is the strongest version of the spoke's "the hardware wins now" claim: not that the compiler emits a good sequence, but that one instruction does what bit-twiddling-hacks spends a dozen operations approximating, and does it on 512 bits at once.

The 256-bit form buys nothing over the 512-bit form. VPOPCNTQ ymm and VPOPCNTQ zmm are both 1.00/cycle on the same port. Half the width for the same issue cost — so on a machine with AVX-512, using ZMM is not an optimization, it is the absence of a mistake.

One port is the ceiling, and it explains the anomaly this spoke recorded. valyu-billion-scale-vector-index measured 0.32 GH/s per core single-threaded and only 7.25 GH/s across 44 SMT threads — a 22× scale-up on 44 threads — and attributed it to threads "fighting over the same execution units". That page said so as an inference. This one is the measurement behind it: on Intel, VPOPCNTQ issues on p5 alone. Two SMT siblings on one core share that port, so the second thread cannot add popcount throughput; it can only fill the cycles the first one leaves idle. A 44-thread run on 22 cores returning 22× is what a one-port-per-core instruction predicts almost exactly.

AMD is a different machine. Zen 4 and Zen 5 issue VPOPCNTQ zmm on two FP pipes — 0.50 cycles per instruction, so two 512-bit popcounts per cycle, twice Intel's rate. Zen 5 also drops the latency to 1 cycle, against Intel's 3. For a dependency chain of popcounts that is a threefold difference; for the hamming-distance loops this spoke cares about, which are throughput-bound rather than latency-bound, the ports matter more. A portable "popcount is one cycle" claim is wrong in both directions, and any benchmark of a Hamming kernel has to name the vendor before its number means anything.

What it does not settle

This is per-instruction data. It does not include the load ports feeding the registers, the XOR that precedes the popcount in a hamming-distance kernel, or the horizontal reduction after it, and those are exactly where valyu-billion-scale-vector-index found its remaining wins. Nor does it cover ARM's CNT/ADDV, which is the other half of edge 6 and still unpaged. Paged 2026-08-30 from cortex-a76-optimization-guide, and the ARM answer is not a smaller version of this one: CNT works per byte lane, so a popcount there needs a horizontal ADDV costing latency 6 at one every two cycles — more than the count itself. Note the tier difference while comparing the two, because it is the whole reason this page opens by saying uops.info is not a vendor table: the ARM figures are the vendor's.

Related

population-count · hamming-distance · branchless-programming · valyu-billion-scale-vector-index · bit-twiddling-hacks · swar · cortex-a76-optimization-guide