5 ms·

Yeah the edited version is correct; it matches up each group of eight "x" values with one "A" matrix (such that, in the bitwise representation of the arguments,

by dzaima 3y ago

Yeah the edited version is correct; it matches up each group of eight "x" values with one "A" matrix (such that, in the bitwise representation of the arguments, there's no data transfer happening across 64-bit blocks; this ends up quite limiting if you want different matrices, so most of the uses are ones where the matrix is the same for all elements).

dragontamer 3y ago
This is nuts. https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=AFFINE%2520&ig_expand=3657 https://www.intel.com/content/www/us/en/docs/intrinsics-guid... Intel's documentation is claiming 0.5 CPI, or a bandwidth of 2x of these operations per clock tick. I mean, forget about bit-shuffling or permuting. I feel like with the right configuration, you can operate 512-bits of CRC32 calculations in parallel, maybe in like 3 or 4 instructions (or ~2 clock ticks) or something incredibly fast. > this ends up quite limiting if you want different matrices, so most of the uses are ones where the matrix is the same for all elements Elliptical Curves is the obvious use case. CRC is one immediate use where all the matricies are the same (and linear in the GF-field), albeit the reduction needs to be done "somehow" but that can be figured out in a later operation... probably... AES encryption is operated over 4x sets of GF(2^8). I know that AES is already got its own instruction but a full software implementation of the GF-operations behind AES might be possible with this. -------------- I dunno, there's a lot of things I see already as immediately applicable where the "A" matrix is nearly constant across all elements. And for those where A isn't constant, pipelined operation is obvious. 8x different "A" matrixies means that we can build a "pipeline" where we can AVX512-shift the bytes down by 8 as well each clock tick, and build an 8x-deep pipeline and apply those 8x A matricies in parallel while consuming 64-bytes per clock-tick, while performing 512-bit worth of operation per clock tick (no, 1024-bits because Intel chips support 2x such operations per clock tick). Pipelining, full parallelization, etc. etc. So many architectures are possible with this spec. IMO, it shows that Intel knows what they're doing with these intrinsic, and I think this is something now GPU can accomplish yet. Truly an advantage to Intel chips only. Very nice instruction. The practical benefits though (Intel-only, exceptionally arcane with very few programmers who can work with, etc. etc.) may make it a dead instruction though. But I'm sure some wizard out there is going to do something cool with this instruction over the next 5 years. (It'd probably take weeks of practice on some practice problem just to learn how to use this instruction correctly, lol)
- dzaima 3y ago
  0.5 CPI is for the 128-bit or 256-bit versions; 512-bit ones are 1 CPI. Same on Zen 4 according to uops.info - https://uops.info/table.html?search=vgf2p8affineqb%20zmm&cb_lat=on&cb_tp=on&cb_ICL=on&cb_TGL=on&cb_ADLP=on&cb_ZEN4=on&cb_measurements=on&cb_avx512=on https://uops.info/table.html?search=vgf2p8affineqb%20zmm&cb_...
  - dragontamer 3y ago
    That's still crazy to me that such a powerful operation is done per clock tick. I appreciate the uops.info table. I've never known about that site, so I'll save that off now. Very nicely presented latency/throughput stats. ----------- EDIT: Looks like https://www.felixcloutier.com/x86/gf2p8mulb https://www.felixcloutier.com/x86/gf2p8mulb also exists. The 0b1'0001'1011 polynomial / x^8 + x^4+x^3+x+1 intrigues me, anyone have any idea why this particular GF-polynomial was chosen? EDIT2: Looks like its related to AES somehow (https://crypto.stackexchange.com/questions/51848/why-is-x8-x4-x3-x-1-used-in-aess-rcon https://crypto.stackexchange.com/questions/51848/why-is-x8-x...). The CPU-chip already has AES-instructions hard coded for modern TLS reasons (and AES-acceleration is going to be in every modern chip). So I'm thinking that these multiplication routines might be "sharing the fundamental units" of the Intel CPU, and Intel is wondering if anyone out there can make due with the individual steps of Rinjadel/AES in other applications.

by dzaima 3y ago

dragontamer 3y ago

This is nuts. https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=AFFINE%2520&ig_expand=3657 https://www.intel.com/content/www/us/en/docs/intrinsics-guid... Intel's documentation is claiming 0.5 CPI, or a bandwidth of 2x of these operations per clock tick. I mean, forget about bit-shuffling or permuting. I feel like with the right configuration, you can operate 512-bits of CRC32 calculations in parallel, maybe in like 3 or 4 instructions (or ~2 clock ticks) or something incredibly fast. > this ends up quite limiting if you want different matrices, so most of the uses are ones where the matrix is the same for all elements Elliptical Curves is the obvious use case. CRC is one immediate use where all the matricies are the same (and linear in the GF-field), albeit the reduction needs to be done "somehow" but that can be figured out in a later operation... probably... AES encryption is operated over 4x sets of GF(2^8). I know that AES is already got its own instruction but a full software implementation of the GF-operations behind AES might be possible with this. -------------- I dunno, there's a lot of things I see already as immediately applicable where the "A" matrix is nearly constant across all elements. And for those where A isn't constant, pipelined operation is obvious. 8x different "A" matrixies means that we can build a "pipeline" where we can AVX512-shift the bytes down by 8 as well each clock tick, and build an 8x-deep pipeline and apply those 8x A matricies in parallel while consuming 64-bytes per clock-tick, while performing 512-bit worth of operation per clock tick (no, 1024-bits because Intel chips support 2x such operations per clock tick). Pipelining, full parallelization, etc. etc. So many architectures are possible with this spec. IMO, it shows that Intel knows what they're doing with these intrinsic, and I think this is something now GPU can accomplish yet. Truly an advantage to Intel chips only. Very nice instruction. The practical benefits though (Intel-only, exceptionally arcane with very few programmers who can work with, etc. etc.) may make it a dead instruction though. But I'm sure some wizard out there is going to do something cool with this instruction over the next 5 years. (It'd probably take weeks of practice on some practice problem just to learn how to use this instruction correctly, lol)

dzaima 3y ago
0.5 CPI is for the 128-bit or 256-bit versions; 512-bit ones are 1 CPI. Same on Zen 4 according to uops.info - https://uops.info/table.html?search=vgf2p8affineqb%20zmm&cb_lat=on&cb_tp=on&cb_ICL=on&cb_TGL=on&cb_ADLP=on&cb_ZEN4=on&cb_measurements=on&cb_avx512=on https://uops.info/table.html?search=vgf2p8affineqb%20zmm&cb_...
- dragontamer 3y ago
  That's still crazy to me that such a powerful operation is done per clock tick. I appreciate the uops.info table. I've never known about that site, so I'll save that off now. Very nicely presented latency/throughput stats. ----------- EDIT: Looks like https://www.felixcloutier.com/x86/gf2p8mulb https://www.felixcloutier.com/x86/gf2p8mulb also exists. The 0b1'0001'1011 polynomial / x^8 + x^4+x^3+x+1 intrigues me, anyone have any idea why this particular GF-polynomial was chosen? EDIT2: Looks like its related to AES somehow (https://crypto.stackexchange.com/questions/51848/why-is-x8-x4-x3-x-1-used-in-aess-rcon https://crypto.stackexchange.com/questions/51848/why-is-x8-x...). The CPU-chip already has AES-instructions hard coded for modern TLS reasons (and AES-acceleration is going to be in every modern chip). So I'm thinking that these multiplication routines might be "sharing the fundamental units" of the Intel CPU, and Intel is wondering if anyone out there can make due with the individual steps of Rinjadel/AES in other applications.