在 docker 镜像中编译时的 mtune 和 march [英] mtune and march when compiling in a docker image

问题描述

在 docker 镜像中编译时(即在 dockerfile 中)，march 和 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.

推荐答案

如果我在 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?

确实如此.构建 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) 目标上工作，最好使用通用指令集.如果您需要指定 march 和 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 的详细基准比较:
GCC 编译器测试各种优化级别使用 Clear Linux

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 镜像中编译时的 mtune 和 march的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！