在 docker 镜像中编译时（即在 dockerfile 中），march 和 mtune 应该设置为什么？
请注意，这不是在正在运行的容器中编译，而是在构建容器时进行编译（例如，在运行映像时从源代码构建工具）。
例如，目前当我运行 docker build 并从源代码安装 R 包时，我得到了很多（可能是 g++/gcc/f95 ...）：
g++ -std=gnu++14 [...] -O3 -march=native -mtune=native -fPIC [...]
如果我在 Dockerhub 构建的镜像中使用 native，我猜这将使用 Dockerhub 使用的机器的规格，这会影响可供下载的镜像二进制文件吗？
这与this similar question about VMs 有关，但容器不是虚拟机。
【问题讨论】：
标签： docker gcc g++ containers compiler-optimization
如果我在 Dockerhub 构建的镜像中使用
native，我猜这将使用 Dockerhub 使用的机器的规格，这会影响可供下载的镜像二进制文件吗？
确实如此。构建 docker 映像时，它是在主机上完成并使用其资源的，因此-march=native 和 -mtune=native 将采用主机的规格。
要构建可供广大受众使用的 docker 映像，并使它们在尽可能多的 (X86) 目标上工作，最好使用通用指令集。如果您需要指定march 和mtune，这些可能是最安全的选择：
-march=x86-64 -mtune=generic
在某些情况下，与-march=native -mtune=native 相比，可能会有一些性能下降，但幸运的是，在大多数应用程序上，这种变化几乎不会被注意到（特定应用程序可能会受到更大的影响，特别是如果它们依赖于一小部分内核函数GCC 能够很好地优化，例如通过利用 CPU 向量指令集）。
作为参考，请查看 Phoronix 的详细基准比较：
GCC Compiler Tests At A Variety Of Optimization Levels Using Clear Linux
它使用不同的优化标志将十几个基准与 GCC 6.3 进行比较。基准测试在 Intel Core-I7 6800K 机器上运行，该机器支持现代 Intel 指令集，包括 SSE、AVX、BMI 等（完整列表请参阅here）。具体来说，-O3 与 -O3 -march=native 是一个有趣的指标。
您可以看到，在大多数基准测试中，-O3 -march=native 相对于-O3 的优势微不足道，甚至可以忽略不计（在一种情况下，-O3 胜出...）。
总之，-march=x86-64 -mtune=generic 是 Docker 镜像的不错选择，应该提供良好的可移植性和通常较小的性能损失。
【讨论】：