It's a bit like asking what percentage of Nix-packaged programs have Hungarian translation -- if Nix packages some more stuff the rate might decrease, but it's not Nix's task to add that to the programs that lack it.
Nix does everything in its power to provide a sandboxed environment in which builds can happen. Given the way hardware works, there are still sources of non-determinism that are impossible to prevent, most importantly timing.
Most programs depend on it, even compilers, and extra care should be taken by them to change that. The only way to prevent it would be to go full-on CPU and OS emulation, but that would be prohibitively expensive.
A compiler invoked twice on the same source file is not mandated to produce the same binary, but it should produce a binary with the same functionality.
There are infinite number of binaries that do the same thing (e.g. just padding random zeros in certain places wouldn't cause a functional problem).
Nix is very good at doing functionally reproducible builds, that's its whole thing. But there are build steps which are simply not deterministic, and they might produce correct, but not always the same outputs.
OS scheduling is non-deterministic, and there are quite a few things that are sensitive to the order of operations (simplest example: floating point addition). Is you want to guarantee determinism, not just provide it on a best effort basis for things that are willing to cooperate, the only way do that is to put everything into a fully deterministic emulator, which is terribly slow.
is SCHED_FIFO or SCHED_RR or the newer incarnations viable? Is it possible to make QEMU deterministic? a quick glance at the realtime schedulers state source code needs to take that into consideration.
I know it seems like i don't know what i am talking about, often, on here. The reason is i don't live on HN so i type a comment and rarely remember the words i want to use before the edit/delete window closes.
The idea that i can't control when things occur during a compilation seems suspect. Is there a certain "code size" or other bellwether where this non-determinism starts to crop up? I ask because i get the feeling if i start compiling trivial stuff it will all be bit-perfect and if i say so i'll get lambasted for "well obviously trivial stuff can be reproducible," so i am heading that off at the pass, first.
It's a bit like asking what percentage of Nix-packaged programs have Hungarian translation -- if Nix packages some more stuff the rate might decrease, but it's not Nix's task to add that to the programs that lack it.
Nix does everything in its power to provide a sandboxed environment in which builds can happen. Given the way hardware works, there are still sources of non-determinism that are impossible to prevent, most importantly timing. Most programs depend on it, even compilers, and extra care should be taken by them to change that. The only way to prevent it would be to go full-on CPU and OS emulation, but that would be prohibitively expensive.