マイクロプロセッサの性能向上には、大きく分けて2通りがある。既存のアプリケーションがそのまま高速化するものと、そうでないものだ。前者の代表的な例は、動作クロックの引き上げや、キャッシュやバッファの増量、あるいは内部アーキテクチャの見直しによるIPC(1サイクルあたりに実行可能な命令数)の引き上げなどだ。後者の例としては、命令セットの拡張や新命令セットの追加が上げられる。ただし、上に記した前者の例は3つとも限界に近づきつつあり、特にクロックの引き上げによる性能の改善(従来のプロセッサにおける性能改善の主力)は、あまり期待できなくなっている。

　現在話題になっているプロセッサのマルチコア/メニーコア化は、今のところ後者(既存のアプリケーションはあまり高速化しない)だが、それを前者に置き換えようとIntelは考えている。それが実現すれば、将来コアを増やすことで、従来のプロセッサでクロックを引き上げてきたのと同じ効果が得られる。そのための努力の表れの1つが、先週開かれたソフトウェア・カンファレンスである。カンファレンスでは、今後作成されるアプリケーション(バイナリ)を、将来のマルチコア/メニーコアプロセッサに対応可能なものにすること、アプリケーションをコアに対してスケーラブルにすることが力説された。

　マルチコア/メニーコアに限らず、将来登場するプロセッサ技術(上で言う後者)に対応可能なアプリケーションの形態は4種類が考えられる。1つは、現在作成しているアプリケーションを、将来のプロセッサに採用される技術を踏まえたものにしておくことで、高速な実行を実現することだ。これが最も望ましいが、どこまで将来登場する技術を正確に予見できるか、あるいは将来登場する技術がどのくらい現在の見込み通りに製品化できるか、将来の技術に対応することで現在のプロセッサでの実行時に不利にならないか、将来の技術に対応することがプログラマーの現時点における負担にならないか、といったあたりが課題となる。

　2番目は、アプリケーションのバイナリとは別のランタイムライブラリ等を更新することで、将来登場する技術の利点を現在のアプリケーションで利用可能にしようという考えだ。ランタイムライブラリは単体で配布されることもあるし、将来のOSが標準で搭載してくるかもしれない。アプリケーションのバイナリを変えなくて済むという利点があるものの、ライブラリの対応だけでは済まない部分がでてくるかもしれない。基本的には1に準じるが、将来、一部を差し替えできるという点がミソだ。

　3番目は、ソースコードをほとんどそのまま、新しいコンパイラとライブラリで再コンパイルするだけ、というもの。そして4番目が、新しい技術に合わせて、ソースコードを書き換え、最新のコンパイラとライブラリでコンパイルする、という方法である。

　これら4つのうち、一般のPC向けで有効なのは最初と2番目の方法だ。言い替えれば、一般向けには、ユーザーの手元にあるバイナリはそのままで、新しい技術に対応できなければならない。そうでないと、技術の普及にあまりにも多くの時間がかかり、プロセッサメーカーとしては「お金をとれる」技術にはならないからだ。

　この10月22日で、ついにWindows XPをプリインストールしたPCの出荷が停止される。最初のWindows XPがリリースされたのが2001年10月(日本語版は翌月)、最後のリリースとなったWindows XP SP3のリリースが2008年7月だから、最初のリリースから数えて9年、SP3のリリースから数えて2年と3カ月ということになる。もちろん、今Windows XPプリインストールマシンを買おうという人は、少なくともあと3年くらいは使うだろうし、マイクロソフトのサポート期限は2014年だから、Windows XPは10年を優に超えて使われることになる。実際、現在のインストールベースのシェアで、Windows XPは6割を大きく超えるとされる。インストールベースでWindows 7がWindows XPのシェアを超えるのは、まだまだ先のことだ。

　Windowsはもちろんのこと、一般のPCにおいてユーザーが利用するソフトウェアは、ほとんどがバイナリで配布されている。1度広まったバイナリは、このWindows XPに限らず、とても長い寿命を持つ。多くの人は、今使っているソフトウェアで不都合がなければ、それを更新することはしない。更新することには、既知のバグフィックス、性能改善、機能向上といったメリットがある反面、新しい未知のバグとの遭遇、必要としない機能の増加、自分が必要としていた機能の消失、望まないユーザーインターフェイスの変更、そしてアップデートフィーの発生といったデメリットが潜んでいるからだ。

　将来登場する技術が、既存のバイナリを高速化しないものだとすると、それがどんなに良いものであっても、そのままでは新しい技術に対応したバイナリが古いバイナリを置き換えるのに10年ほどの時間がかかる。ようやく量販店の店頭に並ぶPCで、64bit版のWindows 7をプリインストールしたものが増えてきたが、x64が発表されたのは2000年、最初の製品がリリースされたのが2003年である。現在のWindows 7のインストールベースが20%弱で、x64版が半分だとしても、その普及度は10%未満に過ぎない。大半のユーザーがx64を使うようになるには、おそらくまだ5年以上かかるだろう。32bit化(Windows NTによるWindows 9xの置き換え)にも、やはり10年以上の歳月が必要だった。

