Question

如果VM是主机提供的内容，那么应该向gcc提供哪些编译器标志？

我通常会认为-march=native将是您在编写专用框时所使用的内容，但-march=native中-march所指出的精细细节让我非常感兴趣警惕使用它。

那么......在VM中设置-mtune和cpuinfo的内容是什么？

具体例子......

我现在的具体情况是在基于KVM的“云”主机内的linux客户机中编译python（以及更多），我无法真正控制主机硬件（除了像CPU GHz m CPU这样的'简单'之类的东西计数和可用的RAM）。目前，uname -m告诉我，我有一台“AMD Opteron（tm）处理器6176”，但老实说我还不知道是否可靠，以及客人是否可以转移到我的不同架构上满足主机的基础设施改组需求（听起来很毛茸/不太可能）。

我真正能保证的是我的操作系统，这是一个64位的Linux内核，其中x86_64产生{{1}}。

Answer 1

3.17.14 Intel 386 and AMD x86-64 Options GCC 4.6.3 Standard C++ Library Manual部分的一些不完整和乱序的摘录（我希望这些摘要是相关的）。

-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。我对其余部分的看法是，如果您指定两者 -march＆amp; -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.

为了它的价值......

出于好奇，我尝试使用您引用的文章中描述的技术。我在作为VMware Player客户端运行的64位Ubuntu 12.04中测试了gcc v4.6.3。 VMware VM使用Intel Pentium双核E6500 CPU在桌面上的Windows 7中运行。

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 / amd64兼容CPU上正确运行的代码。（NO 3）

我坦率地对gcc -march=native CPU选项的特定程度感到震惊。我不知道如何使用CPU的L1缓存大小32k来微调生成的代码。但显然如果有办法实现这一点，那么使用-march=native将允许gcc 执行此操作。

我想知道这是否会导致任何明显的性能提升？

Answer 2

有人认为客户操作系统报告的CPU架构是您应该优化的。否则，我称之为bug。有时候错误可能有正当理由，但是......

请注意，并非所有虚拟机管理程序都必须相同。

查看特定管理程序的邮件列表可能是个好主意。

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

2 个答案:

为了它的价值......