On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart <nathandboss...@gmail.com> wrote: > > > I suspect that there could be a regression lurking for some inputs > > that the benchmark doesn't look at: pg_lfind32() currently needs to be > > able to read 4 vector registers worth of elements before taking the > > fast path. There is then a tail of up to 15 elements that are now > > checked one-by-one, but AVX2 would increase that to 31. That's getting > > big enough to be noticeable, I suspect. It would be good to understand > > that case (n*32 + 31), because it may also be relevant now. It's also > > easy to improve for SSE2/NEON for v17. > > Good idea. If it is indeed noticeable, we might be able to "fix" it by > processing some of the tail with shorter vectors. But that probably means > finding a way to support multiple vector sizes on the same build, which > would require some work.
What I had in mind was an overlapping pattern I've seen in various places: do one iteration at the beginning, then subtract the aligned-down length from the end and do all those iterations. And one-by-one is only used if the total length is small.
