Re: Popcount optimization using AVX512
Ants Aasma <ants.aasma@cybertec.at>
From: Ants Aasma <ants.aasma@cybertec.at>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, "Amonson,
Paul D" <paul.d.amonson@intel.com>, Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <dgrowleyml@gmail.com>, Andres Freund <andres@anarazel.de>, "Shankaran,
Akash" <akash.shankaran@intel.com>, Noah Misch <noah@leadboat.com>,
Matthias van de Meent <boekewurm+postgres@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-04T13:02:53Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix __attribute__((target(...))) usage.
- 41b98ddb77bf 18.0 landed
-
Use __attribute__((target(...))) for AVX-512 support.
- f78667bd910e 18.0 landed
-
Fix code for probing availability of AVX-512.
- 598e0114a3b1 17.0 landed
-
Optimize visibilitymap_count() with AVX-512 instructions.
- 41c51f0c68b2 17.0 landed
-
Optimize pg_popcount() with AVX-512 instructions.
- 792752af4eb5 17.0 landed
-
Inline pg_popcount() for small buffers.
- deb1486c7d36 17.0 landed
-
Avoid function call overhead of pg_popcount() in syslogger.c.
- 4133c1f45c54 17.0 landed
-
Refactor code for setting pg_popcount* function pointers.
- 6687430c98f3 17.0 landed
-
Inline pg_popcount{32,64} into pg_popcount().
- cc4826dd5e52 17.0 landed
-
Remove MSVC scripts
- 1301c80b2167 17.0 cited
-
Use ARMv8 CRC instructions where available.
- f044d71e331d 11.0 cited
-
Use Intel SSE 4.2 CRC instructions where available.
- 3dc2d62d0486 9.5.0 cited
On Thu, 4 Apr 2024 at 01:50, Nathan Bossart <nathandbossart@gmail.com> wrote: > If we can verify this approach won't cause segfaults and can stomach the > regression between 8 and 16 bytes, I'd happily pivot to this approach so > that we can avoid the function call dance that I have in v25. The approach I posted does not rely on masking performing page fault suppression. All loads are 64 byte aligned and always contain at least one byte of the buffer and therefore are guaranteed to be within a valid page. I personally don't mind it being slower for the very small cases, because when performance on those sizes really matters it makes much more sense to shoot for an inlined version instead. Speaking of which, what does bumping up the inlined version threshold to 16 do with and without AVX-512 available? Linearly extrapolating the 2 and 4 byte numbers it might just come ahead in both cases, making the choice easy. Regards, Ants Aasma