The fused unpack_cmp kernels compare packed values against the constant at the column's full physical width (match_each_integer_ptype over T), even when bit_width is 3 or 4 bits. For those columns every value fits in u8, so the whole compare could run 16 lanes wide instead of 2, on the same fused kernel.
The blog post on compute push-down sketched this as future work ('running the comparison in u8-space... 0.075 of baseline') but current develop still compares at full T width — bit_width only gets passed down to the unpack step.
Proposal: in the BitPacked CompareKernel, when the array is unsigned and bit_width <= 8, cast the rhs literal into u8 space and run the fused compare against a u8-physical view of the packed buffer (values are guaranteed < 2^bit_width, so no sign/overflow subtleties for eq/neq/lt on non-negative data). Signed columns can keep the current path unless FoR/ZigZag already normalized them.
Happy to put a PR together if this seems reasonable.
The fused unpack_cmp kernels compare packed values against the constant at the column's full physical width (match_each_integer_ptype over T), even when bit_width is 3 or 4 bits. For those columns every value fits in u8, so the whole compare could run 16 lanes wide instead of 2, on the same fused kernel.
The blog post on compute push-down sketched this as future work ('running the comparison in u8-space... 0.075 of baseline') but current develop still compares at full T width — bit_width only gets passed down to the unpack step.
Proposal: in the BitPacked CompareKernel, when the array is unsigned and bit_width <= 8, cast the rhs literal into u8 space and run the fused compare against a u8-physical view of the packed buffer (values are guaranteed < 2^bit_width, so no sign/overflow subtleties for eq/neq/lt on non-negative data). Signed columns can keep the current path unless FoR/ZigZag already normalized them.
Happy to put a PR together if this seems reasonable.