> In 2020, through a collaboration between AMD, Intel, Red Hat, and SUSE, three microarchitecture levels (or feature levels) on top of the x86-64 baseline were defined: x86-64-v2, x86-64-v3, and x86-64-v4.[41][42] These levels define specific features that can be targeted by programmers to provide compile-time optimizations. The features exposed by each level are as follows:[43]
Lack of -v3 binaries are common in Docker containers. Most, if not all of development, CI and deployment targets support -v3. And yet images like Postgres or Redis are built with the absolute lowest common denominator in mind.
How many CPU cycles are wasted globally because of this? It’s nuts
The newest status update I could find is this [0] but that's over a year old too. Honestly I would rather if they worked on providing ARM64 packages. I know about and use Arch Linux ARM but that's a completely different project with different people and even fewer resources, which often manifests in broken packages (right now generating initramfs fails without manual intervention [1]). I remember for a long time Arch Linux didn't have any build servers and packagers mostly used their own machines to build packages. Not sure what's the current state of things but if that's still the case, then it's quite understandable that not everybody has an ARM64 machine to build on.
It's all part of the same problem domain; How do we rearchitecture the release process of Arch so we can support multiple architectures.
The amount of people that understand this problem domain, have the time+energy to work on it and is actually able to see it too completion is.. well. Not many.
I tried to hack on buildbot, as I wrote in that email, but I have been questioning the maintainability of trying to fit what we need on top of buildbot. In constrast to writing something from scratch.
I wonder if something like that should be built on top of GitLab now that you have migrated to it. GitLab CI supports multiple runners for a single job, so the workflow might be that you merge a merge request which modifies PKGBUILD/.SRCINFO, the CI picks it up and based on labels/tags dispatches it to different runners running possibly on a completely different architecture for building. The runners then send the artifacts back and the job publishes them. The nice thing about this is that most of the parts are already there handled by GitLab itself, you just have to draw the rest of the owl.
This doesn't help at all as you need to coordinate so-name rebuilds across multiple architectures. This implies you need to some way to orchestrate a staging repository and have building do rebuilds towards this repo interactively until all issues are solved.
Retrofitting this ontop of gitlab sounds painfull. I don't even know if we would like to be that tied to a singular forge.
The "building infrastructure" of Arch is just Package Maintainers building and publishing packages they maintain. There was some resistance from PMs against supporting another architecture.
Latest mention is over a year old[0]. This situation invited third parties to release unofficial Arch derivatives built for x86-64-v3[1], splitting the community.
The change was withdrawn to improve it for F41 [1]. There were concerns about using $PATH to find executables for v2/v3/v4, especially for containers and absolute path specifications.
These are bad processors born out of ridiculous market segmentation done by Intel for which we pay for dearly (also worth calling out making ECC server-only feature, because profit, exabytes of user data corrupted be damned).
Not only they are not worth targeting, it is a moral imperative not to consider them for pieces of software like PostgreSQL. If the push comes to shove, a "-compat" or "-legacy" flavour of binaries can be offered to select few users which use older systems with CPUs made before 2011 (pre-Sandy-Bride and Jaguar respectively), which would allow the overall ecosystem get healthier while not leaving affected people behind.
The Atom-based processors are bad not because of market segmentation but because Intel is perennially unable to make more than one good architecture at a time. The ones that are bad because of market segmentation are the processors with a Core family microarchitecture lobotomized down to the i3, Pentium or Celeron product lines, leaving them years behind on feature support that's physically present but fused off.
!!! The following binary packages have been ignored due to non matching USE:
=sys-libs/glibc-2.38-r10 -multilib -stack-realign
=sys-libs/glibc-2.38-r10 systemd
So in order to use binary packages, I either need to switch to systemd, or switch to no-multilib and manually enable all the desktop-related USE flags. Seems too tedious to bother right now.
If you're currently building from source, presumably you have `-march=native` in your CFLAGS anyway, so you wouldn't gain any perf improvements from using the pre-compiled ones.
