Re: Changing default -march landscape

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Changing default -march landscape
Дата
Msg-id CABUevEy7ynyJ4n9JHUzUYEBWVx32PSSCap=S=yW9F4jcrLNFbg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Changing default -march landscape  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: Changing default -march landscape
Список pgsql-hackers
On Thu, Jun 13, 2024 at 9:41 AM Peter Eisentraut <peter@eisentraut.org> wrote:
On 13.06.24 04:00, Nathan Bossart wrote:
> That's true, but my point is that as soon as we start avoiding function
> pointers more commonly, it becomes difficult to justify adding them back in
> order to support new instruction sets.  Should we just compile in the SSE
> 4.2 version, or should we take a chance on AVX-512 with the function
> pointer?
>
>>> The idea that's been floating around recently is to build a bunch of
>>> different versions of Postgres and to choose one on startup based on what
>>> the CPU supports.  That seems like quite a lot of work, and it'll increase
>>> the size of the builds quite a bit, but it at least doesn't have the
>>> aforementioned problem.
>>
>> I guess another idea would be for the PGDG packagers or someone else
>> interested in performance to create repos with binaries built for
>> these microarch levels and users can research what they need.  The new
>> -v2 etc levels are a lot more practical than the microarch names and
>> individual features...
>
> Heartily agreed.

One thing that is perhaps not clear (to me?) is how much this matters
and how much of it matters.  Obviously, we know that it matters some,
otherwise we'd not be working on it.  But does it, like, matter only
with checksums, or with thousands of partitions, or with many CPUs, or
certain types of indexes, etc.?

If we're going to, say, create some recommendations for packagers around
this, how are they supposed to determine the tradeoffs?  It might be
easy for a packager to set some slightly-higher -march flag that is in
line with their distro's policies, but it would probably be a lot more
work to create separate binaries or a separate repository for, say,
moving from SSE-something to AVX-something.  And how are they supposed
to decide that, and how are they supposed to communicate that to their
users?  (And how can we get different packagers to make somewhat
consistent decisions around this?)

We have in a somewhat similar case quite clearly documented that without
native spinlock support everything will be terrible.  And there is
probably some information out there that without certain CPU support
checksum performance will be terrible.  But beyond that we probably
don't have much.

Yeah, I think it's completely unreasonable  to push this on packagers and just say "this is your problem now". If we do that, we can assume the only people to get any benefit from these optimizations are those that use a fully managed cloud service like azure or RDS.

They can do it, but we need to tell them how and when. And if we intend for packagers to be part of the solution we need to explicitly bring them into the discussion of how to do it, at a fairly early stage (and no, we can't expect them to follow every thread on hackers).

--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Sharma
Дата:
Сообщение: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Следующее
От: "Li, Yong"
Дата:
Сообщение: Re: Proposal to add page headers to SLRU pages