デュアルコアCPUを使用するときに人々が-j3オプションを推奨するのはなぜですか？

常に機能する単純なルールはありません。人々は特定のコンピュータで特定の編集を試みたが、それが最適な設定であったか、または現実に関連しているかもしれないかもしれないいくつかの推論に従ったので、特定の番号を推薦することができます。

RAMが多い場合、長いコンパイルの制限要因はCPU時間です。その後、CPUごとに1つのジョブと時々I / Oブロックの保留ジョブを追加するのが良い設定です。これは-j3デュアルコアCPU（またはより正確にはデュアルCPUシステムに適しています。各コアがハイパースレッディングされている場合は4つのCPUがあるため-j5）に適しています。

ＲＡＭが非常に小さい場合、１つの制限要因は、多数の同時タスクを有することができないか、またはタスクが連続的に互いに交換されることであり得る。たとえば、2つのコンパイラインスタンスをメモリに簡単に合わせることができない場合は、すでにmake -j22つ以上のmakeコンパイラインスタンスがある可能性があります。これはRAMに同時に入ることができるコンパイラプロセスの数によって異なります。したがって、一般的な数字はありません。と。

その間に、より多くの仕事を持つことが役に立つかもしれません。各コンパイラプロセスは小さいですが、ビルド全体に大量のデータが含まれる場合、ディスクI / Oがブロック要因になる可能性があります。この場合、同時に実行されるCPUごとに複数のジョブが必要になるため、常に各CPUを使用する1つのジョブがあり、他のジョブはI / Oを待っています。繰り返しますが、これはビルド操作と利用可能なRAMによって大きく異なります。ここでは、データキャッシュに使用可能な項目によって異なります（作業が多すぎるとキャッシュを汚染しすぎる最適な値があります）。

ちょっとそうだと思います。経験的- プロセスmakeの開始を許可すると、CPUs + 1次のことが保証されます。

1. 完了したばかりのワーカープロセスとまだ実行されていないワーカープロセスとの間には間隔がありません。これは、実行キューを事前入力するのと同じです。
2. キューのプリフィルを実行してかなりのオーバーヘッドが発生するほど競合するプロセスはあまりありません。

ところでまたそれが言葉だ。経験的FreeBSDマニュアルはまだおすすめ make -j4単一CPUの場合。

通常、コア数よりも多くの作業を開始する理由があります。 gccを使用したCコンパイルの場合、-pipeがgccオプションで定義されていない場合は、一時ファイルを使用して操作（前処理、最初の実行、最適化、およびアセンブリ）を順次実行します。 -pipeはこれをサブプロセスパイプライン間で使用するように変更します。 （-pipeを追加するのはFreeBSDではデフォルトですが、Linuxではレガシーではありません。）したがって、2つのコアがあり、2つのタスクを並列に許可すると、ディスクI / Oに少し時間がかかります。 1 つのジョブを追加するよう提案することは、この詳細に関連しているようです。しかし、最終的な回答を得るには、誰がこの提案をいつ追加したのかを見つけて、彼に尋ねなければなりません。 ：）またはGentoo開発者メーリングリストに尋ねてください。

基本的に、この数字は著者が常識と呼ばれるものです。せいぜいこれは良い推測です。私が知っている限り、入力時に生成されたmakeプロセスはmakeすでに説明されているので、-j3他の2つのプロセスがコンパイルされている間にメインプロセスが待機する可能性があります。

しかし、Gentooを使用するときの経験則は<#cpus>*2 + 1。

すべては、チキントレイル、茶葉、またはどのディスクI / Oが発生するのか、および現在のLinuxカーネルのスケジュールを伝える魔法の8ボールによって異なります。 [この記事の中心的な始まり]私の個人的な経験によると（-jGentooに限定されていません）、＃cpus + 1と＃cpus * 2 + 1の間のすべてが良い結果をもたらします。 [この投稿のコアの終わり] 平均的にはほとんど気づかないでしょう。違い。今日のプロセッサとコアはとても良いです。

ただし、a）実際に複数のボックスを使用してコンパイルする（du'h）、b）独自のコードを開発する場合は、これらの変更がすべて適用されます。

属性が高い-jほど、以前に未知の依存関係を表示する可能性が高くなります。

注：コア数ではなく、CPUが占める同時ストリーム数を考慮してください。 （スーパータイトル！）