Re: add AVX2 support to simd.h
John Naylor <johncnaylorls@gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Ants Aasma <ants@cybertec.at>, pgsql-hackers@postgresql.org
Date: 2024-01-08T09:03:50Z
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 →
-
Improve style of pg_lfind32().
- 7188a7806d20 17.0 landed
-
Fix compiler warning for pg_lfind32().
- 1f42337be535 17.0 landed
-
Micro-optimize pg_lfind32().
- 7644a7340c8a 17.0 landed
-
Introduce helper SIMD functions for small byte arrays
- 9f225e992bed 17.0 cited
-
Optimize xid/subxid searches in XidInMVCCSnapshot().
- 37a6e5df3713 16.0 cited
On Sat, Jan 6, 2024 at 12:04 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > I've been thinking about the configuration option approach. ISTM that > would be the most feasible strategy, at least for v17. A couple things > come to mind: > > * This option would simply map to existing compiler flags. We already have > ways to provide those (-Dc_args in meson, CFLAGS in autoconf). Perhaps > we'd want to provide our own shorthand for certain platforms (e.g., ARM), > but that will still just be shorthand for compiler flags. > > * Such an option would itself generate some maintenance cost. That could > be worth it because it formalizes the Postgres support for those options, > but it's still one more thing to track. > > Another related option could be to simply document that we have support for > some newer instructions that can be enabled by setting the aforementioned > compiler flags. That's perhaps a little less user-friendly, but it'd avoid > the duplication and possibly reduce the maintenance cost. I also wonder if > it'd help prevent confusion when CFLAGS and this extra option conflict. The last one might offer more graceful forward compatibility if the multiple-binaries idea gets any traction some day, because at that point the additional config options are not needed, I think. Another consideration is which way would touch the fewest places to work with Windows, which uses the spelling /arch:AVX2 etc. One small thing I would hope for from the finial version of this is the ability to inline things where we currently indirect depending on a run-time check. That seems like "just work" on top of everything else, and I don't think it makes a case for either of the above.