すばらしい記事が上がっている。naoyaのはてなダイアリー – マルチスレッドのコンテキスト切り替えに伴うコスト
要約すると切り替えコストがプロセス＞スレッドなので、スレッドの方がプロセスよりも高速ですよ。という事。
個人的な経験から、これをさらに加速すると、莫大な処理量を持つ基幹サーバーの場合、スレッドの切り替えコストすら、処理量が多いと甚大になるので支払いたくなくなる。
そこで、ジョブ＜＞タスクシステムをスレッドに組み込み、なるべく１つのスレッドが複数のジョブを実行できる様にし、１つのスレッドが長時間無停止でCPUを可能な限り選挙し続ける、CPUの血の一滴までOSではなくアプリで使い切るシステムが必要になる。
そうすると自動的に、プログラムはイベントドリブンな非同期プログラムを書くことになっていく。そうすると従来のread,write,select,pollなIOではIOレベルで非同期の品質が高くないのでWindowsのオーバーラップ IOなどの出番となっていく。
もし、あなたが、スレッドのコンテキスト切り替えのコストすら切り詰めなければならないような、超大規模、超高速システムを作ることになった場合、非同期、イベントドリブン、スレッド数をCPUのコア数に可能な限り近づける(コア数以下では意味がないのでせいぜい2倍程度が目安か？)、Windowsのオーバーラップ IOのような高速な非同期IOを使う といったキーワードを覚えておくと、うまく設計できるのではないかと思う。
また、WindowsのオーバーラップIOにはマニュアルにはないが、命名規則から推測すると呼べる関数がいくつか存在しているはずである。もうマニュアル整備されたかもしれないけど・・・
それらをつかうと、TCPのコネクションにおいて、Connect関数なども全て非同期にできるのでSYNだけを送るという事が出来TCPレベルでの通信速度や、同時接続数などはものすごく改善される。
まぁ、バッドノウハウですけど・・・
あくまでも、C,C++を長くやってきた物の経験則上なんですけどね。
日本では、えらくマイナーですが、
stackless pythonのLightweight Threadなんてどうですか?
http://members.verizon.net/olsongt/stackless/why_stackless.html#lightweight-threads
自分でスケジューラを回さないといけないので、めんどくさいですが、ネイティブスレッドと共存できればマルチコア時代にもマッチするかと。
＞日本では、えらくマイナーですが
いや、この手の技法って、速度を究極まで追い求めるときの技法なので、直接メモリをさわれないLW系の言語ではそこまでしなくてもっと思います。
そもそも、メモリを直接さわれないウエイトの方がコンテキストスイッチングよりも遙かに重いので、それを許容するなら、コンテキストスイッチングも許容されてしかるべきかとー
アセンブリ、C,C++ぐらいでしか役に立たない技法だと思います。