Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build results vary from build machine CPU #1939

Closed
bmwiedemann opened this issue Jul 30, 2020 · 8 comments · Fixed by #1953
Closed

build results vary from build machine CPU #1939

bmwiedemann opened this issue Jul 30, 2020 · 8 comments · Fixed by #1953
Labels
type:Bug Inconsistencies or issues which will cause an incorrect result under some or all circumstances

Comments

@bmwiedemann
Copy link
Contributor

Description

While working on reproducible builds for openSUSE, I found that
our insighttoolkit package varied from the type of build machine CPU
that randomly gets chosen from the pool of build workers.

This is because InsightToolkit-5.1.0/CMake/ITKSetStandardCompilerFlags.cmake has -mtune=native
and dropping this helped to make builds reproducible.

See https://reproducible-builds.org/ for why this matters.

Steps to Reproduce

  1. build ITK on 2 hosts with different CPU types
  2. compare binaries

Expected behavior

It should be possible to get bit-identical build results on different build machines.
May be triggered via a cmake flag or the SOURCE_DATE_EPOCH environment variable

Actual behavior

build results vary from build machine CPU

Reproducibility

100%

Versions

5.1

Environment

openSUSE-Tumbleweed-20200728

Additional Information

This PR was done while working on reproducible builds for openSUSE.

@bmwiedemann bmwiedemann added the type:Bug Inconsistencies or issues which will cause an incorrect result under some or all circumstances label Jul 30, 2020
@thewtex
Copy link
Member

thewtex commented Aug 6, 2020

@bmwiedemann thanks for working on the openSUSE packages! 📦 🙏

Perhaps a different -mtune value should be specified in the package build configuration to select the target cpu?

@gdevenyi
Copy link
Contributor

gdevenyi commented Aug 6, 2020

I believe -mtune=generic is the recommended way to produce "code optimized for the most common CPUs at the time the version of gcc was released"

@gdevenyi
Copy link
Contributor

gdevenyi commented Aug 6, 2020

‘generic’
Produce code optimized for the most common IA32/AMD64/EM64T processors. If you know the CPU on which your code will run, then you should use the corresponding -mtune or -march option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option.

As new processors are deployed in the marketplace, the behavior of this option will change. Therefore, if you upgrade to a newer version of GCC, code generation controlled by this option will change to reflect the processors that are most common at the time that version of GCC is released.

There is no -march=generic option because -march indicates the instruction set the compiler can use, and there is no generic instruction set applicable to all processors. In contrast, -mtune indicates the processor (or, in this case, collection of processors) for which the code is optimized.

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

@bmwiedemann
Copy link
Contributor Author

Yes, -mtune=generic sounds good. I tested that it also builds reproducibly.

@dzenanz
Copy link
Member

dzenanz commented Aug 10, 2020

Close the issue?

bmwiedemann added a commit to bmwiedemann/ITK that referenced this issue Aug 10, 2020
to avoid build-time CPU detection of -mtune=native
to get reproducible build results.

See https://reproducible-builds.org/ for why this is good.

Fixes InsightSoftwareConsortium#1939

This PR was done while working on reproducible builds for openSUSE.
@bmwiedemann
Copy link
Contributor Author

@dzenanz I'd prefer to see #1953 merged

bmwiedemann added a commit to bmwiedemann/ITK that referenced this issue Aug 10, 2020
to avoid build-time CPU detection of -mtune=native
to get reproducible build results.

See https://reproducible-builds.org/ for why this is good.

Fixes InsightSoftwareConsortium#1939

This PR was done while working on reproducible builds for openSUSE.
@hjmjohnson
Copy link
Member

-mtune=generic is the least common denominator, which means only use instructions from 20 years ago.

@blowekamp
Copy link
Member

blowekamp commented Aug 20, 2020

-mtune=generic is the least common denominator, which means only use instructions from 20 years ago.

It is my understanding that this is for the optimization of the instructions ( order, delay etc. ), not which instruction sets used. The march flag ( and others ) dictate which instruction can be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:Bug Inconsistencies or issues which will cause an incorrect result under some or all circumstances
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants