在docker映像中编译时进行调整

Question

当在泊坞窗图像（即dockerfile）编制，应该怎样march和mtune被设置为？

请注意，这不是在正在运行的容器中进行编译，而是在构建容器时进行编译（例如，在运行映像时从源代码构建工具）。

例如，当前，当我docker build从源代码运行并安装R软件包时，得到的负载（可能是g++/gcc/f95...）：

g++ -std=gnu++14 [...] -O3 -march=native -mtune=native -fPIC [...]

如果我使用nativeDockerhub构建的映像，我想这将使用Dockerhub使用的机器的规格，这会影响可下载的映像二进制文件吗？

这与有关VM的类似问题有关，但是容器不是VM。

Answer 1

如果我native在 Dockerhub 构建的镜像中使用，我猜这将使用 Dockerhub 使用的机器的规范，这会影响可供下载的镜像二进制文件？

确实如此。当搬运工图像而建，它是在主机上完成，并利用其资源，所以-march=native和-mtune=native将采取主机的规格。

为了构建可供广大用户使用的 docker 镜像，并使它们在尽可能多的 (X86) 目标上工作，最好使用通用指令集。如果您需要指定marchand mtune，这些可能是最安全的选择：

-march=x86-64 -mtune=generic

与-march=native -mtune=native某些情况相比，可能会有一些性能下降，但幸运的是，在大多数应用程序中，这种变化几乎不会被注意到（特定应用程序可能会受到更大的影响，特别是如果它们依赖于 GCC 能够优化的一小部分内核函数）好吧，例如通过利用 CPU 向量指令集）。

作为参考，请查看 Phoronix 的详细基准比较：
使用 Clear Linux 进行各种优化级别的 GCC 编译器测试

它使用不同的优化标志将大约十几个基准与 GCC 6.3 进行比较。基准测试在 Intel Core-I7 6800K 机器上运行，该机器支持现代 Intel 指令集，包括 SSE、AVX、BMI 等（完整列表请参见此处）。具体来说，-O3vs.-O3 -march=native是一个有趣的指标。您可以看到，在大多数基准测试中，-O3 -march=nativeover的优势-O3很小甚至可以忽略不计（在一种情况下，-O3获胜......）。

总而言之，-march=x86-64 -mtune=generic对于 Docker 镜像来说，这是一个不错的选择，应该提供良好的可移植性和通常较小的性能损失。