マルチコアプログラミングは流行らない

最近、マルチコアを扱わなければならない局面が増えてきている。これは当然で、PCやゲーム機であってもマルチコアであるようなモデルが続々と出てきているのだから、プログラムを組むことも当然増えるし、コアも今後5年で64になるだとか128だとか言われている現状では、ますますその要請は増えるだろう。シングルスレッド性能は数年前からほとんど向上しておらず、今後の先行きも怪しいのだから仕方ない。
で、これってどうするんだろうという素朴な疑問が依然としてある。今後マルチコアのマシンに対してプログラムを組むというのは間違いない事実だけれど、それをどうやって組むのか、というのは決まった方向性があるわけではない。大きく分けて、4つの方針があると思う。
ひとつ目は、言語レベルでマルチコアをサポートするものだ。たとえばOpenMPをはじめとするようなインターフェースを持つ言語を用意する。これは現在多くの言語がスレッド動作しているわけで、その意味からすれば一番無難な方法にも思える。ただし、コア数が増えれば増えるほど、デッドロックなどの危険も伴うわけだから、そういうものを検知したりとか、あるいはクリティカルセクションの扱いというものの重要性は増えると考えられる。
二つ目は、自動並列化だ。これは、コンパイラが自動的に並列化できそうな部分を抽出して実行することになる。しかし、これには問題があって、そもそも自動並列化できる(自明並列性を持つ)部分というのは少ない、という研究結果が多く報告されているようだ。また、多少並列性を見つけたとしてもSIMDくらいならまだよいが、スレッド生成にはコストがかかるわけでそれに見合った最適化をかけれるのか、という問題もある。
三つ目は、ライブラリ整備だ。例えば行列演算のような時間がかかって、かつ並列化可能な処理をライブラリで呼び出すということになる。しかし、これにも問題がある。たとえばPerl。CPANみたいなでかいライブラリを集めている場所がある一方で、そこを使わない人たちもおそらくたくさんいる。というか、大半はおそらく他人が作ったライブラリとかは使わず、車輪を再発明していくというのが、今までの歴史だろう。プログラム言語自体の関数をマルチコア対応にしたところで、それは前述の自動並列化と全く同じ問題が発生する。
四つ目は、各コアに一つのプロセスを乗せる方法だ。これは単純で分かりやすいが、結局コア数よりも多くのプロセスを走らせないと意味がない。余ったコアが使われない以上、どうにもならない。
まあ、これらはどうせすべて同時に行われていくんだろうと思うけれど、しかし現状のプログラマがこれらを容易に扱うことは難しいだろう。そうなると、開発としてはマルチコアを扱える人と扱えない人の二つに分かれていく、という方針になるのではないだろうか。いや、ならざるを得ないのではないだろうか。しかし、これだけ不便なものを使って得られるもの、というのは意外と少ない。もちろん一部の分野では非常に助かるのだけれど、全体として助かる人たちというのは少数派だろう。
一部の人たちを除き、マルチコアを使いこなせる人達、というのはそれほど増えていくわけではない。そう思った。