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 →
  1. Improve style of pg_lfind32().

  2. Fix compiler warning for pg_lfind32().

  3. Micro-optimize pg_lfind32().

  4. Introduce helper SIMD functions for small byte arrays

  5. Optimize xid/subxid searches in XidInMVCCSnapshot().

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.