4 ms·
Took a brief look. Seems like a cool idea, but it smells like early days. The example listed on github (population count of 1s in a 64bit register) I thought
by tslug 11y ago
Took a brief look. Seems like a cool idea, but it smells like early days.
The example listed on github (population count of 1s in a 64bit register) I thought was a little underwhelming. It took a poorly optimized loop, for some reason came to the conclusion that 0's would be more popular than they would be with a uniform distribution of inputs as you'd get in a compressed stream of bytes, for example (did I miss something there?), so it added some overhead to special case 0 even though 0 only takes one iteration through the loop anyway, and the loop still required up to 64 iterations if you have the high bit set. If doing population counts on compressed data (most of what traverses the internet), odds are you'll generally have at least one bit set in every byte, so it'll usually be doing a lot of iterations.
If the code matters, then on an x86_64 arch, you can definitely burn a few cache lines to use lookup tables for considerably more speed. 256 byte lookup (4 cache lines) to bring the loop down to 8 iterations, 64k (1k cache lines) to bring it down to 4, assuming you're confident you can warm that latter table up in the dcache with enough activity.
I guess it isn't making guesses with lookup tables yet, but that's when I'd get all nipply.
- barsonme 11y ago> I thought was a little underwhelming. I agree, but... > so it added some overhead to special case 0 even though 0 only takes one iteration through the loop anyway, and the loop still required up to 64 iterations if you have the high bit set. Didn't it simply replace the body of `size_t popcnt(uint64_t x)` with the `popcnt` instruction? Or am I looking at the wrong test?
- joosters 11y agoDidn't it optimise the whole function into the special purpose popcnt instruction? Are you confusing the initial gcc code with the output?