Re: autovectorize page checksum code included elsewhere

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: autovectorize page checksum code included elsewhere
Date: 2023-11-11 12:38:59
Message-ID: CANWCAZYezjS0iM60i8zVnSWFtXu5=c-K7wafB-J9Ug0YkC7XbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> Separately, I'm wondering whether we should consider using CFLAGS_VECTORIZE
> on the whole tree. Commit fdea253 seems to be responsible for introducing
> this targeted autovectorization strategy, and AFAICT this was just done to
> minimize the impact elsewhere while optimizing page checksums. Are there
> fundamental problems with adding CFLAGS_VECTORIZE everywhere? Or is it
> just waiting on someone to do the analysis/benchmarking?

It's already the default for gcc 12 with -O2 (looking further in the
docs, it uses the "very-cheap" vectorization cost model), so it may be
worth investigating what the effect of that was. I can't quickly find
the equivalent info for clang.

That being the case, if the difference you found was real, it must
have been due to unrolling loops. What changed in the binary?

https://gcc.gnu.org/gcc-12/changes.html
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2023-11-11 13:00:00 Re: pg_basebackup check vs Windows file path limits
Previous Message Alexander Lakhin 2023-11-11 12:00:00 Re: ResourceOwner refactoring