4

VMがホストマシンが提供するものすべてのスレーブである場合、どのコンパイラフラグをgccに提供する必要がありますか？

通常は専用ボックスをコンパイルするときに使用すると思いますが、この記事に示されているように-march=native細部が細かく設定されているため、使用するのは非常に慎重です。-march=native

では...何を設定-marchし-mtuneてVM内に配置するのですか？

具体的な例として...

私の現在の特定のケースは、KVMベースの「クラウド」ホスト内のLinuxゲストでPython（およびそれ以上）をコンパイルすることです。これは、ホストハードウェアを実際に制御することはできません（CPU GHz m CPUカウントなどの「単純な」ものを除く）。利用可能なRAM）。現在、cpuinfo「AMD Opteron（tm）プロセッサ6176」を持っていると言っていますが、それが信頼できるかどうか、そしてゲストがホストのインフラストラクチャを満たすために私の上の別のアーキテクチャに移動できるかどうかは正直にわかりません。シャッフルの必要性（毛深い/ありそうもない音）。

私が本当に保証できるのは私のOSだけです。これは、をuname -m生成する64ビットのLinuxカーネルx86_64です。

4

2 に答える 2

4

GCC4.6.3標準C++ライブラリマニュアルのセクション3.17.14Intel386およびAMDx86-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.

それが価値があるもののために...

好奇心から、あなたが参照した記事で説明されているテクニックを使ってみました。VMwarePlayerゲストとして実行されている64ビットUbuntu12.04でgccv4.6.3をテストしました。VMware VMは、Intel Pentium Dual-CoreE6500CPUを使用するデスクトップ上のWindows7で実行されていました。

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で正しく実行できるコードを生成することであるため、これでどのように問題が発生するかわかりません。（いいえ？）

私は率直に言って、gccCPU-march=nativeオプションがどれほど具体的であるかということに驚いています。CPUのL1キャッシュサイズが32kであるために、生成されたコードを微調整する方法がわかりません。しかし、明らかにこれを行う方法がある場合-march=nativeは、を使用するとgccでそれを行うことができます。

これにより、パフォーマンスが大幅に向上するのではないかと思います。

于 2012-04-13T01:38:19.563 に答える
1

ゲストOSによって報告されたCPUアーキテクチャは、最適化する必要があるものであると考えてください。そうでなければ、私はそれをバグと呼ぶでしょう。バグにはまともな理由がある場合もありますが...

すべてのハイパーバイザーが必ずしも同じであるとは限らないことに注意してください。

特定のハイパーバイザーのメーリングリストを確認することをお勧めします。

于 2012-04-12T23:25:16.157 に答える