| ▲ | fragmede 3 hours ago | |
> The big difference is that compilation is deterministic: compile the same program twice and it'll generate the same output twice. That's barely true now. Nix comes close, but builds are only bit-for-bit identical if you set a bunch of extra flags that aren't set by default. The most obvious instability is CPU dispatch order (aka modern single computer systems are themselves distributed, racy systems) changes the generated code ever so slightly. We don't actually care, because if one compiled version of the code uses r8 for a variable but a different compilation uses r9 for that variable, it doesn't matter because we just assume the resulting binary works the same either way. R8 vs r9 are implementation details that don't matter to humans. See where I'm going with this? If the LLM non-deterministically calls the variable fileName one day, and file_name the next time it's given the same prompt, yeah language syntax purists are going to suffer an aneurysm because one of those is clearly "wrong" for the language in use, but it's really more of an implementation detail at this point. Obviously you can't mix them, the generated code has to be consistent in which one it's using, but if compilers get to chose r8 one day and r9 the next, and we're fine with it, why is having the exact variable name that important, as long as it's being used correctly? | ||
| ▲ | tjr 3 hours ago | parent | next [-] | |
I’ve done builds for aerospace products where the only binary difference between two builds of the same source code is the embedded timestamp. And per FAA review guidelines, this deterministic attribute is required, or else something is wrong in the source code or build process. I certainly don’t use all compilers everywhere, but I don’t think determinism in compilation is especially rare. | ||
| ▲ | m4rtink an hour ago | parent | prev [-] | |
If your builds are not deterministic for the same set of inputs, you are doing something wrong - or victim of supply chain attack. | ||