On Tue, 26 Sep 2023, Jeff Law wrote:
> What ultimately pushed us to keep moving forward on this effort was > discovering numerous CRC loop implementations out in the wild, including 4 > implementations (IIRC) in the kernel itself. The kernel employs bitwise CRC only in look-up table generators. Which run at build time. You are quite literally slowing down the compiler in order to speed up generators that don't account for even one millisecond of kernel build time, and have no relation to its run-time performance. (incidentally you can't detect the actual CRC impls using those tables) > And as I've stated before, the latency of clmuls is dropping. I wouldn't be > terribly surprised to see single cycle clmul implmementations showing up > within the next 18-24 months. It's really just a matter of gate budget vs > expected value. In a commercial implementation? I'll take that bet. You spend gates budget like that after better avenues for raising ILP are exhausted (like adding more ALUs that can do clmul at a reasonable 3c-4c latency). > To reiterate the real goal here is to take code as-is and make it > significantly faster. Which code? Table generators in the kernel and xz-utils? > While the original target was Coremark, we've found similar bitwise > implementations of CRCs all over the place. There's no good reason that code > should have to change. But did you look at them? There's no point to optimize table generators either. Alexander
