計算に使用するコアの数 #coresまたは#cores -1?


12

私はやるべき大きな計算があります。すべてのコアを使用できますが、1つのコアを使用せずに使用しない理由はありますか?(計算CPUはIOなしのみ)。または、すべてのコアを利用しても、適切なコンテキストスイッチングを処理および実行することを知らないOSを過小評価していますか?


8
すべてのコアを活用することは良い出発点であり、「-1コア」でOSがより良く動作するという迷信はおそらく単なる迷信ですが、実際には、計算、ハードウェア、オペレーティングシステムに対する動作をプロファイルする必要があります。
Doc Brown

多くの場合、#cores + 1を使用することは非常に理にかなっています。#coresを使用するだけの場合、予期しないブロッキング(ページフォールトなど)により、コアが不必要に強制的にアイドル状態になります。
デビッドシュワルツ

回答:


28

主要なオペレーティングシステムは、使用可能なすべてのコアを使用するプロセスを処理する方法を知るのに十分なほど成熟しています。他のプロセスが影響を受ける可能性があります(多くの場合、影響を受けます)が、利用可能なすべてのコアを使用したため、計算が遅くなることはありません。

コアの数の選択は、計算の実行中に何か他のことをするという意図にさらに依存します。

デスクトップマシンで、計算の実行中にWebブラウザーを使用したり、ビデオを視聴したりする場合は、1つのコアを無料で使用することをお勧めします。同様に、サーバーが2つのことを実行している場合(計算を実行し、同時にそのメトリックを処理および報告するなど)、サイドタスクのためにコアを解放することをお勧めします。

一方、計算を可能な限り高速にすることを優先する場合は、すべてのコアを使用する必要があります。


7
限り、対話型プログラムも(許可された、近代的な肥大化したWebアプリケーションに問題があることができ、)CPUの多くを使用していないとして、高いCPU使用率がありますとき、現代のOSのスケジューラは、インタラクティブな対話型プログラムを保つに実際にはかなり良いです
James_pic

注:サーバー上であっても、sshで簡単に回答を取得できるようにする場合は、コア0をそのままにしておくと便利です。
マシューM.

11

場合によります。

マシンがこの計算専用である場合は、すべてのコアを使用する必要があります。未使用のコンピューティングリソースでは速度が向上しません

リアルタイムスケジューラ、非プリエンプティブスケジューラ、またはプロセッサアフィニティを使用している場合、他のプロセスをすべてのコンピューティングリソースから誤って枯渇させやすいため、もう少し注意が必要です。ただし、何か問題が発生した場合はこれらの設定を手動で変更する必要があるため、デフォルトではほとんどのOSで問題はありません。

マシンが計算専用でない場合、計算に100%を与えることは理想的ではないかもしれません。たとえば、計算の実行中にWebブラウザを使用している場合。マシンの負荷が100%を超えることがあるため、動きが鈍くなることがあります。計算のようなスループット指向のタスクは実際には遅くなりませんが、GUIのような遅延に敏感なタスクはそれほど速く反応しません。その場合、計算のためにNPROC-1スレッド/プロセスのみを開始するのが賢明です。あるいは、通常のタスクよりも低い計算の優先順位を明示的に使用すると、この問題を解決できます。この場合、計算ではリソースを無駄にしないためにNPROCプロセスを使用する必要があります。


3
「計算の実行中にWebブラウザーを使用している場合[…]遅く感じます。計算などのスループット指向のタスクは実際には遅くなりませんが、GUIのような遅延に敏感なタスクはすぐに反応しません。 ...]明示的にこの問題を解決することができ、通常のタスクよりも計算に低い優先順位を使用して」 -そして、それは、Unix上のプロセスの優先度の値が呼ばれている理由である『nice値』と名付けユーティリティを使用して構成されていますnice
ヨルグWミットタグ

2
技術的には、「未使用のコンピューティングリソースでは速度が向上しません」。より少ないコアを使用すると、クロックレートが高くなり、同期が低下する可能性があります。
-Davidmh

2
@Davidmhの注意に加えて、通常CPU側ではL1 $とL2 $はスレッド間である程度共有され、L3 $はすべてのソケットで共有されるため、より多くのスレッドを使用すると$ミスが増加し、プロセスが遅くなる可能性があります。特に、プロセスがプロセッサバウンドではなくメモリバウンドの場合。
マチェイピエチョトカ

