While researching the feasibility of glibc-hwcaps, I came across this wiki article from openSUSE discussing this topic. I’d consider it required reading.
3 Likes
That could be a compromise, building specific stuff in v2, v3, for example we could build the kernel potentially in v2 and v3, and in general, I’m up for optimizing packages like Clear Linux does them.
Note that even building “specific stuff in v2, v3” will likely still preclude users as most of the interesting stuff to optimise is stuff people actually want to use. On systems with unsupported CPUs, those will just crash. After having thought about that a bit more thoroughly, I must retract the recommendation of that approach.
I think the most feasible way forward right now would be to build infrastructure to support glibc-hwcaps and then have it organically enabled it on packages where it makes sense.
I do not see the general target being raised any time soon unless the data situation improves; RFC or not.
4 Likes
Data is def one of the biggest problems, the lack of data, it quite a hard solution to find though because to benchmark this you would need a dedicated server right?
You could benchmark on the very device you’re on right now. As long as it’s reasonably modern (CPU from the past years or so), that should be fairly representative.
I guess (not certain) that this forum will have a bias towards people who don’t need to use old hardware.
FWIW, my main computer uses a Xeon Sandy Bridge from 2013, which I think supports v2 but not v3.
My laptop has a CPU from 2011 because developers with slower and older hardware necessarily produce more performant software. I also sometimes build with -march=native and -mtune=native, why can’t you ricers do the same?
Intel is going to keep bloating their CPUs regardless if makes the hardware better or worse because it’s an intrinsic part of their corporate culture. The Management Engine and Meltdown should have made it obvious that they won’t be held responsible for implementing bad features.
2 Likes
lol! That maybe me spit my (decaf) coffee out.
I suggest all nix developers declock their machines to the slowest speeds possible, remove as much ram as they can, installed a tiny disk, and connected to a 300 baud modem.
this should provide the productivity results we need.
are we allowed to have graphics? if so , how many colours?
1 Like
It’s possible to use existing aarch64 builders to build for armv7l (yes, the Ampere Altra Q80-30 can run 32-bit code), I’ve even added the necessary configuration to our community aarch64 build box for everyone to try. The real question is whether we care enough to actually add support for armv7l-linux on our main Hydra instance.
1 Like
You are absolutely right, but I want Nix to succeed and believe it would be very valuable from a marketing perspective. Unfortunately, it seems that adding an additional hydra build channel is just not feasible
2 Likes
Thanks for sharing this. The piece about glibc-hwcaps only being applicable for shared libraries, and not binaries, is a significant issue and would limit how much can be gained using only glibc-hwcaps.
Another somewhat unrelated performance optimization that could be done is using BOLT?
Sure but I don’t think that in itself needs an RFC; that’d just be an uncontroversial improvement like any other.
Taking advantage of it generally is would require a switch to clang/llvm as the default compiler. This is somewhat easy for us to do technically but may require a bit more community input given that GCC has been the standard compiler for Linux for most distros (including us) for almost the entire history of Linux distros and that it’s FLOSS vs clang’s permissive FOSS license.
Even there I’d only open an RFC when there’s enough people who’d actually care about that enough to block a PR implementing that.
1 Like
Where would someone propose this though without it getting buried?
You’d make a PR, state/show the benefits of it and start tagging people who might feel “responsible” or are knowledgeable about it.
To gather community feedback, you could also create an issue and tag it or a discourse thread like this one. This one certainly did not get buried 
1 Like
My (home) desktop is an Athlon II X4 620, so only v1 support.[1]
Yes, it is old and I don’t want to recompile e.g. Firefox on it on a regular basis. But it is perfectly capable for web browsing, mail and editing Nix configs. Actually, having this modest machine was one of the reasons I got into NixOS. 
I’m all in for optimizing software that benefits from these extensions of the instructions set. But as NixOS can be a lightweight distro (aside from disk space), keeping compatibility with older machines would be nice.
How about introducing a “max-microarch-level” option and forcing it to x86_64_v1 for a core subset of derivations (such as the Kernel, Python) and maybe have two builds for a few selected huge packages (Firefox, Chrome, LibreOffice, VLC) such that older systems can still benefit from the cache (and those are the system that profit most).
[1] I don’t want to sound selfish here, just throwing in one of my machines as an example. Imho NixOS is a very fine system to keep older hardware alive and usable.
Edit/Addendum: The installer could make use of GitHub - HenrikBengtsson/x86-64-level: x86-64-level - Get the x86-64 Microarchitecture Level on the Current Machine to set the max-microarch-level in hardware-configuration.nix
2 Likes
Sadly, I don’t think that is reasonable. A GUI ISO contains a couple thousand derivations. Now, not all of those are packages obviously but I’d have called such an effort infeasible even if it was just hundreds of packages.
As far as I’m aware, we are not using O3 because sometimes decreases performance (by agressive unrolling, etc).
But, has anyone ever benchmarked a full-o3 system to an o2 system?
It might be more relevant than x86-64-v2 since it doesn’t involve dropping hardware.
O3 includes potentially optimisations that produce potentially unsafe and/or wrong code. We won’t use that.
2 Likes
Hm… Do we have metrics on misses on cache.nixos.org? If a lot of users have the max microarch set to v1 in their configs then we should see a lot of misses for the relevant packages and can selectively choose what to build.
Or we push on the development Trustix to get a (distributed) community cache of v1 builds.