C/C++ compilers are non deterministic due to support of super macros that change run to run, non-deterministic optimisation strategies or ordering due to parallelism, and linkers often produce different outputs every time they are run where subtle bugs can cause crashes when addresses don’t line up how you expect. And that’s without mentioning projects that use a configuration step.
Can’t most serious compilers produce reproducible builds these days given the same build environment. I know there has been a drive towards reproducible builds in general for security verification purposes.
Yeah, but it does take a lot of work to coerce them to do it.
GCC is honestly obnoxious, and you have to do a bunch of unintuitive things to get it. The compile stage needs the built-in RNG seeded, parent file paths stripped, you need to ensure that the date/time macros are not used anywhere, and you need to ensure that all command line flags are passed in the exact same order every time.
I just went through this with GCC16 on a new project.
Not only can they but certified toolchains exist in the safety critical space. Medical, aerospace, nuclear projects, and the like are often required to use and procure such toolchains as part of their validation.
Not by default usually but yes, you need to do a lot of work to set all necessary configurations and sometimes provide your own RNG seed for things which insist on random looking values.
I’m not very good with C/C++ so please correct me, isn’t that what’s called a “race condition”? Parallelism can cause non-determinism but not in the same sense LLMs generate non-deterministic output. Compilers are not statistical machines.
You don’t need parallelism to have a race condition, just not handling an event with expected timing can cause one - like when two keys are pressed within one polling cycle and you depend on one being pressed before the other for some logic like up and right arrow for a diagonal but they register as right and up so the diagonal movement doesn’t trigger
Compiler optimisation strategies sometimes use statistical machines and link time optimisation does use random number generators for producing output
You can have single threaded race conditions appear simply from inputs appearing in an unintended ordering. Or on a single core CPU, you can have one task meant to be done first take unusually long time, so the CPU gives time to another thread which finishes first but expected to finish last.
From my understanding, which is very limited, race conditions are more an issue with concurrent programming. Parallel computing uses separate processor cores for each task so there’s less reliance on stack machines. But I guess each core still shares the memory, so maybe it still happens. Like I said, my understanding is limited. Just use rust.
C/C++ compilers are non deterministic due to support of super macros that change run to run, non-deterministic optimisation strategies or ordering due to parallelism, and linkers often produce different outputs every time they are run where subtle bugs can cause crashes when addresses don’t line up how you expect. And that’s without mentioning projects that use a configuration step.
Can’t most serious compilers produce reproducible builds these days given the same build environment. I know there has been a drive towards reproducible builds in general for security verification purposes.
Yeah, but it does take a lot of work to coerce them to do it.
GCC is honestly obnoxious, and you have to do a bunch of unintuitive things to get it. The compile stage needs the built-in RNG seeded, parent file paths stripped, you need to ensure that the date/time macros are not used anywhere, and you need to ensure that all command line flags are passed in the exact same order every time.
I just went through this with GCC16 on a new project.
Not only can they but certified toolchains exist in the safety critical space. Medical, aerospace, nuclear projects, and the like are often required to use and procure such toolchains as part of their validation.
Not by default usually but yes, you need to do a lot of work to set all necessary configurations and sometimes provide your own RNG seed for things which insist on random looking values.
I’m not very good with C/C++ so please correct me, isn’t that what’s called a “race condition”? Parallelism can cause non-determinism but not in the same sense LLMs generate non-deterministic output. Compilers are not statistical machines.
You don’t need parallelism to have a race condition, just not handling an event with expected timing can cause one - like when two keys are pressed within one polling cycle and you depend on one being pressed before the other for some logic like up and right arrow for a diagonal but they register as right and up so the diagonal movement doesn’t trigger
Compiler optimisation strategies sometimes use statistical machines and link time optimisation does use random number generators for producing output
You can have single threaded race conditions appear simply from inputs appearing in an unintended ordering. Or on a single core CPU, you can have one task meant to be done first take unusually long time, so the CPU gives time to another thread which finishes first but expected to finish last.
From my understanding, which is very limited, race conditions are more an issue with concurrent programming. Parallel computing uses separate processor cores for each task so there’s less reliance on stack machines. But I guess each core still shares the memory, so maybe it still happens. Like I said, my understanding is limited. Just use rust.