4

由于虚拟机是主机提供的任何东西的从属，应该向 gcc 提供哪些编译器标志？

我通常认为这将是您在为专用框进行编译时会使用的内容，但是本文中指出的-march=native细节让我对使用它非常谨慎。-march=native

那么......在VM内部设置-march和设置什么？-mtune

举一个具体的例子...

我现在的具体情况是在基于 KVM 的“云”主机内的 linux 客户机中编译 python（以及更多），我无法真正控制主机硬件（除了“简单”的东西，如 CPU GHz m CPU 计数，以及可用内存）。目前，cpuinfo告诉我我有一个“AMD Opteron(tm) 处理器 6176”，但老实说，我还不知道这是否可靠，以及来宾是否可以转移到我身上的不同架构以满足主机的基础架构洗牌需求（听起来毛茸茸/不太可能）。

我能真正保证的是我的操作系统，它是一个 64 位 linux 内核，其中uname -myield x86_64.

4

2 回答 2

4

GCC 4.6.3 标准 C++ 库手册的第3.17.14 节 Intel 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。我对其余部分的看法是，如果您同时指定两者 -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.

物有所值 ...

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

gcc 选项-m64被替换为 just -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 上正确运行的代码。（不？）

坦率地说，我对 gcc -march=nativeCPU 选项的具体程度感到震惊。我不知道如何使用 CPU 的 L1 缓存大小为 32k 来微调生成的代码。但显然，如果有办法做到这一点，那么 using-march=native将允许 gcc做到这一点。

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

于 2012-04-13T01:38:19.563 回答
1

有人会认为客户操作系统报告的 CPU 架构是您应该优化的。否则，我会称之为错误。有时可能有适当的原因导致错误，但是......

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

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

于 2012-04-12T23:25:16.157 回答