# Pre-RFC: Gradual Transition of NixOS x86\_64 Baseline to x86-64-v3 with an Intermediate Step to x86-64-v2

**URL:** https://discourse.nixos.org/t/pre-rfc-gradual-transition-of-nixos-x86-64-baseline-to-x86-64-v3-with-an-intermediate-step-to-x86-64-v2/35924
**Category:** RFCs
**Created:** [November 23, 2023, 5:45pm UTC](https://discourse.nixos.org/t/pre-rfc-gradual-transition-of-nixos-x86-64-baseline-to-x86-64-v3-with-an-intermediate-step-to-x86-64-v2/35924 "2023-11-23T17:45:01Z")
**Posts on this page:** 1
**Showing post:** 51

<div class="post-metadata">

### Author: ![Atemu](https://discourse.nixos.org/user_avatar/discourse.nixos.org/atemu/32/10383_2.png) [@Atemu](https://discourse.nixos.org/u/Atemu)
#### Post date: [January 7, 2024, 1:39am UTC](https://discourse.nixos.org/t/pre-rfc-gradual-transition-of-nixos-x86-64-baseline-to-x86-64-v3-with-an-intermediate-step-to-x86-64-v2/35924/51 "2024-01-07T01:39:31Z")

</div>

> [@boomshroom](#):
>
> depending on how you do it, it could involve rebuilding everything all the way down to the bootstrap tools just to optimize _one_ package.

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.

> [@boomshroom](#):
>
> changing the default does not mean completely dropping support. Much like how you can already set a micro-architecture higher than the baseline, increasing the baseline should still allow using older hardware at the cost of specifying so explicitly and less ability to use the caches.

\*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.

> [@boomshroom](#):
>
> They’d need to compile manually, but it should be possible for Hydra to build at least stdenv for multiple micro-architectures, even if not all of nixpkgs.

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 `$PATH` workaround 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.

---

_[View the full topic](https://discourse.nixos.org/t/pre-rfc-gradual-transition-of-nixos-x86-64-baseline-to-x86-64-v3-with-an-intermediate-step-to-x86-64-v2/35924)._