C ++をコンパイルするために、WindowsをLinuxと同じ速さで実行するにはどうすればよいですか？

これはプログラミングの問題ではないことを知っていますが、関連があります。

私はかなり大きなクロスプラットフォームプロジェクトに取り組んでいます。WindowsではVC ++ 2008を使用します。Linuxではgccを使用します。プロジェクトには約40kのファイルがあります。Windowsは、同じプロジェクトをコンパイルおよびリンクする際に、Linuxよりも10倍から40倍遅いです。どうすれば修正できますか？

Linuxでは20秒、Windowsでは3分を超える単一の変更増分ビルド。どうして？Linuxに「ゴールド」リンカーをインストールして、その時間を7秒まで短縮することもできます。

同様に、gitはWindowsよりもLinuxで10〜40倍高速です。

gitの場合、gitがWindowsを最適な方法で使用していない可能性がありますが、VC ++ですか？Microsoftは自社の開発者をできる限り生産的にしたいと考え、より高速なコンパイルはそのための長い道のりになると思います。たぶん彼らは開発者にC＃を勧めようとしているのでしょうか？

簡単なテストとして、多数のサブフォルダーを含むフォルダーを見つけて、簡単なテストを行います

dir /s > c:\list.txt

Windowsの場合。キャッシュから実行するように、2回実行して2回目の実行の時間を計ります。ファイルをLinuxにコピーし、同等の2回の実行を行い、2回目の実行の時間を計ります。

ls -R > /tmp/list.txt

まったく同じ仕様のワークステーションが2台あります。12gigのRAM、8コア、3.0GHzのHP Z600。〜400kファイルを含むフォルダーでは、Windowsは40秒かかり、Linuxは1秒未満かかります。

Windowsを高速化するために設定できるレジストリ設定はありますか？何ができますか？

コンパイル時間に関連するいくつかのわずかに関連するリンク。必ずしもI / Oとは限りません。

• どうやらWindows 10（Windows 7ではない）には、プロセスを閉じるとグローバルロックが保持されるという問題があるようです。複数のコア、したがって複数のプロセスでコンパイルすると、この問題が発生します。

• この/analyseオプションはWebブラウザーをロードするため、パフォーマンスに悪影響を与える可能性があります。（ここでは関係ありませんが、知っておくと便利です）

筋金入りのWindowsシステムハッカーがやって来ない限り、党派的なコメント（私はしません）と推測（これは私が試そうとしているもの）を超えることはありません。

1. ファイルシステム-同じファイルシステムで同じ操作（を含むdir）を試行する必要があります。私はこれに出くわしましたさまざまなパラメータのいくつかのファイルシステムをベンチマークするにた。

2. キャッシング。LinuxでRAMディスクのコンパイルを実行しようとしたところ、カーネルがキャッシュを処理する方法のおかげで、ディスクでコンパイルするよりも遅いことがわかりました。これはLinuxの確かなセールスポイントであり、パフォーマンスが大きく異なる理由かもしれません。

3. Windowsでの依存関係の仕様が不適切です。おそらく、Windowsのchromium依存関係の仕様は、Linuxほど正確ではありません。これにより、小さな変更を加えたときに不要なコンパイルが発生する可能性があります。Windowsで同じコンパイラツールチェーンを使用してこれを検証できる場合があります。

いくつかのアイデア：

