私は現在、マルチスレッド アプリケーションがうまくスケーリングできない理由を考えています。
私が認識しており、私が戦ってきた2つの理由は次のとおりです。
- スレッド間の通信がうまくいかず、速度が遅くなる
- チップ上のコア数と CPU へのメモリ帯域幅は比例して増加しません。これは、チップ上のより多くのコアが頻繁に使用されるほど、コアあたりのメモリ帯域幅が遅くなることにつながります。
他にどんな問題がありますか?
私は現在、マルチスレッド アプリケーションがうまくスケーリングできない理由を考えています。
私が認識しており、私が戦ってきた2つの理由は次のとおりです。
他にどんな問題がありますか?
ポイント1)の場合、必ずしも「うまく機能していない」とは限りませんが、ほとんどの場合、プロセス/スレッドが互いに待機しなければならないクリティカルセクションがあります。たとえば、いくつかのクリティカルデータを更新します。これはアムダールの法則によってよく説明されています。
追加したいもう1つのポイントは、タスク自体のスケーラビリティです。タスク(入力)がスケーラブルでない場合、処理能力(コア/スレッド)を増やしても全体のスループットを向上させることはできません。たとえば、アプリケーションはデータフローを処理することですが、同じフローからのデータパケットを並列に処理できないという制約があり(順序の考慮により)、スケーラビリティはフローの数によって制限されます。
さらに、O(1)アルゴリズムとO(n)アルゴリズムの違いを考慮すると、アルゴリズムのスケーラビリティはさらに基本的です。もちろん、ここでのトピックは、データサイズではなく、処理能力のスケーラビリティに焦点を当てているかもしれません。
(1)では、マルチスレッドアプリのパフォーマンスに悪影響を与える可能性のある最も重要な要素の1つを突き止めたと思います。Esp。「偽共有」のためのグーグル。
(2)ただし、マルチスレッドアプリのセット(CPUバウンドスレッドを並行して実行するアプリ)にのみ影響します。アプリがI/Oバウンドのスレッドを多数使用する場合、(2)はそれほど重要ではありません。
ここで私のボックスを見ると、100個のプロセスと1403個のスレッドがあり、CPUは3%を使用しています。100個のプロセスのうち7個だけがシングルスレッドです。したがって、ほとんどのアプリはマルチスレッドですが、I/Oは待機しています。
私のボックスは、コアが1つしかない場合、現時点ではかなりうまく機能します。確かに、私のブラウザを巻き上げるリンクを押すと、複雑なページを表示するのに少し時間がかかるかもしれませんが、それほどではありません。
プリエンプティブマルチタスカーの高いI/Oパフォーマンスを利用するためにアプリがマルチスレッド化されている最も一般的なケースでは、アプリはシングルコアCPUでも非常に適切に拡張できます。
プリエンプティブマルチタスクOSはすべて「CPUバウンドタスクを並行して実行する」ことであると考えないようにしてください。実際には、ロック、同期、シグナリングなどの必要性を強制することで、これを困難にしています。 I / O、協調スケジューラーが見事に苦手なこと。
多くのマルチスレッドアプリケーションは、「1ユーザー1スレッド」の概念に基づいて構築されています。つまり、ユーザーまたは雑用を処理する必要がある場合は、スレッドがタスクに割り当てられます。スレッドが増えるたびに、スケジューラの負荷が増加し、この時点でどのスレッドを実行するかを決定するためにすべての処理が実行されるようになります。これを「スケジューラー飽和」と呼びます。
Windows(95/98 / Meなどではなくマルチスレッドエンジン)には、最高のパフォーマンスを得るためにプロセッサごとに1つのスレッドを推奨するI/O完了ポートと呼ばれるメカニズムがあります。IOCPベースのアプリケーションは通常、非常に高速ですが、いつものように、ボトルネックは、特定の種類のOSメモリの不足や通信メディアの待機など、他の場所で発生します。
ここSOでIOCPを検索できます。これには、独自のタグがあります。