GNU make のジョブ数がコア数と等しいかどうか、または他のジョブが「動作」している間にキューに入れることができるジョブを 1 つ追加することでビルド時間を最適化できるかどうかについて、いくつかの論争があるようです。 .
クアッドコアシステムで使用する方が良いです-j4か?-j5
どちらかをサポートするベンチマークを見た (または行った) ことはありますか?
質問する
68796 次
10 に答える
60
ハイパースレッディング ラップトップを搭載した 4 コアでホーム プロジェクトを実行し、結果を記録しました。これはかなりコンパイラーが重いプロジェクトですが、最後に 17.7 秒の単体テストが含まれています。コンパイルは IO 集中型ではありません。利用可能なメモリは非常に多く、そうでない場合でも残りは高速な SSD にあります。
1 job real 2m27.929s user 2m11.352s sys 0m11.964s
2 jobs real 1m22.901s user 2m13.800s sys 0m9.532s
3 jobs real 1m6.434s user 2m29.024s sys 0m10.532s
4 jobs real 0m59.847s user 2m50.336s sys 0m12.656s
5 jobs real 0m58.657s user 3m24.384s sys 0m14.112s
6 jobs real 0m57.100s user 3m51.776s sys 0m16.128s
7 jobs real 0m56.304s user 4m15.500s sys 0m16.992s
8 jobs real 0m53.513s user 4m38.456s sys 0m17.724s
9 jobs real 0m53.371s user 4m37.344s sys 0m17.676s
10 jobs real 0m53.350s user 4m37.384s sys 0m17.752s
11 jobs real 0m53.834s user 4m43.644s sys 0m18.568s
12 jobs real 0m52.187s user 4m32.400s sys 0m17.476s
13 jobs real 0m53.834s user 4m40.900s sys 0m17.660s
14 jobs real 0m53.901s user 4m37.076s sys 0m17.408s
15 jobs real 0m55.975s user 4m43.588s sys 0m18.504s
16 jobs real 0m53.764s user 4m40.856s sys 0m18.244s
inf jobs real 0m51.812s user 4m21.200s sys 0m16.812s
基本的な結果:
- コア数にスケーリングすると、パフォーマンスがほぼ直線的に向上します。リアルタイムは 2.5 分から 1.0 分 (2.5 倍) に短縮されましたが、コンパイルにかかる時間は 2.11 分から 2.50 分に増加しました。システムは、このビットで追加の負荷をほとんど認識しませんでした。
- コア数からスレッド数にスケーリングすると、ユーザー負荷が 2.50 分から 4.38 分に大幅に増加しました。このほぼ 2 倍になるのは、他のコンパイラ インスタンスが同じ CPU リソースを同時に使用しようとしたためである可能性が最も高いです。システムは要求とタスクの切り替えで少し負荷がかかり、使用時間は 17.7 秒になります。利点は、コンパイル時間 53.5 秒で約 6.5 秒であり、12% のスピードアップになります。
- スレッド カウントから 2 倍のスレッド カウントにスケーリングしても、大幅な速度向上は見られませんでした。12 と 15 の時間は、無視できる統計的異常である可能性が最も高いです。かかる合計時間は、システム時間と同様にわずかに増加します。どちらも、タスク切り替えの増加が原因である可能性が最も高いです。これには何のメリットもありません。
今の私の推測では、コンピューターで何か他のことをする場合は、コア数を使用してください。そうでない場合は、スレッド数を使用してください。それを超えると何のメリットもありません。ある時点で、メモリが制限されて崩壊し、コンパイルが大幅に遅くなります。「inf」行が追加されたのはかなり後になってからで、8+ のジョブにサーマル スロットリングがあったのではないかと疑っています。これは、このプロジェクト サイズでは、メモリまたはスループットの制限が有効でないことを示しています。ただし、コンパイルするメモリが 8 GB であることを考えると、これは小さなプロジェクトです。
于 2013-09-17T15:01:08.107 に答える
60
最善の方法は、特定の環境とワークロードで自分自身をベンチマークすることです。フリーサイズの答えを得るには、あまりにも多くの変数 (ソース ファイルのサイズ/数、使用可能なメモリ、ディスク キャッシング、ソース ディレクトリとシステム ヘッダーが異なるディスク上にあるかどうかなど) があるようです。
私の個人的な経験 (2 コアの MacBook Pro で) では、-j2 は -j1 よりも大幅に高速ですが、それ以上 (-j3、-j4 など) では測定可能な速度向上はありません。したがって、私の環境では、「ジョブ==コア数」が良い答えのようです。(YMMV)
于 2010-03-23T11:53:47.613 に答える
31
個人的にはmake -j n、n は「コア数」+1 を使用します。
ただし、科学的な説明はできません。多くの人が同じ設定を使用しているのを見てきましたが、これまでのところかなり良い結果が得られています。
--jobsいずれにせよ、いくつかのメイクチェーンはオプションと互換性がなく、予期しない結果につながる可能性があるため、注意する必要があります。奇妙な依存エラーが発生している場合は、makeなしで試してみてください--jobs。
于 2010-03-23T14:46:07.990 に答える
7
最終的には、ビルドに使用するのに最適な数を決定するためにいくつかのベンチマークを実行する必要がありますが、重要なリソースはCPUだけではないことを忘れないでください。
たとえば、ディスクに大きく依存するビルドがある場合、マルチコアシステムで多くのジョブを生成するのは実際には遅くなる可能性があります。これは、ディスクがすべてを提供するためにディスクヘッドを前後に移動する余分な作業を行う必要があるためです。さまざまなジョブ（OSがディスクキャッシュをどの程度適切に処理するか、ディスクによるネイティブコマンドキューイングのサポートなど、多くの要因によって異なります）。
そして、ハイパースレッディングに対して「実際の」コアがあります。ハイパースレッドごとにジョブを生成することでメリットが得られる場合と得られない場合があります。繰り返しになりますが、調べるにはベンチマークを行う必要があります。
特に#cores+1を試したとは言えませんが、私たちのシステム（Intel i7 940、4つのハイパースレッドコア、大量のRAM、VelociRaptorドライブ）とビルド（CPUとIを交互に使用する大規模なC ++ビルド）で/ Oバウンド）-j4と-j8の間にほとんど違いはありません。（おそらく15％優れていますが、2倍近くはありません。）
昼食に出かける場合は-j8を使用しますが、システムの構築中に他の目的でシステムを使用する場合は、より低い数値を使用します。:)
于 2010-03-23T19:12:14.137 に答える
5
Foxconn M/B と 4GB の G-Skill メモリを搭載した Athlon II X2 Regor proc を入手しました。
'cat /proc/cpuinfo' と 'free' を最後に追加して、他の人が私の仕様を確認できるようにします。4GBのRAMを搭載したデュアルコアのAthlon II x2です。
uname -a on default slackware 14.0 kernel is 3.2.45.
次のステップのカーネル ソース (linux-3.2.46) を /archive4 にダウンロードしました。
抽出した ( tar -xjvf linux-3.2.46.tar.bz2);
ディレクトリに cd しました ( cd linux-3.2.46);
cp /usr/src/linux/.config .デフォルトのカーネルの構成を ( )にコピーしました。
make oldconfig3.2.46 カーネル構成を準備するために使用されます。
次に、-jX のさまざまな呪文を使って make を実行しました。
time コマンドの後に make を発行して、各実行のタイミングをテストしました。たとえば、'time make -j2' です。各実行の間に、linux-3.2.46ツリーを「rm -rf」して再抽出し、デフォルトの/usr/src/linux/.configをディレクトリにコピーし、make oldconfigを実行してから、「make -jX」テストを再度実行しました.
プレーンな「メイク」：
real 51m47.510s
user 47m52.228s
sys 3m44.985s
bob@Moses:/archive4/linux-3.2.46$
上記と同じですが、make -j2 を使用します
real 27m3.194s
user 48m5.135s
sys 3m39.431s
bob@Moses:/archive4/linux-3.2.46$
上記と同じですが、make -j3 を使用します
real 27m30.203s
user 48m43.821s
sys 3m42.309s
bob@Moses:/archive4/linux-3.2.46$
上記と同じですが、make -j4 を使用します
real 27m32.023s
user 49m18.328s
sys 3m43.765s
bob@Moses:/archive4/linux-3.2.46$
上記と同じですが、make -j8 を使用します
real 28m28.112s
user 50m34.445s
sys 3m49.877s
bob@Moses:/archive4/linux-3.2.46$
「cat /proc/cpuinfo」の結果:
bob@Moses:/archive4$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 6
model name : AMD Athlon(tm) II X2 270 Processor
stepping : 3
microcode : 0x10000c8
cpu MHz : 3399.957
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmo
v pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rd
tscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 p
opcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowpre
fetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips : 6799.91
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
processor : 1
vendor_id : AuthenticAMD
cpu family : 16
model : 6
model name : AMD Athlon(tm) II X2 270 Processor
stepping : 3
microcode : 0x10000c8
cpu MHz : 3399.957
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmo
v pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rd
tscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 p
opcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowpre
fetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips : 6799.94
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
「無料」利回り:
bob@Moses:/archive4$ free
total used free shared buffers cached
Mem: 3991304 3834564 156740 0 519220 2515308
于 2013-07-13T04:42:49.743 に答える
3
参照として：
LKDSpawning Multiple Build Jobsのセクションから:
n は生成するジョブの数です。通常は、プロセッサごとに 1 つまたは 2 つのジョブを生成します。たとえば、デュアル プロセッサ マシンでは、次のようにします。
$ make j4
于 2015-10-07T06:49:44.333 に答える
1
私の経験から、追加のジョブを追加するとパフォーマンスが向上するはずです。これは単純に、ディスク I/O が CPU 以外のボトルネックの 1 つだからです。ただし、追加ジョブの数はコア数や使用するディスクの種類と密接に関連しているため、決定するのは容易ではありません。
于 2012-07-20T05:26:37.603 に答える