1. 8.3名を無効にします。これは、ファイル数が多く、フォルダ数が比較的少ないドライブでは大きな要因になる可能性があります。fsutil behavior set disable8dot3 1
2. より多くのフォルダを使用します。私の経験では、NTFSはフォルダーごとに約1000個を超えるファイルを使用してスローダウンし始めます。
3. MSBuildで並列ビルドを有効にします。"/ m"スイッチを追加するだけで、CPUコアごとにMSBuildの1つのコピーが自動的に開始されます。
4. SSDにファイルを置く-ランダムI / Oに非常に役立ちます。
5. 平均ファイルサイズが4KBをはるかに超える場合は、平均ファイルサイズにほぼ対応するより大きなクラスターサイズでファイルシステムを再構築することを検討してください。
6. ファイルが最適化されていることを確認してください。断片化されたファイルは多くのディスクシークを引き起こし、スループットの40+倍のコストがかかる可能性があります。sysinternalsの「contig」ユ​​ーティリティ、または組み込みのWindowsデフラグツールを使用します。
7. 平均ファイルサイズが小さく、使用しているパーティションが比較的いっぱいである場合、フラグメント化されたMFTで実行している可能性があり、パフォーマンスが低下します。また、1Kより小さいファイルはMFTに直接保存されます。上記の「contig」ユ​​ーティリティが役立つ場合があります。または、MFTサイズを増やす必要がある場合があります。次のコマンドを実行すると、ボリュームが25％になりfsutil behavior set mftzone 2ます。最後の数値を3または4に変更して、サイズをさらに12.5％増やします。コマンドの実行後、再起動してファイルシステムを作成します。
8. 最終アクセス時間を無効にする： fsutil behavior set disablelastaccess 1
9. インデックスサービスを無効にする
10. ウイルス対策ソフトウェアとスパイウェア対策ソフトウェアを無効にするか、少なくとも関連するフォルダを無視するように設定します。
11. ファイルをOSおよびページングファイルとは別の物理ドライブに配置します。別の物理ドライブを使用すると、Windowsは両方のドライブに対して並列I / Oを使用できます。
12. コンパイラフラグを確認してください。Windows C ++コンパイラには多くのオプションがあります。本当に必要なものだけを使用していることを確認してください。
13. OSがページプールバッファーに使用するメモリの量を増やしてみてください（最初に十分なRAMがあることを確認してください）。 fsutil behavior set memoryusage 2
14. Windowsエラーログをチェックして、ディスクエラーが時々発生しないことを確認します。
15. 物理ディスク関連のパフォーマンスカウンターを見て、ディスクのビジー状態を確認してください。キューの長さが長いか、転送あたりの時間が長いことは悪い兆候です。
16. ディスクパーティションの最初の30％は、raw転送時間の点で、残りのディスクよりもはるかに高速です。パーティションを狭くすると、シーク時間が最小限になります。
17. RAIDを使用していますか？その場合、RAIDタイプの選択を最適化する必要がある場合があります（RAID-5は、コンパイルなどの書き込みの多い操作には適していません）
18. 不要なサービスを無効にします
19. フォルダーの最適化：すべてのファイルを別のドライブ（ファイルのみ）にコピーし、元のファイルを削除し、すべてのフォルダーを別のドライブ（空のフォルダーのみ）にコピーし、元のフォルダーを削除し、元のドライブを最適化し、フォルダー構造を最初にコピーします、次にファイルをコピーします。Windowsが一度に1つのファイルで大きなフォルダーを作成すると、フォルダーが断片化して遅くなります。（「contig」もここで役立つはずです）
20. I / OバウンドでCPUサイクルに余裕がある場合は、ディスク圧縮をオンにしてみてください。CPUにいくらかのコストがかかりますが、（ソースコードのような）高度に圧縮可能なファイルを大幅に高速化できます。

NTFSは、ファイルアクセス時間を毎回節約します。あなたはそれを無効にしてみることができます： "fsutil behavior set disablelastaccess 1"（再起動）

ビジュアルc ++の問題は、私が知る限り、このシナリオを最適化することはコンパイラチームの優先事項ではないということです。それらの解決策は、プリコンパイル済みヘッダー機能を使用することです。これは、特定のプロジェクトが実行したウィンドウです。ポータブルではありませんが、動作します。

さらに、Windowsには通常、ウイルススキャナーがあり、システムの復元ツールや検索ツールがあり、buidフォルダーを監視しているとビルド時間が完全に台無しになる可能性があります。Windows 7のリソースモニターは、それを見つけるのに役立ちます。私が持ってここに返信あなたが本当に興味があるなら、VC ++ビルド時間を最適化するためのいくつかのさらなるヒントをします。

私は個人的に、LinuxでWindows仮想マシンを実行すると、WindowsのIO速度の大幅な低下を解消できたことがわかりました。これは、おそらくLinux vmがWindows自体ではなかった多くのキャッシュを行っていたためです。

そうすることで、私が取り組んでいた大規模な（250Kloc）C ++プロジェクトのコンパイル時間を15分から6分程度まで高速化することができました。

