もっと知りたい！ Snow Leopard 第4回

Snow Leopardの深層・その2

マルチコア時代の新機軸！ Snow LeopardのGCD

Mac OS X 10.6 Snow Leopard

　「Mac OS X 10.6 Snow Leopard」は、アプリケーションやカーネルを64bitに対応させたことで性能の向上を図っている（関連記事）。

　ただ、それだけでは実行速度を大きく引き上げることはできない。そこでSnow Leopardは、「Grand Central Dispatch」（GCD）と「OpenCL」というふたつの仕組みも用意している。今回はこのうち、プログラムを並列化する枠組みであるGCDについて取り上げよう。

GCDが生まれた背景

行き詰まるCPUの高速化と、難しい並列化

　まず知っていてほしいのは、GCDが生まれた背景には、プログラムの高速化における「行き詰まり」があるということ。

　プログラムとはCPUに対する命令の集まりで、CPUはこの命令をひとつひとつ処理していく。この命令を処理する速度が「クロック」と呼ばれるもので、単純な命令なら1クロック、複雑な命令なら数クロックから何十クロックで実行される。

　プログラムの処理速度は、CPUのクロックを上げることで向上するが、これが3GHz前後で停滞しており、今後、大幅な上昇は見込めない。プログラム側で命令あたりのクロック数を削減する努力も続けられているが、主な命令でリスク（当てが外れたときのペナルティ）の少ない高速化はひと通りやり尽くされている。

　そうした過去の手法に変わって、プログラムを高速化する要素として期待されているのが、ひとつのCPUパッケージの中に複数のCPUコアをまとめて入れてしまう「マルチコア」だ。

Core 2 Duoのイメージイラスト

マルチコア用のプログラムは難しい

　ただし、このマルチコアCPUを利用して、プログラムを高速化する際にも課題がある。

　シングルコアのCPUでは、単純に命令の実行速度を向上してきただけなので、プログラム側では特にやることはなかった。せいぜいCPUが実行しやすいように苦手な命令を混ぜないようにしたり、命令の並びに気を付けるという「最適化」をするぐらいだった。

　しかし、マルチコアに対応するためにはそうはいかない。ひとつのプログラムはひとつのコアでしか実行できないので、マルチコアを活用するためには、すべてのコアに負荷を与えるようにしなければならない。

　サーバーではひとつのサービスを複数のプログラムに分割して実行する「マルチプロセス」という手段がよく使われる。いい例がウェブサーバーで、サーバーソフトウェアを複数並列で実行して、ウェブブラウザーからの接続ごとに別のサーバーを割り当てることで処理を並列化して、性能を向上させている。

　ただし、単一のアプリケーションを高速化する際、このマルチプロセスはプロセス間の通信が増えるのであまり向いていない。ひとつのアプリケーションの中で同時に複数の作業を行なう「マルチスレッド」のプログラムを記述する必要がある。

　このマルチスレッドのプログラムを記述するのがかなり難しいのだ。

　例えばA／Bというふたつ「スレッド」が同時に動くだけでも、AとBのどちらが先行するか分からないため、スレッド間の関係を調整する必要がある。またAとBが同時に同じメモリーに書き込んで、一方が破壊されてしまうという衝突が起こる可能性がある。こうした問題には「ロック」を使って、排他処理を実装しなければならない。

　一方、ロックなどの排他処理、スレッド間の同期処理は、CPUにとって「重たい」命令で、多用するとかえって性能が下がる。せっかくすべてのコアを使っていても、結果として性能が上がらないのでは意味がない。

　これを示したのが「アムダールの法則」である。プログラム中の並列度、同時に実行していい部分と、ロックをかけてひとつのスレッドだけ動かす部分との比率で、コアを増やしたときの性能向上が決まってしまうというものだ。

　この法則からは、プログラムの中にわずか10%の非並列化部分があるだけで、並列化による性能向上が半分になることが示されている。半分しか並列化可能でないならば、いくらコアを投入してもコアが2つのときとほとんど性能が変わらないわけだ。

　こうしたことから、プログラムがマルチコアを生かすというのはかなり難しい。効率のいい並列化というのはもう何十年という課題で、このアムダールの法則ですら1967年に提唱されている。効率が高くて、開発の負荷もかからない並列プログラミング環境──。これはまさしく「聖杯」である。

　その聖杯の探索に果敢にも挑戦したのがGCDだ。

ASCII倶楽部