I don't think anything discussed in this thread is ready for v17, so I am
going to punt it to v18.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Nov 28, 2023 at 7:51 AM Andres Freund wrote:
>
> Hi,
>
> On 2023-11-25 14:09:14 +0700, John Naylor wrote:
> > * Note: I have seen the threads with the idea of compiling multiple
> > entire binaries, and switching at postmaster start. I think it's a
> > good idea, but I also suspect detecti
Hi,
On 2023-11-25 14:09:14 +0700, John Naylor wrote:
> * Note: I have seen the threads with the idea of compiling multiple
> entire binaries, and switching at postmaster start. I think it's a
> good idea, but I also suspect detecting flags from the packager is an
> easier intermediate step.
It's
On Mon, Nov 27, 2023 at 03:21:53PM -0600, Nathan Bossart wrote:
> On Sat, Nov 25, 2023 at 02:09:14PM +0700, John Naylor wrote:
>> Sorry, I wasn't clear, I mean: detect that a packager passed
>> "-march=x86_64-v2" in the CFLAGS, so that a symbol in header files
>> would cause inlining of functions c
On Sat, Nov 25, 2023 at 02:09:14PM +0700, John Naylor wrote:
> On Thu, Nov 23, 2023 at 11:51 PM Nathan Bossart
> wrote:
>>
>> On Thu, Nov 23, 2023 at 05:50:48PM +0700, John Naylor wrote:
>> > On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart
>> > wrote:
>> >> One half-formed idea I have is to intro
On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart wrote:
>
> On Wed, Nov 22, 2023 at 02:54:13PM +0200, Ants Aasma wrote:
> > For reference, executing the page checksum 10M times on a AMD 3900X CPU:
> >
> > clang-14 -O2 4.292s (17.8 GiB/s)
> > clang-14 -O2 -msse4.12.859s (26.7
On Thu, Nov 23, 2023 at 11:51 PM Nathan Bossart
wrote:
>
> On Thu, Nov 23, 2023 at 05:50:48PM +0700, John Naylor wrote:
> > On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart
> > wrote:
> >> One half-formed idea I have is to introduce some sort of ./configure flag
> >> that enables all the newer ins
On Thu, Nov 23, 2023 at 05:50:48PM +0700, John Naylor wrote:
> On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart
> wrote:
>> One half-formed idea I have is to introduce some sort of ./configure flag
>> that enables all the newer instructions that your CPU understands.
>
> That's not doable,
It's n
On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart wrote:
>
> On Wed, Nov 22, 2023 at 02:54:13PM +0200, Ants Aasma wrote:
> > On Wed, 22 Nov 2023 at 11:44, John Naylor wrote:
> >> Poking in those files a bit, I also see references to building with
> >> SSE 4.1. Maybe that's an avenue that we should p
On Wed, Nov 22, 2023 at 02:54:13PM +0200, Ants Aasma wrote:
> On Wed, 22 Nov 2023 at 11:44, John Naylor wrote:
>> Poking in those files a bit, I also see references to building with
>> SSE 4.1. Maybe that's an avenue that we should pursue? (an indirect
>> function call is surely worth it for page-
On Wed, 22 Nov 2023 at 11:44, John Naylor wrote:
>
> On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart
> wrote:
> >
> > Presently, we ask compilers to autovectorize checksum.c and numeric.c. The
> > page checksum code actually lives in checksum_impl.h, and checksum.c just
> > includes it. But chec
On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart wrote:
>
> Presently, we ask compilers to autovectorize checksum.c and numeric.c. The
> page checksum code actually lives in checksum_impl.h, and checksum.c just
> includes it. But checksum_impl.h is also used in pg_upgrade/file.c and
> pg_checksums.
Hi,
On 2023-11-06 20:47:34 -0600, Nathan Bossart 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
On Sat, Nov 11, 2023 at 07:38:59PM +0700, John Naylor wrote:
> On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart
> 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 autov
On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart 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 th
(Unfortunately, I'm posting this too late for the November commitfest, but
I'm hoping this will be the first in a series of proposed improvements
involving SIMD instructions for v17.)
Presently, we ask compilers to autovectorize checksum.c and numeric.c. The
page checksum code actually lives in c
16 matches
Mail list logo