これを行うのが難しいのは、C ++がそれ自体とコンパイルプロセスを多数の小さな個々のファイルに分散させる傾向があるという事実によるものです。これはLinuxが得意でWindowsが得意ではありません。Windows用の非常に高速なC ++コンパイラを作成する場合は、すべてをRAMに保持し、ファイルシステムにはできるだけ手を触れないようにしてください。

これは、より高速なLinux C ++コンパイルチェーンを作成する方法でもありますが、Linuxでは、ファイルシステムが既に多くの調整を行っているため、それほど重要ではありません。

これの理由は、Unixの文化によるものです。歴史的に、ファイルシステムのパフォーマンスは、WindowsよりもUnixの世界ではるかに優先されてきました。Windowsでは優先度が高くなかったことは言うまでもなく、Unixでは優先度が高くなっています。

1. ソースコードへのアクセス。

   あなたがコントロールできないものを変えることはできません。Windows NTFSソースコードにアクセスできないことは、パフォーマンスを改善するためのほとんどの努力がハードウェアの改善によるものであることを意味します。つまり、パフォーマンスが遅い場合は、バスやストレージメディアなどのハードウェアを改善することで問題を回避します。問題を回避する必要がある場合にのみ、多くのことを行うことができます。

   Unixのソースコードへのアクセス（オープンソースの前であっても）はより広く行われていました。したがって、パフォーマンスを向上させたい場合は、最初にソフトウェア（より安く簡単）で対処し、次にハードウェアで対処します。

   その結果、Unixファイルシステムを研究し、パフォーマンスを改善する新しい方法を見つけることで博士号を取得した人は世界中にたくさんいます。

2. Unixは多くの小さなファイルに向かう傾向があります。Windowsは、少数（または単一）の大きなファイルに向かう傾向があります。

   Unixアプリケーションは多くの小さなファイルを扱う傾向があります。ソフトウェア開発環境について考えてみてください。多くの小さなソースファイルがあり、それぞれに独自の目的があります。最終段階（リンク）では1つの大きなファイルが作成されますが、その割合はわずかです。

   その結果、Unixはファイルのオープンとクローズ、ディレクトリのスキャンなどのために高度に最適化されたシステムコールを備えています。Unixの研究論文の歴史は何十年にもわたるファイルシステムの最適化に及んでおり、ディレクトリアクセス（ルックアップとフルディレクトリスキャン）の改善、最初のファイルのオープンなどに多くの考慮が払われています。

   Windowsアプリケーションは、1つの大きなファイルを開き、長時間開いたままにし、完了したら閉じる傾向があります。MS-Wordについて考えてください。msword.exe（またはその他）は、ファイルを1回開き、何時間も追加し、内部ブロックを更新します。ファイルのオープンを最適化することの価値は、時間の無駄です。

   Windowsのベンチマークと最適化の歴史は、長いファイルの読み書き速度にあります。それが最適化されます。

   悲しいことに、ソフトウェア開発は最初の状況に向かっています。Unix（TeX / LaTeX）に最適なワープロシステムであるヘックでは、各章を別のファイルに入れ、それらをすべて#includeすることをお勧めします。

3. Unixは高性能を重視しています。Windowsはユーザーエクスペリエンスに重点を置いています

   Unixはサーバールームで起動しました。ユーザーインターフェイスはありません。ユーザーが目にするのは速度だけです。したがって、速度が優先されます。

   Windowsはデスクトップから始まりました。ユーザーは自分が何を見るかだけを気にし、UIを見ることができます。したがって、UIの改善にはパフォーマンスよりも多くのエネルギーが費やされます。

