ここにいる何人かの人々は、新しいWD Velociraptor 10000rpmハードディスクへの切り替えを勧めました。雑誌の記事でもその性能を絶賛。私はそれを購入し、古いシステムをそれにミラーリングしました。結果としてコンパイル速度が向上することは、やや残念です。
私は 1.5G RAM を搭載したE6600を持っています。これは、1200 個のファイルを含む C++ プロジェクトです。ビルドは Visual Studio 2005 で行われます。音響管理はオフになっています (とにかく大きな違いはありません)。
何かがうまくいかなかったのか、それともこの適度な加速が本当にすべてなのか、私は期待できますか?
編集： RAMを増やすことを推奨する人もいます。RAM を 2 倍の 3GB にすることで、最小限のゲイン (3-5%) を得ました。
/MP オプション (文書化されていないため、プロセッサ オプションに手動で入力する必要があります) を使用して、ソース レベルの並列ビルドを有効にしていますか? これにより、ハードディスクが高速になるだけでなく、コンパイルが大幅に高速化されます。それによる利益はごくわずかです。
Visual Studio 2005 では、複数のプロジェクトを並行してビルドできます。マルチコア マシンでは既定でビルドされますが、プロジェクトが相互にどのように依存しているかによっては、それらを並行してビルドできない場合があります。
1200 cpp ファイルが 1 つのプロジェクト内にある場合、CPU をすべて使用していない可能性があります。私が間違っていなければ、C6600 はクアッドコア CPU です。
デイブ
これは実際には、ハードディスクを交換するだけで速度が大幅に向上します。この時点でおそらくメモリまたは CPU バウンドです。最近では 1.5GB は軽く、RAM は非常に安価です。メモリを増やすと、かなり大きな改善が見られる場合があります。
推奨事項として、複数のドライブがインストールされている場合は、ビルド ディレクトリをソース ファイルとは別のディスク上のどこかに設定してみてください。
このコメントについて：
1200 cpp ファイルが 1 つのプロジェクト内にある場合、CPU をすべて使用していない可能性があります。私が間違っていなければ、C6600 はクアッドコア CPU です。
実際、C6600 は何でもありません。E6600 と Q6600 があります。E6600 はデュアル コアで、Q6600 はクアッド コアです。私の開発マシンでは、クアッド コア CPU を使用しています。私たちのプロジェクトには 1200 以上のファイルがありますが、コンパイル時にまだ簡単にプロセッサが制限されます (ただし、より高速なハード ドライブはスピードアップに役立ちます!)。
ハードディスクの読み取りがコンパイルのボトルネックではなかったと思います。現実的には、ハードディスクから読み書きする必要があるものはほとんどありません。より多くの RAM またはより高速なプロセッサを使用すると、パフォーマンスがさらに向上する可能性があります。
結果から、hdd レイテンシー速度が探していたボトルネックではないか、プロジェクトがすでに可能な限り高速に構築されていることをお勧めします。考慮すべきその他の項目は次のとおりです。
ハードドライブを改善するだけで、速度が最大 6% 向上します。ハウラーの言うとおりだ。より高速なRAM と PCU を入手してください。
多くの人がすでに指摘しているように、おそらく本当のボトルネックに取り組んでいないでしょう。パーツ (またはコード) をランダムに変更することは、「低音の逆行」と言えます。最初にパフォーマンスのボトルネックを特定してから、何かを変更します。
CPU または I/O バウンドで、CPU 使用率、ディスク キューの長さ、および IO バイトを調べて、何が起こっているかを最初に把握したい場合は、Perfmon を使用すると概要を把握できます。
すべてのソースを RAM ドライブに置くことで、コンパイル時間を半分に短縮しました。
http://www.superspeed.com/desktop/ramdisk.phpを試してみて、1GB の RAM ドライブをインストールし、すべてのソースをそこにコピーしました。RAM から直接ビルドすると、IO オーバーヘッドが大幅に削減されます。
私が編集しているものと、その内容についてのアイデアを提供するために。
私のビルドは約 135 秒から 65 秒になりました。
欠点は、ソース ファイルが RAM に存在することです。そのため、ソース管理についてより注意を払う必要があります。マシンの電源が失われると、バージョン管理されていないすべての変更が失われます。一部の RAM ドライブは、マシンをシャットダウンしたときに自身をディスクに保存するという事実によってわずかに軽減されますが、それでも、最後のチェックアウトまたは最後のシャットダウンからすべてが失われます。
また、ソフトウェアの料金を支払う必要があります。しかし、あなたはハードドライブに大金を払っているので、これは大したことではないかもしれません.
利点は、コンパイル時間が長くなることと、exe が既にメモリ内に存在するという事実です。そのため、起動時間とデバッグ時間が少し改善されます。ただし、本当の利点はコンパイル時間です。
VC 2005 はプロジェクトごとに一度に複数のファイルをコンパイルしないため、VC 2008 に移行して両方の CPU コアを使用するか、ソリューションを複数のライブラリ サブプロジェクトに分割して複数のコンパイルを実行します。
1200 ソース ファイルはたくさんありますが、いずれも数百 K を超える可能性は低いため、すべてをメモリに読み込む必要がありますが、そうするのにそれほど時間はかかりません。
システム メモリを 4G に増やして (そうです、32 ビット OS の限界については知っています)、CPU を調べると、単に高速なディスク ドライブを使用するよりもはるかに多くのパフォーマンスが向上する可能性があります。