forkOnを使用してスレッドを生成するプログラムしかないとします。このようなシナリオでは、異なる能力の間でHaskellスレッドの負荷分散はありません。だから+RTS -qmの有無にかかわらずこのプログラムを実行するのに違いはありますか？forkOnと-qm RTSフラグの関係は何ですか？
ドキュメントによれば、-qmはスレッドの移行を無効にします。これは、forkOnを使用するのと同様の効果があると私は思っています。私はこの前提で正しいですか？私はこの点について文書がどれほど明確ではないか確信しています。
私はこの分野の専門家ではありませんが、とにかくそれを撃つでしょう。
GHC（Haskellコンパイラ）は、1つまたは複数のHEC（Haskell Execution Context、capまたはcapabilityとも呼ばれます）を持つことができます。ランタイムフラグ+RTS -N <number>またはsetNumCapabilities機能を使用すると、プログラムで使用可能なHECの数を定義することができます。 1つのHECが1つのオペレーティングシステムスレッドです。ランタイムスケジューラは、HEC間でHaskell軽量スレッドを分配します。
forkOn機能では、スレッドが実行されたHECを選択することができます。 getNumCapabilitiesは、機能の数（HEC）を返します。
スレッド移行は、Haskellスレッドを別のHECに移行（移動）できることを意味します。ランタイムフラグ+RTS -qmは、このスレッドの移行を無効にします。
ドキュメントを約forkOnその
forkIOなどを述べていますが、スレッドが実行すべき機能に指定することができます。 forkOnスレッドとは異なり、forkOnによって作成されたスレッドは、その存続期間全体にわたって同じ機能を維持します（forkIOスレッドはスケジューリングポリシーに従って機能間を移行できます）。
のでforkOnと、それは1つのHECを選択することが可能ですスレッドがで走っている。
このスレッドによって行われた
外国呼び出しが行われることが保証されていないと述べている
forkIOと比較すると任意の特定のOSスレッドによって。特定のOSスレッドによって外部呼び出しが必要な場合は、代わりにforkOSを使用してください。
今、forkOnの機能と+RTS -qm（無効なスレッドの移行）は同じものですか？おそらくそうではありません。 forkOnを使用すると、ユーザーはHaskellスレッドが実行されているHECを明示的に選択します（たとえば、すべてのHaskellスレッドを同じHECに入れることが可能です）。 +RTS -qmとforkIOでHaskellのスレッドがのHECの切り替えはありませんが、HECはforkIOによって生成されたHaskellのスレッドがで終わるを知る方法はありません
参照を：。