RE: Popcount optimization using AVX512
Amonson, Paul D <paul.d.amonson@intel.com>
From: "Amonson, Paul D" <paul.d.amonson@intel.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@alvh.no-ip.org>, "Shankaran, Akash" <akash.shankaran@intel.com>, Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>, "Matthias van
de Meent" <boekewurm+postgres@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-13T17:52:14Z
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
> -----Original Message----- > From: Nathan Bossart <nathandbossart@gmail.com> > Sent: Wednesday, March 13, 2024 9:39 AM > To: Amonson, Paul D <paul.d.amonson@intel.com> > +extern int pg_popcount32_slow(uint32 word); extern int > +pg_popcount64_slow(uint64 word); > > +/* In pg_popcnt_*_accel source file. */ extern int > +pg_popcount32_fast(uint32 word); extern int pg_popcount64_fast(uint64 > +word); > > Can these prototypes be moved to a header file (maybe pg_bitutils.h)? It > looks like these are defined twice in the patch, and while I'm not positive that > it's against project policy to declare extern function prototypes in .c files, it > appears to be pretty rare. Originally, I intentionally did not put these in the header file as I want them to be private, but they are not defined in this .c file hence extern. Now I realize the "extern" part is not needed to accomplish my goal. Will fix by removing the "extern" keyword. > + 'pg_popcnt_choose.c', > + 'pg_popcnt_x86_64_accel.c', > > I think we want these to be architecture-specific, i.e., only built for > x86_64 if the compiler knows how to use the relevant instructions. There is a > good chance that we'll want to add similar support for other systems. > The CRC32C files are probably a good reference point for how to do this. I will look at this for the 'pg_popcnt_x86_64_accel.c' file but the 'pg_popcnt_choose.c' file is intended to be for any platform that may need accelerators including a possible future ARM accelerator. > +#ifdef TRY_POPCNT_FAST > > IIUC this macro can be set if either 1) the popcntq test in the autoconf/meson > scripts passes or 2) we're building with MSVC on x86_64. I wonder if it would > be better to move the MSVC/x86_64 check to the autoconf/meson scripts so > that we could avoid surrounding large portions of the popcount code with this > macro. This might even be a necessary step towards building these files in an > architecture-specific fashion. I see the point here; however, this will take some time to get right especially since I don't have a Windows box to do compiles on. Should I attempt to do this in this patch? Thanks, Paul