GHC 7.0.x―7.2.1 現在のスレッド実装について
forkOnIO 関数とどう違うの?と思う方向けの補足: GHC.Conc モジュールの forkOnIO 関数 [http://j.mp/fNglNF ] を forkOn 関数という名前に変更して、Control.Concurrent で公開するよう変更しました。
2011-03-30 22:03:47注意:forkOn(IO) はあくまでユーザースレッドを実行する CPU のアフィニティを指定する機能です。スレッド固有データ(TSD:thread-specific data)などネイティブ・スレッドを要求する機能を利用したい場合には、forkOn(IO) ではなく forkOS を使って下さい。 http://itpro.nikkeibp.co.jp/article/COLUMN/20081006/316216/?ST=ittrend&P=2 http://www.haskell.org/ghc/docs/7.2.1/html/libraries/base-4.4.0.0/Control-Concurrent.html#v:forkOS
あと、threadCapability 関数 [http://j.mp/eVypmK ] や getNumCapabilities 関数[http://j.mp/dRk4rT ] も Control.Concurrent モジュールから公開するよう変更されました。
2011-03-30 22:09:12threadCapability 関数の説明
GHC Currentに、forkIOなどで作成したスレッドが、どの HEC (ネイティブスレッド)で実行されているか、実行HECが固定されているかどうか、を出力するためのthreadCapability関数が追加されました。 http://bit.ly/eUdHF7
2011-03-02 12:38:32forkIO ではなく forkOnIO を利用してスレッドを作成した場合、作成されたスレッドは特定の HEC に固定されて実行されることになるので、この場合に threadCapability は (x::Int,True)を返すというわけですね。
2011-03-02 12:52:15c.f. http://bit.ly/fdeNyV http://bit.ly/dKl033 http://bit.ly/e2Y51h http://bit.ly/eUdHF7
2011-03-02 12:55:09getNumCapabilities 関数の説明
GHC Current で、GHC.Conc モジュールに numCapabilitie の IO 版の getNumCapabilities が加わりました。 http://j.mp/egemFj
2011-02-03 20:59:49コメントにもあるように、getNumCapabilitie を加えたのは、いずれ Haskell プログラムを動かす CPU 数(capability)を、RTS の -N<x> オプションではなく、Haskell プログラム上で与えられるようにすることを考えてことみたいですね。
2011-02-03 21:05:07プログラムを実行する CPU コア数が固定な現在の実装なら、必ず同じ答えが返ってくるので numCapabilitie でも何も問題はないのですが、実行中に使用 CPU コア数が変化するとなると IO で値を返さないと不適当になるので。 http://j.mp/b1PC0u
2011-02-03 21:08:29I/O manager の実装
new IO manager を使うのに -threaded が必要なのは、-threaded RTS は old IO manager を持っていたけど、non-threaded RTS にはそんなものがない(単なるイベントループしかない)からだそうです。
2011-07-19 15:55:38@tanakh さっき select でソースコードを検索したら、readRawBufferPtr のコメントで threaded モードでない場合に(safe な FFI の呼び出しのために) select を呼ぶと書いてありました。 http://bit.ly/b0LZAZ
2010-09-29 00:03:43さっきのコメントが気になって、ちょっと RTS に潜ってみました。 http://twitter.com/shelarcy/status/25792565720 http://bit.ly/b0LZAZ
2010-09-29 00:24:33rts/posix/Select.c に threaded でない RTS での I/O 処理を(select 関数を使って)管理するための関数が定義されているのですが、その定義全体が !defined(THREADED_RTS) に囲まれていて、
2010-09-29 00:27:17コメントに「threaded RTS では、GHC.Conc モジュールで提供される I/O Manager を使って I/O 処理を管理する」という旨のことが書かれていますね。 http://bit.ly/d9OPQU
2010-09-29 00:30:18@repeatedly そのドキュメントは GHC 6.12.x までのですね。loop 自体は確かにそんな感じですが、実装はちゃんとリストじゃなくて優先度つきキューになってます。 http://j.mp/opSxZL http://j.mp/oeUiIA
2011-08-20 22:18:42注意: threaded な RTS では、select ではなく、epoll や kqueue などを適宜利用する実装になっています。 http://www.haskell.org/ghc/docs/7.2.1/html/libraries/base-4.4.0.0/src/GHC-Event-Manager.html http://www.haskell.org/ghc/docs/7.2.1/html/libraries/base-4.4.0.0/src/GHC-Event-EPoll.html http://www.haskell.org/ghc/docs/7.2.1/html/libraries/base-4.4.0.0/src/GHC-Event-KQueue.html
なお、threaded な RTS での I/O manager の実装については、"Scalable I/O Event Handling for GHC" という論文で詳しく説明されています。 http://research.google.com/pubs/pub36841.html
threaded な RTS と threaded でない(non-threaded な) RTS での TVar や MVar の実装の違い
@kazu_yamamoto いや、単一コアか複数コアかに関係なく遅いという話ですね。で、複数コアを使った場合には -threaded で性能向上が図れると期待するかもしれないけれど、実際にはそうではないかもしれないという話です。
2011-03-28 17:42:59@kazu_yamamoto はい。-threaded STM では TVar が複数のネイティブスレッド上で使用される可能性があるので内部的にはロックをかける実装になっているのに対し、
2011-03-28 17:59:32