最速TCPサーバーの件でちょっと分からないこと(解決)

epoll + fork 版サーバーは、予想通り thread 版を大きく 突き放すスコアをたたき出し、しかもまだCPU使用率には余力が残っていました。CPUを使い切れて いないのは、多分実験機のNICの Broadcom BCM5754 が複数コアに割り込みを分散する機能を もっていないためで、NICを増やしたり割り込み分散機能のあるNICを使えばもっと 差が広がると思います。

@mathaneさんはepoll+forkが最速になるだろうと予想していて、結果も予想通りになっているわけですが。Linuxカーネルからみるとネイティブスレッドもふつうのプロセスと同様にLWPと1:1対応しているわけでfork版とコンテキストスイッチのオーバーヘッドはそう変わらないはずだ。むしろ別プロセスをコンテキストスイッチする方が仮想メモリ空間の切り替えの分だけ重そうだから、僕の知識の範囲ではthread版の方が速いはずである。でもそうなってなくてfork版の方が20%ほどスループットが高いし、それが当然の結果みたいだ。どうしてだろう?プロセスとスレッドではスケジューリングアルゴリズムが違うのかな。

追記

@koieさんが教えてくれたのですが、workerスレッドを事前に120コ立ち上げてひたすらaccept-readするというループだからオーバーヘッドがすごいのでは?ということでした。ふーむ、それなら4スレッドくらいにしておいたらどうなるのでしょうかね。一方でepoll+forkの実験はプロセス2つ。どういうことだろう。threadモデルは今ひとつスループットが出なくてスレッドを増やしたらちょっとずつスループットが上がっていったというところか。だとしたらスレッドよりもプロセスが有利なのはどうしてだろう…?threadだとどこかで大きめのクリティカルセクションができてしまうからですかね(そんなこと言ってるうちに自分で調べろよ馬鹿という)。