私は並行性と並列性に関する章である「Real World Haskell」の本を読んでいます。私の質問は次のとおりです。
Haskell スレッドは、実際には 1 つの「実際の」OS スレッド内の複数の「仮想」スレッドであるため、多数 (1000 など) 作成してもパフォーマンスに劇的な影響はありませんか? つまり、Haskell スレッドを作成することで発生するオーバーヘッドforkIOは (ほとんど) 無視できると言えますか? 可能であれば、実用的な例を持ってきてください。
軽量スレッドの概念が、マルチコア アーキテクチャの利点を利用する妨げになっていませんか? 私が理解しているように、2 つの Haskell スレッドを 2 つの別個のコアで同時に実行することはできません。これは、オペレーティング システムの観点からは、実際には 1 つのスレッドであるためです。それとも、Haskell ランタイムは、複数の CPU を確実に利用できるようにするための巧妙なトリックを行っているのでしょうか?
GHC のランタイムは、複数のハードウェア コアに分散される数十億のスパーク、数千の軽量スレッドをサポートする実行環境を提供します。-threadedフラグを使用してコンパイルし、+RTS -N4目的のコア数を設定します。
具体的には：
これは、多数 (1000 個など) 作成してもパフォーマンスに大きな影響がないということですか?
まあ、1,000,000 個を作成することは確かに可能です。1000は安すぎて出てこない。「スレッド リング」などのスレッド作成ベンチマークで、GHC が非常に優れていることがわかります。
軽量スレッドの概念が、マルチコア アーキテクチャの利点を利用する妨げになっていませんか?
全くない。GHC は2004 年からマルチコアで実行されています。マルチコア ランタイムの現在のステータスは、こちらで追跡されています。
それはどのように行うのですか？このアーキテクチャについて読むのに最適な場所は、論文「Runtime Support for Multicore Haskell」です。
GHC ランタイム システムは、物理 CPU ごとにおよそ 1 つずつ、少数のオペレーティング システム スレッドにそれらを多重化することにより、何百万もの軽量スレッドをサポートします。...
Haskell スレッドは、ワーカー スレッドと呼ばれる一連のオペレーティング システム スレッドによって実行されます。物理 CPU ごとにおよそ 1 つのワーカー スレッドを維持しますが、厳密にはどのワーカー スレッドかは刻々と変化する可能性があります ...
ワーカー スレッドは変更される可能性があるため、各 CPU に対して Haskell Execution Context (HEC) を 1 つだけ維持します。HEC は、Haskell スレッドを実行するために OS ワーカー スレッドが必要とするすべてのデータを含むデータ構造です。
作成中のスレッドとスレッドが実行されている場所を、threadscope を介して監視できます。. ここで、たとえば二分木ベンチマークを実行します。
Warp Web サーバーは、これらの軽量スレッドを広範囲に使用して、非常に優れたパフォーマンスを実現します。他の Haskell Web サーバーも競争を煽っていることに注意してください。これは、「Warp が優れている」というよりも「Haskell が優れている」という意味です。
Haskell は、軽量スレッドを複数のシステム スレッドに分散できるマルチスレッド ランタイムを提供します。4 コアまでは非常にうまく機能します。それを過ぎると、パフォーマンスの問題がいくつかありますが、それらは積極的に取り組んでいます.
1000 プロセスの作成は比較的軽量です。心配しないでください。パフォーマンスに関しては、ベンチマークするだけです。
前に指摘したように、複数のコアは問題なく動作します。複数の Haskell スレッドを、異なる OS スレッドでスケジュールすることにより、同時に実行できます。