マルチスレッドのボトルネックの話の行き着く先はkernelとhardwareだろう
以下、眠い頭の与太話なので、気にしないでください。
非同期IOとかマルチスレッドとかいうけれど、資源配分を実際にやってるのはkernelそしてhardwareなので、そこがスケールしないところまでは行けない。
CPUが何個あるか、CPUのタスクスイッチがどれくらい重いか、スケジュールの負荷は、メモリのバンド幅は、ネットワークのhardwareのバッファの構造は、、そういう議論抜きで話が進行しちゃうというのは、要するにその上のスタックが重過ぎるということなんだろうか。
今なら、スーパーコンピュータを手作りできちゃう時代だ。IOのあるデバイスをFPGAとかで作るのはノウハウがいるのかもしれないが、バッファのロジックを書くことはできるだろう。いいたいことは、100万接続をバッファできるport80をもったネットワークカードを作ることはそんなに難しいことなのだろうか？ということ。ちうか、ロードバランサをできるだけハードウェアで実装しようとしたらそうなる。（最近経営が傾いたNortel製のスイッチは、設計がHW寄りだという話も聞いたことがある気がする＜あやふや）。100万円以下の機器だって、数万コネクションの同時接続は「仕様上は」サポートしてるはずだ。
一方、極端な話、サービスをP2Pにすると、C10K自体が起こりづらくなる。全世界の人と6hopでつながるなら、6G^(1/6)=42で、1つのノードは50個もコネクションがあればいい（笑←処理の「余分な」遅延は6倍だが、ネットワークの遅延と比べてどうかな。
つーわけで、こういう話は「今、これが問題だ」→「解決したから問題ではない」のいたちごっこになりがちだ
というわけで、限り有る私の脳みそでは深追いはしない。
一つ一つの問題を解決してくださった方々に深く敬意を表し、これから解決しようという人々にエールを送るのみ。
inspired by(=respect to)
追記：並列処理にとって本質的にヤバイ問題はあると思う。それは逐次処理だ（笑
何がヤバイのか。それは、ロックの問題だと思う。解決しようとしている問題が、実はserialである場合だ。
デッドロックも、資源を共有しているだけでなく、獲得の「順番」が問題になる。
なぜ共有メモリが必要かって、それは逐次処理を保証しないといけないからだ。
つまり、共有メモリが必要だとか、ロックの粒度が、メッセージのやり取りが、、ということになったら、あなたの抱えている問題は、pureな並列処理ではなくて、合理的なスケジューリングなのだ、と思う。
何が合理的か、と言えば「満たすべき制約をminimumにすること」かもしれない。
そういう意味では以下の記事を読み返したい今日この頃＜読めよ
