nproc 使用可能な CPU コア/スレッドの数を示します。例 双方向 SMT をサポートするクアッドコア CPU で 8。
make で並行して実行できるジョブの数 -j を使用して オプションは、いくつかの要因によって異なります:
- 利用可能なメモリの量
- 各
makeが使用するメモリ量 仕事 makeの程度 ジョブは I/O または CPU バウンド
make -j$(nproc) 開始するのに適切な場所ですが、使用可能なメモリを使い果たしてスラッシングを開始しない限り、通常はより高い値を使用できます。
非常に高速なビルドのために、十分なメモリがある場合は、tmpfs を使用することをお勧めします 、そうすれば、ほとんどのジョブは CPU バウンドになり、make -j$(nproc) になります
最も簡単な方法は、 nproc を使用することです そのように:
make -j`nproc`
コマンド nproc マシンのコア数を返します。目盛りでラップすることにより、 nproc コマンドが最初に実行され、数値が返され、その数値が make に渡されます .
core-count + 1 を実行するとコンパイル時間が短縮されるという逸話的な経験があるかもしれません。これは、I/O の遅延、その他のリソースの遅延、その他のリソースの制約の可用性などの要因と関係があります。
nproc+1 でこれを行うには 、これを試してください:
make -j$((`nproc`+1))
残念ながら、同じビルドのさまざまな部分でさえ、競合する j ファクターの値で最適な場合があります。これは、ビルドされているもの、どのように、その時点でどのシステム リソースがボトルネックであるか、ビルド マシンで他に何が起こっているか、ビルド マシンで何が起こっているかによって異なります。ネットワーク (分散ビルド手法を使用している場合)、ビルドに含まれる多くのキャッシュ システムのステータス/場所/パフォーマンスなど。
100 個の小さな C ファイルをコンパイルする方が、1 つの巨大なファイルをコンパイルするよりも高速である場合があり、その逆も同様です。非常に複雑な小さなコードを構築すると、大量の単純明快なコードを構築するよりも遅くなる可能性があります。
ビルドのコンテキストでさえ重要です。排他的で重複しないビルド用に微調整された専用サーバーでのビルド用に最適化された j ファクターを使用すると、開発者が同じ共有サーバーで並行してビルドを行う場合、非常に残念な結果が生じる可能性があります (各ビルドにはさらに時間がかかる場合があります)。シリアル化されている場合はすべてを合わせた時間よりも時間がかかります)、または異なるハードウェア構成または仮想化されたサーバーで。
ビルド仕様の正確さの側面もあります。非常に複雑なビルドでは競合状態が発生し、j 係数の増減によって発生率が大幅に変化する断続的なビルド エラーが発生する場合があります。
私は何度も行くことができます。重要なのは、あなたのを実際に評価する必要があるということです まさにあなたの文脈で構築する j ファクターを最適化する必要があります。 @Jeff Schaller のコメントが適用されます。最適なものが見つかるまで繰り返します。個人的には、nproc 値から始めて、最初に上向きに試し、上向きにしようとするとすぐに劣化が見られる場合にのみ下向きに試します。
測定値の変動性を把握するためだけに、同一と思われる状況でいくつかの同一のビルドを最初に測定することをお勧めします。 jファクター検索での劣化読み取り）
最後に、固定された j ファクターの代わりに、サポートされていて利用可能な場合は (適応型) ジョブサーバーを使用することをお勧めします。より広い範囲のコンテキストで一貫して優れたビルド パフォーマンスを提供します。