スレッド/プロセスの優先度レベルを適切に設定すると、バックグラウンド作業が対話型プロセスに与える影響を緩和できます。私は10年以上にわたり、個人のコンピューターで分散コンピューティングアプリを実行しています。CPU計算タスクの優先度を低く設定すると、ブラウザーやその他の通常のデスクトップアプリを使用する能力が損なわれません。GPUでのリソース共有は高度ではなく、GPUコンピューティングをバックグラウンドで実行しているときに、GPUアクセラレーションHTML5ビデオ(ゲームを気にしない)で時々問題に遭遇しました。マルチスレッドゲームは、GFXが軽い場合でも問題が発生する可能性があります。飢えたスレッドに勝つ2+
ダンはFirelightによっていじる

1

私は彼の否定的な投票のために、以下の@motoDrizztに同意することについていくらか慎重です:)、それは実際に私の実際の経験です-実際のコアの数(数千ではなく)を超えても、より良いです。たとえば、http: //www.forkosh.com/images/avoronoi.gifを見てください。この3D-voronoi_diagramの各2D-planeは個別に生成できます。また、プログラムはnfork = n query_string属性を取り、n個のプレーンの計算を「同時に」分岐します。

4コアプロセッサでは、ダイアグラムを完了する(ユーザー)時間は、nforkでほぼ線形に減少し、約nfork = 8(4コアハイパースレッド)まで増加します。しかし、8を超えると、時間がより遅くなりますが、それでも時間が減少します。約16を超えると、それ以上の顕著な改善はありません。私はこの動作をまったく分析していませんが、OS(この場合はLinux Slackware 14.2x64)のプロセスを単純に調整して、全体的なアイドル時間をさらに短縮しました。


0

最良の選択はシステムに依存します。そのため、実際のシステムで両方のバージョンを実行し、システムがどのように応答するかを確認します。システム上でブラウザ、テキストエディタ、その他のものを引き続き使用できますか?また、n-1ではなくn個のスレッドを使用した場合のパフォーマンスは向上しますか?すべてのCPUを使用しようとする別のアプリと一緒にアプリを実行するとどうなりますか?

そして、ハイパースレッディングを検討する必要があります。4つのコアとハイパースレッディングにより、8コアまたは7コアを使用できます。繰り返しますが、システムの応答性と終了までの時間を試してください。

最後に、作業をスレッドよりも多くのブロックに分割することを検討してください。その理由は、異なるスレッドが異なる時間にジョブを終了するため、より高速なスレッドに渡すためにいくつかの作業を残しておく必要があるためです。そうしないと、最後のスレッドが終了するまで待つ必要があります。

PS。「ハイパースレッディングは、FPUが1つしかないため、FPUを集中的に使用するコードでは役に立たない」。絶対に間違っています。FPUを集中的に使用するコードであっても、レイテンシのためにFPUを最大限に活用することは非常に困難です。ハイパースレッディングは、スケジューリングに使用できる独立した操作が2倍あるため役立ちます。


-4

「悪い」とは思わない方法でこれを書く方法がわからないので、友好的な発言として受け取ってください。

通常、平均的なPCには既に1,000以上のスレッドがありますが、8対7を使用すると違いが生じると思われる理由は何ですか?:-)

できるだけ多くのスレッドを使用します。また、OSの応答を気にする必要がなく、スレッドが非常に長い時間(1秒以上)実行される場合は、2倍の数のコアを使用して実験することもできます。


3
しかし、これらの数千のスレッドのほとんどは100%CPUを使用していませんか?
アンドレアスレイブランド

1
2倍の数のコアを使用しても、一般的に計算時間は改善されません。実際、物理コアの数を超える数を使用することは、より多くの論理コアがある場合でも(ハイパースレッディングなどを使用します。ただし、実行しているタスクによって異なりますが)、一般的には有益ではありません。出典:MATLAB Parallel Processingを使用した過去の経験。
-Sanchises

1
@Sanchisesこれは、ハイパースレッディングが準並列命令インターリーブを活用しているためです-分岐が多くメモリが重いコードに効果的です。マトリックス計算は非常にFPUが激しく、物理コアごとにFPUが1つしかないため、ハイパースレッディングは役に立ちません。
J ...
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.