linux 当编译程序以在VM中运行时，march和mtune应该设置为什么？

umuewwlo 于 2023-02-21 发布在 Linux

关注(0)|答案(2)|浏览(127)

由于VM从属于主机所提供的任何内容，应该向gcc提供什么编译器标志？
我通常会认为-march=native将是您在为专用框编译时使用的，但是-march=native将要使用的this article中所示的精细细节使我非常谨慎地使用它。
那么...在虚拟机内将-march和-mtune设置为什么？
举个具体的例子...
我现在的具体情况是编译python（以及更多）在基于KVM的“云”主机内的Linux访客中，我无法真实的控制主机硬件（除了“简单”的东西，如CPU GHz m CPU计数和可用RAM）。目前，cpuinfo告诉我，我有一台“AMD皓龙（tm）处理器6176”，但老实说我不知道（还没有）这是否可靠，客户机是否可以在我身上移动到不同的体系结构，以满足主机的基础设施 Shuffle 需求（听起来很棘手/不太可能）。
我所能真正保证的是我的操作系统，它是一个64位的linux内核，uname -m产生x86_64。

linux

来源：https://stackoverflow.com/questions/10132904/when-compiling-programs-to-run-inside-a-vm-what-should-march-and-mtune-be-set-t

2条答案

按热度按时间

z31licg01#

GCC 4.6.3 Standard C++ Library Manual的第3.17.14节英特尔386和AMD x86-64选项中的一些不完整和无序的摘录（我希望是相关的）。

-march=cpu-type
  Generate instructions for the machine type cpu-type.  
  The choices for cpu-type are the same as for -mtune.  
  Moreover, specifying -march=cpu-type implies -mtune=cpu-type. 

-mtune=cpu-type
  Tune to cpu-type everything applicable about the generated code,  
  except for the ABI and the set of available instructions.  
  The choices for cpu-type are:
    generic
      Produce code optimized for the most common IA32/AMD64/EM64T processors. 
    native
      This selects the CPU to tune for at compilation time by determining
      the processor type of the compiling machine. 
      Using -mtune=native will produce code optimized for the local machine
      under the constraints of the selected instruction set.
      Using -march=native will enable all instruction subsets supported by
      the local machine (hence the result might not run on different machines).

我发现最有趣的是specifying -march=cpu-type implies -mtune=cpu-type，我对其余部分的看法是，如果你指定both-march & -mtune，你可能太接近于做过度的调整了。
我的建议是只使用-m64，因为您是在x86-64 Linux中运行的，所以应该足够安全，对吗？
但是如果你不需要运行在另一个环境中，并且你觉得幸运和容错，那么-march=native可能也适合你。

-m32
  The 32-bit environment sets int, long and pointer to 32 bits  
  and generates code that runs on any i386 system.     
-m64
  The 64-bit environment sets int to 32 bits and long and pointer  
  to 64 bits and generates code for AMD's x86-64 architecture.

为了它的价值...

出于好奇，我尝试使用了你提到的文章中描述的技术。我在64位Ubuntu 12.04中测试了gcc v4.6.3，Ubuntu 12.04作为VMware Player客户机运行。VMware VM在Windows 7中运行，台式机使用Intel Pentium双核E6500 CPU。
gcc选项-m64被替换为-march=x86-64 -mtune=generic。
但是，使用-march=native编译会导致gcc使用下面所有更具体的编译器选项。

-march=core2 -mtune=core2 -mcx16 
-mno-abm -mno-aes -mno-avx -mno-bmi -mno-fma -mno-fma4 -mno-lwp 
-mno-movbe -mno-pclmul -mno-popcnt -mno-sse4.1 -mno-sse4.2 
-mno-tbm -mno-xop -msahf --param l1-cache-line-size=64 
--param l1-cache-size=32 --param l2-cache-size=2048

所以，是的，正如gcc文档所述，当“* 使用-march=native...结果可能不会在不同的机器上运行 *"时，为了安全起见，您可能只应该使用-m64或明显等效的-march=x86-64 -mtune=generic进行编译。
我看不出您对此会有什么问题，因为这些编译器选项的目的是gcc将生成能够在任何x86-64/amd 64兼容的CPU上正确运行的代码。
坦率地说，我对gcc -march=native CPU选项的具体性感到惊讶。我不知道如何使用CPU的L1缓存大小32 k来微调生成的代码。但显然 * 如果 * 有一种方法可以做到这一点，那么使用-march=native将允许gcc**做到这一点。
我想知道这是否会导致任何明显的性能改进？