From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Changing default -march landscape |
Date: | 2024-07-31 02:59:44 |
Message-ID: | ZqmooMcQOzTiCztd@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 30, 2024 at 07:39:18PM -0700, Andres Freund wrote:
> On 2024-06-12 20:09:45 -0500, Nathan Bossart wrote:
>> 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 still think that's a good idea - but I don't think it's gonna deal well with
> the various avx512 "features". The landscape of what's supported on what CPU
> is so comically complicated that there's no way to build separate versions for
> everything.
Good point.
> We can hide most of the dispatch cost in a static inline function that only
> does the runtime test if size is large enough - the size is a compile time
> constant most of the time, which optimizes away the dispatch cost most of the
> time. And even if not, an inlined runtime branch is a *lot* cheaper than an
> indirect function call.
I ended up doing precisely this for pg_popcount()/pg_popcount_masked(),
although not quite as sophisticated as what you propose below. I'll look
into expanding on this strategy in v18.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-07-31 03:01:50 | Re: Popcount optimization using AVX512 |
Previous Message | Andres Freund | 2024-07-31 02:43:08 | Re: Popcount optimization using AVX512 |