Transparently Supporting PGO/FDO/PLO Optimized Builds

[SergeK]

Hi! Very excited to learn about this project and about your persistent progress! Managing optimized builds within the “derivation model” is, intuitively, hard. At Nixpkgs we currently dismiss the challenge due to dubious expected benefits (e.g. Pre-RFC: Gradual Transition of NixOS x86_64 Baseline to x86-64-v3 with an Intermediate Step to x86-64-v2 - #59 by Atemu) and due to complexity required to implement optimized builds without compromising “purity” (basic repeatability and being able to identify different builds, e.g. distinguish between builds with different profiles). One trivial solution is to “rebuild the world”: override stdenv globally, injecting profile data as pure inputs, passing the appropriate compiler and linker flags, and setting requiredSystemFeatures to distinguish between derivations destined for sufficiently different hardwares. This is an expensive solution, which is what, if I understand, leads to your following points:

@psionik

The high level problem is that profiling requires two unique derivations to be used.

• Quick check: do you mean two instantiations of the same expression, with a lag and different profile data inputs?

@psionik

believe the correct high-level model for NixOS is binary substitution. The derivation the users specifies does not change. The binary used to satisfy that specification changes.

• Question: do you mean the “nixlang expression does not change”, or the “.drv does not change”? In the latter case, do you suggest “impurely” overwriting (overlaying) the untampered derivation’s outPaths?

@psionik

How does substitution occur?

@psionik

2-4 different binaries and the files linked into place are dynamic. Only more preparation to implement will reveal if mutating a profile (re-linking new files into place) or generating a new profile (perhaps with the user in the loop) is the cleaner route.

Optimized builds could well be a downstream application of the entire range of “late (delayed) binding” problems and efforts:

• Grafting:
  • Timely delivery of security updates — 2016 — Blog — GNU Guix
  • Feature request: Replace package without rebuilding world · Issue #132749 · NixOS/nixpkgs · GitHub
• Python packages without propagatedBuildInputs: Builders - Pyproject.nix
• Separate-derivation and delayed checkPhases: Why does the NixOS infrastructure have to be hosted in a centralized way? - #41 by amjoseph