编译要在VM中运行的程序时，应将march和mtune设置为什么? [英] When compiling programs to run inside a VM, what should march and mtune be set to?
问题描述
随着VM从属于主机所提供的任何内容，应向gcc提供哪些编译器标志?
With VMs being slave to whatever the host machine is providing, what compiler flags should be provided to gcc?
我通常认为-march=native将是您编译专用框时要使用的，但是-march=native的详细信息如
I would normally think that -march=native would be what you would use when compiling for a dedicated box, but the fine detail that -march=native is going to as indicated in this article makes me extremely wary of using it.
那么...在虚拟机内部设置-march和-mtune的内容是什么?
So... what to set -march and -mtune to inside a VM?
举一个具体的例子...
For a specific example...
我现在的具体情况是在基于KVM的云"主机中的Linux来宾中编译python(及更多)，我对主机硬件没有真正的控制权(除了诸如CPU GHz m CPU之类的简单"东西之外)计数和可用的RAM).目前，cpuinfo告诉我我有一个"AMD Opteron(tm)处理器6176"，但老实说，我还不知道(是否)可靠，以及来宾是否可以转移到我身上的不同体系结构上以满足主机的基础结构改组需求(听起来很毛/不太可能).
My specific case right now is compiling python (and more) in a linux guest inside a KVM-based "cloud" host that I have no real control over the host hardware (aside from 'simple' stuff like CPU GHz m CPU count, and available RAM). Currently, cpuinfo tells me I've got an "AMD Opteron(tm) Processor 6176" but I honestly don't know (yet) if that is reliable and whether the guest can get moved around to different architectures on me to meet the host's infrastructure shuffling needs (sounds hairy/unlikely).
我真正能保证的就是我的操作系统，它是64位linux内核，其中uname -m产生x86_64.
All I can really guarantee is my OS, which is a 64-bit linux kernel where uname -m yields x86_64.
推荐答案
Some incomplete and out of order excerpts from section 3.17.14 Intel 386 and AMD x86-64 Options of the GCC 4.6.3 Standard C++ Library Manual (which I hope are pertinent).
-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您可能太接近调整过度杀伤力了.
What I found most interesting is that specifying -march=cpu-type implies -mtune=cpu-type. My take on the rest was that if you are specifying both -march & -mtune you're probably getting too close to tweak overkill.
我的建议是只使用-m64，并且由于在x86-64 Linux操作系统中运行，您应该足够安全，对吗?
My suggestion would be to just use -m64 and you should be safe enough since you're running inside a x86-64 Linux, correct?
但是，如果您不需要在其他环境中运行，并且感到幸运和容错能力，那么 -march=native可能也很适合您.
But if you don't need to run in another environment and you're feeling lucky and fault tolerant then -march=native might also work just fine for you.
-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在运行Windows 7的台式机上使用Intel Pentium双核E6500 CPU.
For what it's worth ...
Out of curiosity I tried using the technique described in the article you referenced. I tested gcc v4.6.3 in 64-bit Ubuntu 12.04 which was running as a VMware Player guest. The VMware VM was running in Windows 7 on a desktop using an Intel Pentium Dual-Core E6500 CPU.
gcc选项-m64被替换为-march=x86-64 -mtune=generic.
The gcc option -m64 was replaced with just -march=x86-64 -mtune=generic.
但是，使用-march=native进行编译会导致gcc使用以下所有更具体的编译器选项.
However, compiling with -march=native resulted in gcc using all of the much more specific compiler options below.
-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进行编译.
So, yes, as the gcc documentation states when "Using -march=native ... the result might not run on different machines". To play it safe you should probably only use -m64 or it's apparent equivalent -march=x86-64 -mtune=generic for your compiles.
我看不到您对此会有什么问题，因为这些编译器选项的目的是gcc会生成能够在任何 x86-64/amd64兼容CPU上正常运行的代码. (不?)
I can't see how you would have any problem with this since the intent of those compiler options are that gcc will produce code capable of running correctly on any x86-64/amd64 compliant CPU. (No?)
我很惊讶地发现gcc -march=native CPU选项到底有多具体.我不知道如何使用CPU的L1高速缓存大小为32k来微调生成的代码.但是显然如果有办法做到这一点，那么使用-march=native将允许gcc 做到.
I am frankly astounded at how specific the gcc -march=native CPU options turned out to be. I have no idea how a CPU's L1 cache size being 32k could be used to fine tune the generated code. But apparently if there is a way to do this, then using -march=native will allow gcc to do it.
我想知道这是否会带来明显的性能改进吗?
I wonder if this might result in any noticeable performance improvements?
这篇关于编译要在VM中运行的程序时，应将march和mtune设置为什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