4. Windowsエコシステムは、計画された陳腐化に依存しています。新しいハードウェアが1〜2年先にあるのに、なぜソフトウェアを最適化するのですか？

   私は陰謀説を信じていませんが、もしそうした場合、Windowsの文化ではパフォーマンスを向上させるインセンティブが少ないことを指摘します。Windowsのビジネスモデルは、時計仕掛けのような新しいマシンを購入する人々に依存しています。（そのため、MSがオペレーティングシステムの出荷を遅らせたり、Intelがチップのリリース日を見逃したりすると、何千もの企業の株価が影響を受けます。）これは、新しいハードウェアを購入するように人々に指示することによって、パフォーマンスの問題を解決するインセンティブがあることを意味します。実際の問題を改善するのではなく、遅いオペレーティングシステムです。Unixは、予算が厳しく、ファイルシステムを高速化する新しい方法を発明することで博士号を取得できる学界から来ています。学界の誰かが注文書を発行して問題を解決するためのポイントを獲得することはめったにありません。

   また、Unixはオープンソースであるため（そうでなかったとしても、誰もがソースにアクセスできました）、退屈な博士課程の学生なら誰でもコードを読んで、それを改良することで有名になることができます。これはWindowsでは起こりません（MSには、Windowsのソースコードに学者がアクセスできるプログラムがあり、ほとんど利用されていません）。以下のUnix関連のパフォーマンスペーパーをご覧ください。httpまたは、Osterhaus、Henry Spencerなどの論文の歴史を調べて。ヘック、Unixの歴史の中で最大の（そして見るのが最も楽しい）議論の1つは、OsterhausとSelzerの間のやり取りでした。 html：//www.eecs.harvard.edu/margo/papers/ Windowsの世界でそのようなことが起こっているのはわかりません。ベンダーがお互いを1対1で見ているように見えるかもしれませんが、革新はすべて標準化団体レベルにあるように思われるため、最近ではそれははるかにまれになっているようです。

それが私の見方です。

更新： Microsoftから提供されている新しいコンパイラチェーンを見ると、ツールチェーン全体をRAMに保持し、繰り返し作業を減らすことが容易になるため、非常に楽観的になります。非常に印象的なもの。

インクリメンタルリンク

VC 2008ソリューションが.lib出力を持つ複数のプロジェクトとして設定されている場合は、「ライブラリ依存関係入力を使用」を設定する必要があります。これにより、リンカーは.libではなく.objファイルに直接リンクします。（そして実際にそれを段階的にリンクさせます。）

ディレクトリトラバーサルのパフォーマンス

元のマシンでのディレクトリのクロールと、別のマシンで同じファイルを使用して新しく作成されたディレクトリのクロールを比較するのは少し不公平です。同等のテストが必要な場合は、ソースマシン上のディレクトリの別のコピーを作成する必要があります。（それでもまだ遅いかもしれませんが、ディスクの断片化、短いファイル名、バックグラウンドサービスなど、さまざまな原因が考えられます。）パフォーマンスに関する問題は、dir /s実際のファイルを測定するよりも、出力を書き込むことに関係があると思いますがトラバーサルパフォーマンス。dir /s /b > nul巨大なディレクトリを持つ私のマシンでも遅いです。

私はそれがファイルシステムに関連していると確信しています。プラットフォーム依存のコードが絶対に必要な場合を除いて、すべてのコードが共通であるLinuxおよびWindowsのクロスプラットフォームプロジェクトに取り組んでいます。私たちはgitではなくMercurialを使用しているため、gitの「Linuxness」は適用されません。中央リポジトリから変更を取り込むには、Linuxに比べてWindowsで永遠にかかりますが、私たちのWindows 7マシンはWindows XPのマシンよりもはるかに優れていると言わざるを得ません。その後のコードのコンパイルは、VS 2008ではさらに悪くなります。hgだけではありません。CMakeはWindowsでも実行速度がかなり遅く、これらのツールはどちらも何よりもファイルシステムを使用します。

問題は非常に悪いので、Windows環境で作業するほとんどの開発者は、インクリメンタルビルドを実行する必要さえありません。代わりに、ユニティビルドを実行する方が速いことがわかりました。

ちなみに、Windowsでのコンパイル速度を大幅に低下させたい場合は、前述のUnityビルドをお勧めします。ビルドシステムに正しく実装するのは面倒です（私はCMakeのチームのためにそれを行いました）が、一度完了すると、継続的インテグレーションサーバーの処理が自動的にスピードアップします。ビルドシステムが吐き出すバイナリの数に応じて、1〜2桁の改善が得られます。あなたのマイレージは異なる場合があります。私たちの場合、Linuxビルドが3倍、Windowsが1倍ほど高速化されたと思いますが、共有ライブラリと実行可能ファイルが多数あります（これにより、単一ビルドの利点が減少します）。

