Hacker News Reader

Comment by ethegwo | Hacker News Reader

As I know, LLVM optimizer (maybe also GCC) is not idempotent, does it mean we need to pay performance for idempotent buildings?

View on HN

Shouldn't same system+same version+same flags produce the same result?

The algorithms used might not produce a deterministic result (like order is different), and maybe it also depends on timings of the CPU with threads scheduled on different cores, or faster/slower cores, etc.

Deterministic builds aren't always that straightforward

All C and C++ compilers in common use are single-threaded, and parallelism is achieved by compiling multiple files at once. An optimizer pass producing nondeterministic results due to a bug is not impossible, but would be a bug to fix. Multithreaded linkers which are expected to have nondeterministic results do exist, and you have to not use that for reproduce able builds.

There's a long tail of tricky problems to solve for reproducible builds, but a specific build of a compiler producing different executable code from run to run hasn't really been one of them.

Now I'm wondering how differently my multithreaded tcc fork produces code. I don't think it should but it always wouldn't surprise me if there was some shared state remaining.

Forcing the ordering to be deterministic is a well-established part of the process

https://reproducible-builds.org/docs/stable-inputs/

https://reproducible-builds.org/docs/stable-outputs/

I'm using nix and clang/llvm - never have I ever got a different binary.

If what you're saying is true - stage 3 bootstrap wouldn't be possible.

bit obvious, but all it takes something that takes something that changes everytime to make it non-reproducible - like __DATE__ and __TIME__

Nix solves this by forcing __DATE__ and __TIME__ to be a single immutable value in the sandbox for all builds. If you look in the store the file timestamps will be this value.

Google takes great care to ensure that the LLVM optimizer produces bit-identical results for identical inputs across plenty of machines. If the llvm optimizer produced non-bit-identical results for identical inputs (all sources and command-line flags), Google would consider that a high priority bug.

So I'm reasonably sure it does produce bit-identical results.

Compilation performance or end executable performance?

The latter I mean, conservative optimization level is benefit to keep idempotency

Reply on news.ycombinator.com