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

できるだけ早くコンパイルしたい。図を移動します。そして、-jオプションに続く番号の選択を自動化したいと思います。シェルスクリプトなどで、その値をプログラムで選択するにはどうすればよいですか？

の出力は、nprocコンパイルに使用できるスレッドの数と同等ですか？

make -j1 make -j16

nproc使用可能なCPUコア/スレッドの数を示します。たとえば、双方向SMTをサポートするクアッドコアCPU では8です。

このオプションをmake使用して並行して実行できるジョブの数は-j、いくつかの要因に依存します。

• 利用可能なメモリの量
• 各makeジョブが使用するメモリ量
• どの程度makeの仕事は、I / O-またはCPUがバインドされています

make -j$(nproc) 開始するには適切な場所ですが、使用可能なメモリを使い果たしてスラッシングを開始しない限り、通常はより高い値を使用できます。

本当に高速なビルドの場合、十分なメモリがある場合tmpfs、ほとんどのジョブがCPUにバインドさmake -j$(nproc)れ、可能な限り高速に動作するように、を使用することをお勧めします。

残念ながら、同じビルドの異なる部分でさえ、jファクターの値が競合する場合に最適な場合があります。これは、ビルド対象、その方法、その時点でどのシステムリソースがボトルネックであるか、ビルドマシンで他に何が起こっているか、何が起こっているかによって異なりますネットワーク（分散ビルドテクニックを使用している場合）、ビルドに関係する多くのキャッシュシステムのステータス/場所/パフォーマンスなど。

100個の小さなCファイルをコンパイルする方が、1つの巨大なCファイルをコンパイルするよりも速くなる場合があります。小さく複雑なコードの構築は、大量の単純な/線形コードの構築よりも遅くなる可能性があります。

ビルドのコンテキストも重要です-専用のサーバー上のビルド用に最適化されたajファクターを使用して、排他的で重複しないビルド用に微調整すると、同じ共有サーバー上で並行してビルドする開発者が使用すると、非常に期待外れの結果が生じる可能性がありますシリアル化されている場合はそれらすべてを組み合わせた時間）、または異なるハードウェア構成のサーバー上または仮想化された時間です。

ビルド仕様の正確さの側面もあります。非常に複雑なビルドには、jファクターの増減に応じて大幅に変化する可能性のある断続的なビルド障害を引き起こす競合状態がある場合があります。

私は続けることができます。ポイントは、jファクターを最適化したいコンテキストでビルドを実際に評価する必要があるということです。@Jeff Schallerのコメントが適用されます。最適なものが見つかるまで繰り返します。個人的には、nprocの値から始め、上向きの試みがすぐに劣化を示す場合にのみ、最初に上向きと下向きに試します。

測定のばらつきを把握するために、おそらく同一のコンテキストでいくつかの同一のビルドを最初に測定することをお勧めします-高すぎると全体の最適化の作業を危険にさらす可能性があります（20％のばらつきは完全に10％の改善/ j因子検索での劣化の読み取り）。

最後に、固定されたjファクターの代わりに、サポートおよび利用可能な場合は（適応）ジョブサーバーを使用することをお勧めします-幅広いコンテキストで一貫してより良いビルドパフォーマンスを提供します。

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

make -j`nproc`

このコマンドnprocは、マシン上のコアの数を返します。目盛りで囲むことにより、nprocコマンドが最初に実行され、数値が返され、その数値がに渡されmakeます。

コアカウント+ 1を実行するとコンパイル時間が短縮されるという逸話的な経験があります。これは、I / O遅延、他のリソース遅延、リソース制約の他の可用性などの要因に関係しています。

でこれを行うには、これをnproc+1試してください：

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

make仮想CPUを持っているのと同じ数の並列ワーカーを使用するコマンドを作成する場合は、次の使用をお勧めします。

nproc | xargs -I % make -j%

スタンドアロンコマンドとして、またはその中のRUNディレクティブとして記述できますDockerfile（Dockerはネストされたコマンドをサポートしていないため）