大規模なクロスプラットフォームプロジェクトをどのように構築しますか？LinuxとWindowsで共通のmakefileを使用している場合、makefileがWindows上で高速になるように設計されていなければ、Windowsのパフォーマンスを10倍に簡単に低下させる可能性があります。

LinuxおよびWindows用の共通（GNU）メイクファイルを使用して、クロスプラットフォームプロジェクトのいくつかのメイクファイルを修正しました。Makeはsh.exeレシピの各行のプロセスを開始しており、WindowsとLinuxの間でパフォーマンスの違いを引き起こしています！

GNU makeドキュメントによると

.ONESHELL：

問題は解決するはずですが、この機能は（現在）Windows makeではサポートされていません。したがって、（たとえば、現在のエディター行の最後に; \または\を追加することによって）論理行が1つになるようにレシピを書き換えることは非常にうまくいきました！

私見これはすべてディスクI / Oパフォーマンスに関するものです。大きさの順序は、多くの操作がWindowsではディスクに行われるのに対し、Linuxではメモリで処理されることを示唆しています。つまり、Linuxの方がキャッシュが優れています。Windowsでの最良のオプションは、ファイルを高速ディスク、サーバー、またはファイルシステムに移動することです。ソリッドステートドライブを購入するか、ファイルをRAMディスクまたは高速NFSサーバーに移動することを検討してください。

私はディレクトリトラバーサルテストを実行しましたが、結果は報告されたコンパイル時間に非常に近く、これはCPU処理時間やコンパイラー/リンカーアルゴリズムとはまったく関係がないことを示唆しています。

クロムディレクトリツリーをトラバースする上記の推奨時間の測定：

• NTFS上のWindows Home Premium 7（8GB Ram）：32秒
• Ubuntu 11.04 Linux（2GB Ram）、NTFS：10秒
• Ubuntu 11.04 Linux（2GB Ram）（ext4）：0.6秒

テストのために、クロムのソースをプルしました（両方ともwin / linuxの下で）

git clone http://github.com/chromium/chromium.git 
cd chromium
git checkout remotes/origin/trunk 

走った時間を測る

ls -lR > ../list.txt ; time ls -lR > ../list.txt # bash
dir -Recurse > ../list.txt ; (measure-command { dir -Recurse > ../list.txt }).TotalSeconds  #Powershell

アクセスタイムスタンプをオフにして、ウイルススキャナーをオフにし、Windowsでキャッシュマネージャーの設定を増やしました（> 2Gb RAM）-目立った改善はありませんでした。実際のところ、Linuxはそのままで、RAMの4分の1を搭載したWindowsの50倍のパフォーマンスを発揮します。

数値が間違っていると主張したい人のために-何らかの理由で-試してみて、あなたの発見を投稿してください。

nmakeの代わりにjomを使用してみてください

ここで入手：https : //github.com/qt-labs/jom

実際のところ、nmakeはコアの1つだけを使用しています。jomはマルチコアプロセッサを利用するnmakeのクローンです。

GNU makeは、-jオプションのおかげですぐにそれを実行できます。これが、Microsoft nmakeと比較した場合の速度の理由かもしれません。

jomは、異なるプロセッサ/コアで異なるmakeコマンドを並列に実行することで機能します。違いを感じてみてください！

Windows上のMinGWツールのGnu makeおよびその他のツールを使用して、1つの監視のみを追加したいと思います。ツールがIP経由で通信できない場合でも、ホスト名を解決するようです。これは、MinGWランタイムの初期化ルーチンが原因で発生したと思います。ローカルDNSプロキシを実行すると、これらのツールを使用してコンパイル速度を向上させることができました。

VPN接続を並行して開いたときにビルド速度が10倍ほど低下したため、大きな頭痛の種になる前に。この場合、これらすべてのDNSルックアップはVPNを通過しました。

この観察は、MinGWベースだけでなく、他のビルドツールにも当てはまる可能性があり、その間に最新のMinGWバージョンで変更されている可能性があります。

私は最近、mingw bash.exeを次のバージョンで置き換えることにより、Gnu makeを使用してWindowsでコンパイルを約10％高速化する別の方法をアーカイブできました win-bashの

（インタラクティブな編集に関しては、win-bashはあまり快適ではありません。）