0

今朝コンパイルしている間、私は考えました。

専用のLinuxマシン(たとえばFedoraを実行している)を考えると、ユーザーはリモートでログインし、シンボリックリンクでリンクされた自分のマシン(小さなLAN上)に保存されているc ++ソフトウェアをLinuxボックスにコンパイルします(gccを使用)。

今のところ、各ユーザーが同じコードをコンパイルしていると仮定します...1人のユーザーが10分で自分のコードをコンパイルしてリンクできます。

2人のユーザーが同時にコンパイルするのに合計20分かかるのでしょうか?3人、つまり10人のユーザーはどうでしょうか?

ユーザーが増えるにつれて収穫逓減をもたらすオーバーヘッドが関係していますか?

ボーナスの質問として-このセットアップでコンパイル効率を上げるためのヒントはありますか?

4

4 に答える 4

2

私は提案しdistccます。

于 2009-03-18T10:30:54.993 に答える
0

プロジェクトのソースのサイズによっては、コンパイルする前にすべてのファイルをビルドマシンにローカルにコピーすることで節約できる場合がありますコンパイラが必要に応じてすべてのファイルをネットワーク経由でプルする必要がある場合、ネットワークアクセスはディスクアクセスよりもはるかに遅いため、オーバーヘッドが発生します。

スクリプトを作成したり、変更されたファイルのみをビルドマシンにコピーするツールを使用したりすると、オーバーヘッドが大幅に削減されます。この場合、ビルドマシンは基本的にソースファイルのローカルミラーを保持し、コンパイルするたびに、変更されたファイルを更新してからコンパイルします。明らかに、ユーザーが多い場合やプロジェクトファイルが大きい場合は、ストレージ/スペースの問題が発生します。

于 2009-03-18T10:28:26.730 に答える
0

次の理由により、常にオーバーヘッドが発生します。

  • スケジューリングのニーズ
  • 時間の競合するI/O操作

ネットワークアクセスは、たとえばディスクアクセスよりも大幅に遅いため、最後のものが最も重要になります。ここでは、プリキャッシュ(最初にすべてのファイルをローカルでフェッチしてからコンパイルを開始する)が役立つ場合があります。すでに開始されているビルドは、新しい同時ユーザーによって妨げられることはありません。

于 2009-03-18T10:29:03.237 に答える
0

コンパイルはほとんど CPU に制限されるため、十分な RAM があると仮定すると、コンパイル時間はおおよそ (タスクあたりの時間) * (タスクの数) / (システム内の CPU/コアの数) になると予想できます。(不思議なことに、私のプロジェクトの 3 コア システムで 'make -j' を実行したところ、3 倍以上のスピードアップが得られたので、シーケンシャル make がフル スピードで実行されないようにする何らかのブロックの問題が発生している可能性があります。)

ユーザーが自分のコンピューターでプログラムをコンパイルしないのはなぜですか?

于 2009-03-18T10:36:24.590 に答える