タスク並列の記述を容易に行なうことができるCilk Plusだが、データ並列にも対応する

　おそらくIntelもこれが分かっているからこそ、ソフトウェアに投資し、ソフトウェア開発者向けのイベントを開いて、少しでもこの時間を短縮しようとしているわけだ。先週開かれた「インテル ソフトウェア・カンファレンス2010」で紹介された「Cilk」が興味深かったのは、たった3つのキーワードだけで、並列処理が記述できる点にある。アプリケーション開発者の負担を極限まで減らしつつ、将来のマルチコア/メニーコアへの対応を可能にするというのは、先行してバイナリを置き換えておくのに不可欠な資質であり、一般PC向けアプリケーションを意識した正しいアプローチではないかと思う。

　これまでの並列プログラミングは、あまりにローレベルなため、対応することによりプログラミングとデバッグに関する負担が大きくなりすぎた。ユーザーが対話的に扱うアプリケーションは、並列処理の効果が疑わしいことが多い上、ハードウェアにもまだシングルコア製品を用いたものが多数残っている(インストールベース)。Cilkくらい簡潔になれば、一般向けアプリケーションでも並列処理を行なおうという開発者が出てくるかもしれない。

　一方、この一般PC向けとは、全く異なるアプローチの世界も存在する。それはHPCの世界だ。HPCの世界では、特にハイエンドに近づくほど、アプリケーションは基本的にソースコードで流通する。そして、ユーザー自身が、利用するハードウェアに対するアプリケーションの最適化を行なう。時には、その最適化そのものが、ユーザーの研究対象であったりもする。求められるのはCilkのような簡便さではなく、OpenMPやMPI、CUDAやOpenCLといったもっとローレベルな実装だ。

　極論すればHPCのユーザーとは、アーキテクチャの違いやそれに起因するソースコードの書き換えなどいとわず、実行が高速であるかどうかだけを価値判断の基準とする人たちである(これはハイエンドの場合で、企業内のHPCユーザー等では、バイナリのパッケージも使われる)。アーキテクチャ等に対するロイヤリティ(忠誠度)は低く、そのせいもあってか、スーパーコンピューター専業メーカーの多くは、1度や2度の行き詰まり(会社更正など)を経験している。技術的なチャレンジとしてはワクワクするものであっても、事業としてはそれほどエキサイティングなものではないようだ。

　そうであっても、これまでHPCが並列コンピューティングの世界を牽引してきたのは事実だし、今後も並列コンピューティングの一極を担い続けることは間違いない。ただ、HPCの世界で使われてきた技術が、そのまま一般PC向けのコンピューティングに降りてくるかというと、それは必ずしもそうはならないだろう。

　一般向けのアプリケーションのうち、HPCでおなじみのデータ並列に向いたものは極めて限られるし、ソースコードかバイナリかというアプリケーションの流通形態の違い、という問題もある。加えてGPGPUには、OSやアプリケーション本体とは異なるメモリ空間で実行することによるオーバーヘッドが少なからず存在する。果たして、それを乗り越えてもメリットを見出せる一般向けアプリケーションがどれだけあるのか(HPC向けにあることは実証されている)、それともAMDの言うようにCPUとGPUの融合した先に答えがあるのか、議論は尽きない。

.NET Framework 4.0も、データ並列とタスク並列の両方をサポートするが、タスク並列の考え方は新しく追加されたもの

　今回のインテル・ソフトウェア・カンファレンスで興味深かったのは、HPCの並列プログラミング手法とは異なる、一般向けの並列プログラミング手法をインテルとマイクロソフトの両方が提唱したことだ。インテルはCilkを、マイクロソフトはC#と.NET Framework 4.0の組み合わせによる、データ並列とは別のタスク並列の考えを提唱した。

　いずれにしても、マルチコア/メニーコアの将来に向けてスケーラブルなアプリケーションを作成するには、どこかでソースコードを1回は書き換えなければならない。そういう意味では、やはりマルチコア/メニーコアは冒頭で述べた後者の例に違いないわけだが、一度書き直してしまえば、後は書き換える必要はないと両社は述べている。つまり、それ以降はコア数の増加が、アプリケーション性能の向上につながるわけだ。問題は、その性能向上カーブがどこまでリニアに近いものなのか今のところハッキリとしないことだが、Cilkくらい簡便なら、将来の保険と割り切っても対応できそうな気がしてくる。果たして、会場に詰めかけた開発者はどう捉えたのだろうか。