I have a Ryzen 7000 setup, and of course I’d want my system build with binaries which take advantage of the new architecture and instructions (AVX-512) in this case.
NixPKGs architecture.nix defines zenver4 as a supported architecture, along with others.
To be clear, I want nixos-rebuild to automatically get the binaries optimised for my CPU and/or compile if needed.
This would require upstream building those binaries, which it doesn’t, and it would be unreasonable to do so for all architectures under the sun.
To be clear, you will need to compile all of those binaries, and nixpkgs packages aren’t exactly optimized for building the minimum feature set like e.g. gentoo, so this will take a lot of time.
To actually change the setting, you can set nixpkgs.hostPlatform to change gcc.arch and gcc.tune for the deployed configuration. YMMV with actually building successfully.
would it be possible to set it up to build packages with AVX-512 (and maybe other settings that might help with build/runtime speeds) only for packages that aren’t yet in the cache or that are manually specified? That should help with faster builds in general and better performance where manually set
No. Nix operates strictly by whether build inputs match. If the inputs are the same, and the cache has the binary, you can grab it from the cache. If the inputs are not the same because you changed the build architecture, you have to build it.
Anything else would leak side effects and make your builds non-reproducible.
Yep. It’s a little awkward, because you have to set a second nixpkgs instance: Build flags - NixOS Wiki
Rather than using nix-build on it you can of course use that expression in a configuration.nix and put it in environment.systemPackages. You can also make that instance shared for evaluation speed by putting it in module._args and such, but now we’re talking writing clean NixOS modules.
Note that any reverse dependencies will still have to be rebuilt, so setting this for some deep library in an overlay will not be much different than the alternative. This may indeed be useful for some leaf packages that do heavy compute, though, or even packages that you’re building downstream anyway.