仮想マシンのCPUコアが増えるとコンパイル時間が遅くなるのはなぜですか？

[編集＃2] VMWareの誰かがVMWare Fusionのコピーを見つけたら、VirtualBoxとVMWareの比較と同じようにできるとうれしいです。どういうわけか、VMWareハイパーバイザーはハイパースレッディング用に調整されると思う（私の回答も参照）

私は何か奇妙なものを見ています。Windows 7 x64仮想マシンのコア数を増やすと、全体的なコンパイル時間が減少する代わりに増加します。コンパイルは通常、並列処理に非常に適しています（中間部分（依存関係のマッピング後）で、各.c / .cpp / .cs / whateverファイルでコンパイラインスタンスを呼び出して、リンカーが取得する部分オブジェクトを構築することができます）以上。ですから、実際には、コアの数でコンパイルが非常にうまくいくと想像していました。

しかし、私が見ているのは：

• 8コア：1.89秒
• 4コア：1.33秒
• 2コア：1.24秒
• 1コア：1.15秒

これは、単に特定のベンダーのハイパーバイザー実装（私の場合はtype2：virtualbox）による設計成果物なのか、ハイパーバイザー実装をより単純にするためにより多くのVMに広がるものなのでしょうか？非常に多くの要因があるので、私はこの振る舞いについて賛否両論を立てることができるようです-だから誰かが私よりもこのことを知っているなら、あなたの答えを読んでみたいです。

どうもありがとう

[ 編集：コメントのアドレス指定 ]

@MartinBeckett：コールドコンパイルは破棄されました。

@MonsterTruck：直接コンパイルできるオープンソースプロジェクトが見つかりませんでした。素晴らしいと思いますが、今は私の開発環境を台無しにすることはできません。

@Mr Lister、@ philosodad：VirtualBoxを使用して8つのハードウェアスレッドがあるため、エミュレーションなしの1：1マッピングである必要があります

@Thorbjorn：VM用に6.5GBと小さなVS2012プロジェクトがあります-ページファイルをゴミ箱に入れたり出したりすることはほとんどありません。

@All：誰かがオープンソースのVS2010 / VS2012プロジェクトを指すことができれば、それは私の（独自の）VS2012プロジェクトよりも良いコミュニティリファレンスかもしれません。OrchardとDNNは、VS2012でコンパイルするために環境を調整する必要があるようです。VMWare Fusionを使用している人にもこれが表示されるかどうかを確認したい（VMWareとVirtualBoxの区分化の場合）

テストの詳細：

• ハードウェア：Macbook Pro Retina
  • CPU：コアi7 @ 2.3Ghz（クアッドコア、ハイパースレッディング= Windowsタスクマネージャーで8コア）
  • メモリー：16 GB
  • ディスク：256GB SSD
• ホストOS：Mac OS X 10.8
• VMタイプ：VirtualBox 4.1.18（タイプ2ハイパーバイザー）
• ゲストOS：Windows 7 x64 SP1
• コンパイラ：3つのC＃AzureプロジェクトでソリューションをコンパイルするVS2012
  • 「VSCommands」と呼ばれるVS2012プラグインによるコンパイル時間の測定
  • すべてのテストは5回実行され、最初の2回は破棄され、最後の3回は平均されます

回答：速度は低下せず、CPUコアの数でスケールアップします。元の質問で使用されたプロジェクトは、複数のコアのメリットを享受するために「小さすぎます」（実際には大量の開発ですが、コンパイラー用に小さく/最適化されています）。作業を分散する方法を計画したり、複数のコンパイラプロセスを生成したりするのではなく、この小規模で、すぐに作業を連続して行うことが最善のようです。

これは、質問へのコメント（および私の個人的な好奇心）に基づいて行った新しい実験に基づいています。私はより大きなVSプロジェクトを使用しました-Umbraco CMSのソースコードはオープンソースであり、ソリューションファイルを直接ロードして再構築できるためです（ヒント：umbraco_675b272bb0a3\src\umbraco.slnVS2010 / VS2012でロード）。

今、私が見るものは私が期待するものです、すなわちコンパイルがスケールアップします!! さて、私が見つけてからある時点まで：

テイクアウト：

• 新しいVMコアにより、VirtualBoxプロセス内に新しいOS Xスレッドが作成されます
• コンパイル時間は期待どおりに拡大します（コンパイルは十分に長いです）
• 8つのVMコアでは、ペナルティが大きいため（50％ヒット）、コアエミュレーションがVirtualBox内で開始される可能性があります
• これは、OS Xが4つのハイパースレッドコア（8 h / wスレッド）をVirtualBoxの8コアとして提示できないためです。

その最後のポイントにより、「Activity Monitor」（CPU履歴）を介してすべてのコアのCPU履歴を監視することになりました。

テイクアウト：

• 1つのVMコアでは、アクティビティは4つのHWコアを飛び越えているようです。コアレベルで熱を均等に分散するのは理にかなっています。

• 4つの仮想コア（および27のVirtualBox OS Xスレッドまたは全体で〜800 OS Xスレッド）でさえ、奇数のHWスレッド（1,3,5,7）でほぼ飽和しているのはHWスレッド（0,2,4,6）だけですほぼ0％です。スケジューラはHWコアではなくHWスレッドで動作する可能性が高いため、OSX 64ビットカーネル/スケジューラーがハイパースレッドCPU向けに最適化されていない可能性がありますか？または、8VMコアのセットアップを見ると、おそらく高いCPU使用率でそれらの使用を開始していますか？何か面白いことが起こっています...まあ、それはダーウィンの開発者にとっては別の質問です...

[編集]：VMWare Fusionでも同じことを試してみたい。そんなに悪くはないでしょう。彼らはこれを商用製品として紹介するのだろうか...

フッター：

画像が消える場合、コンパイルタイムテーブルは（text、ugly！）

Cores in    Avg compile      Host/OSX    Host/OSX CPU
   VM         times (sec)   Threads      consumption
    1           11.83            24        105-115%
    2           10.04            25        140-190%
    4            9.59            27        180-270%
    8           14.18            31        240-430%

これが発生する理由は1つしかありません。それは、オーバーヘッドが利益を超えているということです。

ホストマシンから実際のコアやプロセス、さらにはスレッドを割り当てるのではなく、複数のコアをエミュレートしている場合があります。それは私にはかなりありそうであり、明らかにあなたに負のスピードアップを与えるつもりです。

もう1つの可能性は、プロセス自体が十分に並列化されておらず、並列化を試みても、得られるよりも通信のオーバーヘッドが大きくなることです。

あなた一人じゃありません ...

JavaでMaven 3.xを使用してi3でコンパイルすると、同じことが起こりました。デフォルトで「4」スレッドにすると、2つのコアのみを使用するように明示的に指示するよりもはるかに遅く、ほぼ50％遅くなります。

ハイパースレッディングコンテキストスイッチングとオーバーラップI / Oに関係があると思います。

あなたがそれについて考え始めるとき、それは理にかなっています。優れたシステム全体のプロファイリングツールを使用して、結果の劣化の原因を証明できます。