ブラックホール化(blackholing)とは、サンク(遅延された計算)に、評価中という印を付ける行為である。これは三つの理由で有用である。第一に、これによって、ある種の無限ループが検出(NonTermination例外)できる。第二に、ある種のスペースリークを避けることができる。第三に、並列プログラムにおいて一つの計算を繰り返し行うことを避けることができる。これは、計算が既に実行中である場合にそうと分かるからである。

-feager-blackholingオプションは、それぞれのサンクの評価が始まってすぐにそれをブラックホール化するようにする。デフォルトは「遅延ブラックホール化」であり、こちらでは、スレッドが何らかの理由で一時停止した場合にのみサンクに評価中の印が付けられる。遅延ブラックホール化において、大部分のサンクはブラックホール化される必要がないので、典型的にはこちらの方が効率的(1-2%程度)である。しかし、並列プログラムでは積極的ブラックホール化によってより多くの計算の繰り返しを防ぐことができ、これが実際並列性にとって重要である場合がよくある。

我々は、並列に走ることを意図したコードは何でも-feager-blackholing付きでコンパイルすることを推奨する。

プログラムの実行中、同時にx個のスレッドを使う。通常、xは機械のCPUコア数と一致するべきである^[9]。例えば、デュアルコアの機械ではおそらく+RTS -N2 -RTSを使うことになるだろう。

xを省略する、つまり+RTS -N -RTSとすると、マシンにあるプロセッサの数に基いてランタイムが自分で値を決定する。

マシンの全てのプロセッサを使う時には注意すること。もし他のプログラムがプロセッサをいくつか使っているなら、これによってパフォーマンスを改善するどころか悪影響になることがある。

-Nを設定することには、並列ガベッジコレクタを有効にするという効果もある(4.16.3. ガベッジコレクタを制御するためのRTSオプションを見よ)。

プログラムが開始した後にこの値を変更する方法は(今のところ)ない。

現在の-Nオプションの値は、GHC.Conc.numCapabilitiesでHaskellプログラムから得られる。

OSのaffinity(親和性)機能を使ってOSスレッドをCPUコアに固定する。これは実験的な機能であり、有用かもしれないしそうでないかもしれない。役に立ったかどうか知らせてね！

負荷分散のための自動移住を無効にする。通常ランタイムは、暇なCPUを活用するため、CPUをまたいでスレッドをスケジュールしようとする。このオプションはこの振る舞いを無効にするものである。移住はスレッドにしか適用されないことに注意。parによって作られたスパークは、別途work-stealingによって負荷分散される。

このオプションが役に立つのは、おそらく、並行プログラムで、GHC.Conc.forkOnIOを使ってスレッドを明示的にCPUにスケジュールする場合だけだろう。

スレッドが目覚めたとき、それを現在のCPUに移住させる。通常、スレッドがブロックしていて目覚めた場合、最後に走っていたCPUに割り振られる。このオプションによって、スレッドがブロックを解いたCPUに即座に移住できるようになる。

この積極的な移住を可能にする根拠となるのは、これによって相互に連絡し合うスレッドが同じCPUに集められる傾向があることである。しかし、これが悪い戦略になるような病理的な例が存在する。プログラム中の連絡パターンによって、これは良案になるかもしれず、そうでないかもしれない。