在docker映像中编译时进行调整 [英] mtune and march when compiling in a docker image

问题描述

在Docker映像中（即在dockerfile中）进行编译时，三月和 mtune 应该是什么

When compiling in a docker image (i.e. in the dockerfile), what should march and mtune be set to?

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

Note this is not about compiling in a running container, but compiling when the container is being built (e.g. building tools from source when the image is run).

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

For example, currently when I run docker build and install R packages from source I get loads of (could be g++/gcc/f95 ...):

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

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

If I use native in an image built by Dockerhub, I guess this will use the spec of the machine used by Dockerhub, and this will impact the image binary available for download?

这与类似的问题

This is related to this similar question about VMs but containers aren't VMs.

推荐答案

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

If I use native in an image built by Dockerhub, I guess this will use the spec of the machine used by Dockerhub, and this will impact the image binary available for download?

是的。构建docker映像时，它是在主机上并使用其资源完成的，因此 -march = native 和 -mtune = native 将采用主机的规格。

That's true. When the docker image is built, it is done on the host machine and using its resources, so -march=native and -mtune=native will take the specs of the host machine.

用于构建可供广大读者使用的docker映像，并使它们在许多设备上都能正常工作（ X86）的目标，最好使用通用的指令集。如果您需要指定三月和 mtune ，则可能是最安全的选择：

For building docker images that may be used by a wide audience, and making them work as on many (X86) targets as possible, it's best to use a common instruction set. If you need to specify march and mtune, these would probably be the safest choice:

-march = x86-64 -mtune = generic

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

There may be some performance hits compared to -march=native -mtune=native in certain cases, but fortunately, on most applications, this change could go almost unnoticed (specific applications may be more affected, especially if they depend on a small piece of kernel functions that GCC is able to optimize well, for example by utilizing the CPU vector instruction sets).

请参考Phoronix进行的详细基准测试比较：

使用Clear Linux在GCC编译器上进行了各种优化级别的测试

For reference, check this detailed benchmark comparison by Phoronix:
GCC Compiler Tests At A Variety Of Optimization Levels Using Clear Linux

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

It compares about a dozen benchmarks with GCC 6.3 using different optimization flags. Benchmarks run on an Intel Core-I7 6800K machine, which supports modern Intel instruction sets including SSE, AVX, BMI, etc. (see here for the complete list). Specifically, -O3 vs. -O3 -march=native is the interesting metric. You could see that in most benchmarks, the advantage of -O3 -march=native over -O3 is minor to negligible (and in one case, -O3 wins...).

最后， -march = x86-64 -mtune = generic 是Docker映像的不错选择，应该提供良好的可移植性，并且通常会对性能造成较小的影响。

To conclude, -march=x86-64 -mtune=generic is a decent choice for Docker images and should provide good portability and a typically minor performance hit.

这篇关于在docker映像中编译时进行调整的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！