2007年1011

スレッドよりも軽く、スレッドよりも早く・・・

すばらしい記事が上がっている。naoyaのはてなダイアリー - マルチスレッドのコンテキスト切り替えに伴うコスト

要約すると切り替えコストがプロセス>スレッドなので、スレッドの方がプロセスよりも高速ですよ。という事。

個人的な経験から、これをさらに加速すると、莫大な処理量を持つ基幹サーバーの場合、スレッドの切り替えコストすら、処理量が多いと甚大になるので支払いたくなくなる。



そこで、ジョブ<>タスクシステムをスレッドに組み込み、なるべく1つのスレッドが複数のジョブを実行できる様にし、1つのスレッドが長時間無停止でCPUを可能な限り選挙し続ける、CPUの血の一滴までOSではなくアプリで使い切るシステムが必要になる。

そうすると自動的に、プログラムはイベントドリブンな非同期プログラムを書くことになっていく。そうすると従来のread,write,select,pollなIOではIOレベルで非同期の品質が高くないのでWindowsのオーバーラップ IOなどの出番となっていく。

もし、あなたが、スレッドのコンテキスト切り替えのコストすら切り詰めなければならないような、超大規模、超高速システムを作ることになった場合、非同期、イベントドリブン、スレッド数をCPUのコア数に可能な限り近づける(コア数以下では意味がないのでせいぜい2倍程度が目安か?)、Windowsのオーバーラップ IOのような高速な非同期IOを使う といったキーワードを覚えておくと、うまく設計できるのではないかと思う。

また、WindowsのオーバーラップIOにはマニュアルにはないが、命名規則から推測すると呼べる関数がいくつか存在しているはずである。もうマニュアル整備されたかもしれないけど・・・
それらをつかうと、TCPのコネクションにおいて、Connect関数なども全て非同期にできるのでSYNだけを送るという事が出来TCPレベルでの通信速度や、同時接続数などはものすごく改善される。

まぁ、バッドノウハウですけど・・・

あくまでも、C,C++を長くやってきた物の経験則上なんですけどね。

参考

Schi Heil と叫ぶために - プロセス、スレッド、ファイバ、タスク、ジョブ、違いを整理してみよう

Windows オーバーラップ IO - Google 検索

関連するエントリ一覧

関連するタグ

その他






トラックバック

このエントリーのトラックバックURL:



コメント

コメント一覧

心は萌え(管理人)(--)『

お気軽にコメント下さい。ただし、基本的に読んではいますが、お返事はほとんどしません。お返事が必要な方はTOPページにあるメールアドレスへメールを送って下さい。

 

ymikasa : 2007年10月11日 21:17『

日本では、えらくマイナーですが、
stackless pythonのLightweight Threadなんてどうですか?
http://members.verizon.net/olsongt/stackless/why_stackless.html#lightweight-threads

自分でスケジューラを回さないといけないので、めんどくさいですが、ネイティブスレッドと共存できればマルチコア時代にもマッチするかと。

 

心は萌え : 2007年10月11日 23:43『

>日本では、えらくマイナーですが

いや、この手の技法って、速度を究極まで追い求めるときの技法なので、直接メモリをさわれないLW系の言語ではそこまでしなくてもっと思います。

そもそも、メモリを直接さわれないウエイトの方がコンテキストスイッチングよりも遙かに重いので、それを許容するなら、コンテキストスイッチングも許容されてしかるべきかとー

アセンブリ、C,C++ぐらいでしか役に立たない技法だと思います。

 



コメントしてください




保存しますか?






このエントリーを含むはてなブックマーク

* 人気blogランキングこのサイトを投票
http://revilog.com/ TOPへ