-jを作成するために渡されるオプションの最大数を決定する方法は？

nproc利用可能なCPUコア/スレッドの数を提供します。例えば8 双方向SMTをサポートするクアッドコアCPU。

makeこのオプションを使用して並列に実行できるジョブの数は、-jさまざまな要因によって異なります。

• 利用可能なメモリ量
• make各ジョブで使用されるメモリ量
• makeジョブがI/OまたはCPUにバインドされている程度

make -j$(nproc)良い出発点ですが、利用可能なすべてのメモリを消費し、スラッシングを開始しない限り、通常はより高い値を使用できます。

非常に高速なビルドに十分なメモリがある場合は、を使用することをお勧めします。tmpfsこれにより、ほとんどのタスクがCPUにバインドされ、make -j$(nproc)できるだけ早く実行されます。

最も簡単な方法は、nproc次のように使用することです。

make -j`nproc`

このコマンドはnprocマシンのコア数を返します。ティックでラップすると、nprocコマンドが最初に実行され、に渡される番号が返されますmake。

コア数+ 1を実行すると、コンパイル時間が速くなるという逸話的な経験があるかもしれません。これは、I/O レイテンシ、その他のリソース待ち時間、およびその他のリソースの可用性制約にさらに関連しています。

これを行うには、次のようにしますnproc+1。

make -j$((`nproc`+1))

残念ながら、同じビルドの異なる部分でもビルド中のアイテム、方法、当時のボトルネックが発生するシステムリソース、ビルドシステムで進行中の他のタスク、何が発生するかに応じて、J-引数値が衝突する最適な選択になることがありますあります。進行中のネットワーク（分散ビルド技術を使用する場合）、ビルドに関連する複数のキャッシュシステムの状態/場所/パフォーマンスなど

100個の小さなCファイルをコンパイルすることは、1つの巨大なCファイルをコンパイルするよりも速くなる可能性があり、その逆も同様です。非常に複雑な小さなコードを書くことは、大量の単純/線形コードを書くよりも遅くなるかもしれません。

ビルドのコンテキストも重要です。専用サーバーのビルドに最適化されたaj要素を使用し、重複しない独自のビルドの微調整は、開発者が同じ共有サーバー上で並列にビルドしたときに非常に混乱する結果を生み出す可能性があります（それぞれこれらのビルド）。すべてのシリアライゼーションを組み合わせるよりも時間がかかる場合があります）、またはハードウェア構成または仮想化が異なるサーバーの場合。

建物仕様の正確さの側面もあります。非常に複雑なビルドには、間欠的なビルド失敗を引き起こす競合条件がある可能性があり、その発生率はj因子の増加または減少に大きく依存します。

ずっと行けました。カギは現実的に評価しなければならないということだ。あなたの組み込みあなたの背景j 引数を最適化したい。 @Jeff Schallerのコメントが適用されます。最適なものが見つかるまで繰り返します。個人的には、私はnprocの値で始めて最初に試み、次にそれを試したときにすぐにパフォーマンスが低下した場合にのみ試してみます。

測定のボラティリティに関するアイデアを得るために、まず同じ環境でいくつかの同じビルドを測定することをお勧めします。測定値が高すぎると、全体的な最適化の努力が危険にさらされる可能性があります（20％のボラティリティは、完全なj因子検索で読み取り値を10％改善/縮退させます）。

最後に、IMHO（適応）を使用する方が良いです。稼働中のサーバー固定のj引数ではなく、サポートされて利用可能であれば、より広い文脈で継続的に優れたビルドパフォーマンスを提供できます。

make仮想CPUの数だけ並列ワーカースレッドを使用するコマンドを作成するには、次のようにすることをお勧めします。

nproc | xargs -I % make -j%

RUNスタンドアロンコマンドまたは内部ディレクティブで作成できますDockerfile（Dockerはネストしたコマンドをサポートしていないため）。