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

概述如果VM是主机提供的任何东西,那么应该向 gcc提供哪些编译器标志？ 我通常认为-march = native将是你在编译专用盒时所使用的,但是-march = native的精细细节将如this article所示,这让我非常谨慎使用它. 那么……在VM中设置-march和-mtune的内容是什么？ 举个具体的例子…… 我现在的具体情况是在一个基于KVM的“云”主机内的linux客户机中编译py 如果VM是主机提供的任何东西,那么应该向 gcc提供哪些编译器标志？

我通常认为-march = native将是你在编译专用盒时所使用的,但是-march = native的精细细节将如this article所示,这让我非常谨慎使用它.

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

举个具体的例子……

我现在的具体情况是在一个基于KVM的“云”主机内的linux客户机中编译python(以及更多),我无法真正控制主机硬件(除了’简单’之类的东西,如cpu GHz m cpu数量,以及可用内存).目前,cpuinfo告诉我,我有一台“AMD Opteron(tm)处理器6176”,但老实说我还不知道(如果这是可靠的)以及客人是否可以转移到我的不同架构上以满足主机的要求基础设施改组需求(听起来很毛茸/不太可能).

所有我能真正保证的是我的 *** 作系统,这是一个64位的linux内核,其中uname -m产生x86_64.

解决方法 一些不完整的和无序的摘录自 GCC 4.6.3 Standard C++ Library Manual的 3.17.14 Intel 386 and AMD x86-64 Options部分(我希望是相关的).

-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).

我发现最有趣的是指定-march = cpu-type意味着-mtune = cpu-type.我对其余部分的看法是,如果你同时指定-march&你可能太过接近调整矫枉过正了.

我的建议是只使用-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上正确运行的代码. (没有？)

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

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

总结

以上是内存溢出为你收集整理的linux – 当编译程序在VM中运行时,应该将march和mtune设置为什么？全部内容，希望文章能够帮你解决linux – 当编译程序在VM中运行时,应该将march和mtune设置为什么？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。