Re: Changing default -march landscape
От | Nathan Bossart |
---|---|
Тема | Re: Changing default -march landscape |
Дата | |
Msg-id | ZqmooMcQOzTiCztd@nathan обсуждение исходный текст |
Ответ на | Re: Changing default -march landscape (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Changing default -march landscape
|
Список | 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
В списке pgsql-hackers по дате отправления: