Re: v13: Performance regression related to FORTIFY_SOURCE - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: v13: Performance regression related to FORTIFY_SOURCE
Date
Msg-id CAH2-WzmU=Nxh4W4DfuajtQ5eJonvCKEWetDjMkE_NMBWG=_xkg@mail.gmail.com
Whole thread Raw
In response to v13: Performance regression related to FORTIFY_SOURCE  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: v13: Performance regression related to FORTIFY_SOURCE  (Jeff Davis <pgsql@j-davis.com>)
Re: v13: Performance regression related to FORTIFY_SOURCE  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Sun, Apr 19, 2020 at 3:07 PM Jeff Davis <pgsql@j-davis.com> wrote:
> 1. Is my analysis correct?
> 2. What is the scale of this problem? What about other platforms or
> compilers? Are there other cases in PostgreSQL that might suffer from
> the use of FORTIFY_SOURCE?
> 3. Even if this is the compiler's fault, should we still fix it?

The precedent set by MemSetAligned() is that sometimes we see the code
generated by very common standard library functions as a problem for
us to fix, or to paper over.

Is it possible that the issue has something to do with what the
compiler knows about the alignment of the tapes back when they were a
flexible array vs. now, where it's a separate allocation? Perhaps I'm
over reaching, but it occurs to me that MemSetAligned() is itself
concerned about the alignment of data returned from palloc(). Could be
a similar issue here, too.

Some guy on the internet says that microarchitectural issues can make
__memcpy_avx_unaligned() a lot faster that the "rep movsq" instruction
(which you mentioned was a factor on the other thread) in some cases
[1]. This explanation sounds kind of plausible.

[1] https://news.ycombinator.com/item?id=12050579
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: PG compilation error with Visual Studio 2015/2017/2019
Next
From: Ranier Vilela
Date:
Subject: Re: [PATCH] Small optimization across postgres (remove strlenduplicate usage)