On Thu, Jun 13, 2024 at 1:09 PM Nathan Bossart <nathandboss...@gmail.com> wrote: > Now, let's say we require x86-64-v2. Once we have that, we can avoid the > function pointer on many more x86 machines. While that sounds great, now > we have a different problem. If someone wants to add, say, AVX-512 support > [0], which is a much newer instruction set, we'll need to use the function > pointer again. And we're back where we started. We could instead just ask > folks to compile with --march=native, but then these optimizations are only > available for a subset of users until we decide the instructions are > standard enough 20 years from now.
The way I think about it, it's not our place to require anything (I mean, we can't literally put -march=XXX into our build files, or if we do the Debian et al maintainers will have to remove them by local patch because they are in charge of what the baseline is for their distro), but we should do the best thing possible when people DO build with modern -march. I would assume for example that Amazon Linux is set up to use a default -march that targets the actual minimum microarch level on AWS hosts. I guess what I'm pointing out here is that the baseline is (finally!) moving on common distributions, and yet we've coded things in a way that doesn't benefit... > 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...
