マルチコアの時代になれば、当然のごとく多重実行をいかにうまくやるか、というのがトレンドになってくる。しかしこれは非常に難しい。例えば、1995年の頃では、並列技術としては以下のような順序であっただろう。

1. OSサポートの始まった最先端、マルチスレッド。n:m対応がかぎ。


2. fork()によるマルチプロセス。オーバーヘッドも大きいので、prefork()


3. 旧態依然とした非同期実行select()

しかし、これは時代とともに揺れ動いている。例えば、昨今のトレンドはもう違っていて

1. C10K問題解決のための救世主、epollとかkqueueなどによる最先端非同期処理


2. 成熟に向かっているマルチスレッド。ただし、n-m対応はカーネルレベルよりライブラリレベルが主。


3. いまどきfork()

となって久しい。なにしろ最新の非同期技術は、ボトルネックをカーネルのソケット処理に押し込んでしまったので、もはやユーザレベルで出来るようなことはないに等しくなってしまった。

しかし、だ。最近出たGoogle chromeは、今時マルチプロセスモデルを採用する。他のブラウザが当然のようにマルチスレッドを使いこなすのに対して、だ。ブラウザのような場合は、性能面のオーバーヘッドはそれほどない。そして、プロセスが独立することによってサンドボックス化し、一部の影響を全体に及ぼさないようにしている。

そういえばIllustraがInformix Universal Serverになったときも、従来許されていたような関数がDataBlade内で使えなくなるなど、面倒な部分が目立ったものである。これもまた、マルチプロセスがマルチスレッドになることによる問題点である。おそらく性能面でプロセス＜＝スレッドなのはほぼ変わらないだろうが、使いやすさも考慮しないといけなくなりつつある。その点、おそらくRDBMS界隈では未だに旧態依然としたfork()を使っているPostgreSQLが有利なのだろうと思う。それがうまく生きるケースというのはなかなか見えてこないが。

おそらく商用のシステムなどの場合、OSのボトルネックの位置などを見越して、マルチスレッドとマルチプロセスの組み合わせなどということは頻繁にあるだろう。そのため組み合わせまで考慮し出すと大変なことになる。星の数ほどあるデザインの中で、適切なソリューションがなんなのかを考え続け、しかもその変化を見極めていかなければなぁ、とは思う。しかし、気を引き締めないと古い間違った意見にとらわれてしまいそうだ。