# 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:** 20
**Page:** 2

<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: [November 25, 2023, 6:46am 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/21 "2023-11-25T06:46:34Z")

</div>

While researching the feasibility of glibc-hwcaps, I came across this wiki article from openSUSE discussing this topic. I’d consider it required reading.

[https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels](https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels)

---

<div class="post-metadata">

### Author: ![nyanbinary](https://discourse.nixos.org/user_avatar/discourse.nixos.org/nyanbinary/32/11523_2.png) [@nyanbinary](https://discourse.nixos.org/u/nyanbinary)
#### Post date: [November 25, 2023, 9:19pm 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/22 "2023-11-25T21:19:39Z")

</div>

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.

---

<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: [November 25, 2023, 9:36pm 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/23 "2023-11-25T21:36:58Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![nyanbinary](https://discourse.nixos.org/user_avatar/discourse.nixos.org/nyanbinary/32/11523_2.png) [@nyanbinary](https://discourse.nixos.org/u/nyanbinary)
#### Post date: [November 25, 2023, 9:41pm 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/24 "2023-11-25T21:41:44Z")

</div>

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?

---

<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: [November 25, 2023, 9:49pm 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/25 "2023-11-25T21:49:43Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![Mapybara](https://discourse.nixos.org/letter_avatar_proxy/v4/letter/m/8dc957/32.png) [@Mapybara](https://discourse.nixos.org/u/Mapybara)
#### Post date: [November 26, 2023, 3:13am 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/26 "2023-11-26T03:13:52Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![anon52471967](https://discourse.nixos.org/letter_avatar_proxy/v4/letter/a/dc4da7/32.png) [@anon52471967](https://discourse.nixos.org/u/anon52471967)
#### Post date: [November 26, 2023, 7:37am 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/27 "2023-11-26T07:37:34Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![nixinator](https://discourse.nixos.org/user_avatar/discourse.nixos.org/nixinator/32/3859_2.png) [@nixinator](https://discourse.nixos.org/u/nixinator)
#### Post date: [November 26, 2023, 3: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/28 "2023-11-26T15:45:25Z")

</div>

> [@anon52471967](#):
>
> _necessarily_ produce more performant software

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?

---

<div class="post-metadata">

### Author: ![misuzu](https://discourse.nixos.org/letter_avatar_proxy/v4/letter/m/ba9def/32.png) [@misuzu](https://discourse.nixos.org/u/misuzu)
#### Post date: [November 26, 2023, 9:39pm 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/29 "2023-11-26T21:39:15Z")

</div>

> [@RaitoBezarius](#):
>
> I would argue the only real reason we don’t support ARMv7 is that because it’s hard to have it in CI

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](https://github.com/NixOS/aarch64-build-box/blob/2467f8c2ce3840ced308d1adfc06075ddcc6b85b/armv7l.nix) 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.

---

<div class="post-metadata">

### Author: ![gytis-ivaskevicius](https://discourse.nixos.org/user_avatar/discourse.nixos.org/gytis-ivaskevicius/32/3333_2.png) [@gytis-ivaskevicius](https://discourse.nixos.org/u/gytis-ivaskevicius)
#### Post date: [November 26, 2023, 10:25pm 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/30 "2023-11-26T22:25:32Z")

</div>

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

---

<div class="post-metadata">

### Author: ![pauldoo](https://discourse.nixos.org/user_avatar/discourse.nixos.org/pauldoo/32/5013_2.png) [@pauldoo](https://discourse.nixos.org/u/pauldoo)
#### Post date: [November 28, 2023, 8:52am 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/31 "2023-11-28T08:52:10Z")

</div>

> [@Atemu](#):
>
> While researching the feasibility of glibc-hwcaps, I came across this wiki article from openSUSE discussing this topic. I’d consider it required reading.

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.

---

<div class="post-metadata">

### Author: ![nyanbinary](https://discourse.nixos.org/user_avatar/discourse.nixos.org/nyanbinary/32/11523_2.png) [@nyanbinary](https://discourse.nixos.org/u/nyanbinary)
#### Post date: [November 28, 2023, 2:37pm 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/32 "2023-11-28T14:37:40Z")

</div>

Another somewhat unrelated performance optimization that could be done is using BOLT?

> **[Intel Appears On The Verge Of Some Exciting Performance Optimizations For...](https://www.phoronix.com/news/Intel-Clear-BOLT-Like-Optimize)**
>
> One thing that has never gotten old over the past nearly twenty years of covering Linux news on Phoronix are the relentless performance optimizations made to the Linux kernel, GCC and LLVM/Clang compilers, and other key open-source projects over the...

---

<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: [November 28, 2023, 3:39pm 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/33 "2023-11-28T15:39:29Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![nyanbinary](https://discourse.nixos.org/user_avatar/discourse.nixos.org/nyanbinary/32/11523_2.png) [@nyanbinary](https://discourse.nixos.org/u/nyanbinary)
#### Post date: [November 28, 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/34 "2023-11-28T17:45:29Z")

</div>

Where would someone propose this though without it getting buried?

---

<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: [November 28, 2023, 5:53pm 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/35 "2023-11-28T17:53:49Z")

</div>

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 😉

---

<div class="post-metadata">

### Author: ![wamserma](https://discourse.nixos.org/user_avatar/discourse.nixos.org/wamserma/32/5353_2.png) [@wamserma](https://discourse.nixos.org/u/wamserma)
#### Post date: [November 29, 2023, 9:58pm 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/36 "2023-11-29T21:58:20Z")

</div>

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](https://github.com/HenrikBengtsson/x86-64-level) to set the `max-microarch-level` in `hardware-configuration.nix`

---

<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: [November 30, 2023, 3:44pm 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/37 "2023-11-30T15:44:33Z")

</div>

> [@wamserma](#):
>
> 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).

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.

---

<div class="post-metadata">

### Author: ![riceicetea](https://discourse.nixos.org/user_avatar/discourse.nixos.org/riceicetea/32/7034_2.png) [@riceicetea](https://discourse.nixos.org/u/riceicetea)
#### Post date: [December 2, 2023, 9:12am 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/38 "2023-12-02T09:12:29Z")

</div>

> [@Flakebi](#):
>
> using -O3

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.

---

<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: [December 2, 2023, 1:50pm 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/39 "2023-12-02T13:50:33Z")

</div>

O3 includes potentially optimisations that produce potentially unsafe and/or wrong code. We won’t use that.

---

<div class="post-metadata">

### Author: ![wamserma](https://discourse.nixos.org/user_avatar/discourse.nixos.org/wamserma/32/5353_2.png) [@wamserma](https://discourse.nixos.org/u/wamserma)
#### Post date: [December 3, 2023, 7:07pm 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/40 "2023-12-03T19:07:15Z")

</div>

> [@Atemu](#):
>
> > [@wamserma](#):
> >
> > 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).
> 
> 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.

Hm… Do we have metrics on misses on [cache.nixos.org](http://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.

[Previous page](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.md?page=1)

[Next page](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.md?page=3)
