On Mon, Jan 5, 2026 at 4:02 PM [email protected] < [email protected]> wrote: > > >There was already a proposal to use armv8-a+crypto, which is more > widely available and works on smaller inputs. > > Our implementation with SVE2 is able to gain better performance than > https://www.postgresql.org/message-id/CANWCAZaKhE%2BRD5KKouUFoxx1EbUNrNhcduM1VQ%3DDkSDadNEFng%40mail.gmail.com > > I've benchmarked our SVE2 implementation against armv8-a+crypto, and the results show substantial improvements.
Thanks for testing! For future reference, please don't top post. We prefer to reply in-line to relevant points. > These buffer sizes are particularly relevant for PostgreSQL workloads: > > 8KB: Default page size (28.8% faster checksumming) > 4KB: Alternative page size configuration (36.1% faster) We don't use CRC for page checksums. Did you mean FPI in WAL? > 512B-2KB: Typical WAL record sizes (32-39% faster) That seems on the high end, but your mileage may vary. Even if it were typical, the difference isn't that impressive, given that the patch seems to use double the number of (twice as wide?) accumulators. In any case, I suspect going from (say) 3x to 4x won't make much difference in profiles for those workloads, aside from having less portability. Plus, it seems more widely useful to allow a cutoff at 64 bytes, rather than 128. > While armv8-a+crypto has broader current deployment, SVE2 is already available in production cloud infrastructure: AWS Graviton 4, Ampere AmpereOne, and NVIDIA Grace (all released 2023). As ARMv9 adoption continues, these gains become increasingly relevant. That's pretty recent. > Rather than choosing one approach over the other, perhaps we could implement both with runtime CPU detection? That's bad for maintainability. The broader point is I've already found something that seems good enough (and can be configured differently if necessary), portable enough, and is already used for our x86 vectorized implementation. I just wasn't going to make it a priority until someone showed up with enough interest to test and review it. -- John Naylor Amazon Web Services
