There’s rarely such a thing as “optimising one package”. The vast majority of packages use libraries for much (if not most) of their work. This means these libraries also influence the package’s performance.
I.e. optimising ffmpeg would likely gain very little (if any) vorbis encoding performance because ffmpeg uses a dedicated library for the performance-critical part of that.
*no ability to use the caches.
You likely wouldn’t even be able to boot an installer ISO on an unsupported CPU.
Raising the default baseline will exclude the majority of users of then-unsupported hardware. There’s no way around it.
Just the stdenv wouldn’t really help anyone. If you’re going to be building your average desktop closure, having the stdenv cached or not doesn’t make a huge difference.
Suffice to say, this is not a feasible option if you want users of then-unsupported hardware to still be able to reasonably use NixOS. Especially considering their hardware likely being highly unsuited for compiling modern software.
If anyone should be building their own packages, it’s the users of powerful modern CPUs who need the handful of % mean improvement for …what reason exactly?
Anyhow, I think it’s reasonably well established that:
- There is a point to this. With v3, the increase is small and highly package dependant but it’s there, it’s real and likely desirable, especially for those few packages.
- There are many users who would be effectively excluded from using the distro were the baseline raised to v3 and even some who would be excluded by v2.
- We’re can have our cake and eat it too at the expense of a closure size increase (how much?) using glibc-hwcaps in addition to the
$PATHworkaround for the executables themselves.
The next step is to build code infrastructure for glibc-hwcaps usage and use it on packages&libraries that benefit.
Until that is done and well established, I think we can pause any discussion on raising the baseline.