もっと知りたい！ Snow Leopard ― 第4回
Snow Leopardの深層・その2
マルチコア時代の新機軸！ Snow LeopardのGCD
2009年09月02日 18時15分更新
入れ子にも対応
さらに、ブロックによる並列化を入れ子にすることもできる。下のリストは、printfによる出力部分だけをdispatch_main_queueの戻り値で与えられたキューで実行、つまりは main関数と同じコンテクストで実行するというものだ。
 |
|---|
出力結果を見ると、タスクそのものを実行したスレッドと、printfを実行したスレッドが異なる。そして出力はシリアライズされつつも、同じスレッドで実行しているのが分かる。
 |
|---|
並列化したくない部分やmain関数のコンテクストで実行しないと困る部分は、dispatch_main_queueを使ったり、あるいは自分で並列度1（常にシリアライズされて実行される）のキューを作成してそこに必要なブロックだけを登録すればいい。あとはGCDが適切に対応してくれる。
なお、今回はGCDの並列化のサンプルのため、ループの中にdispatch_asyncやdispatch_group_asyncを記述したが、実際のプログラムでこうしたループを並列化するには、ループの並列化に特化したdispatch_applyを使う方が適切である。
dispatch_applyは「stride」（大股で歩く、などの意味）をサポートしている。周回ごとスレッドに分配するのではなく、1〜3周目は1スレッド目、2〜6周目は2スレッド目といった具合に分配して、よりタスクスイッチの手間を減らして、高速化が図れる。
GUIの処理だけメインスレッドで実行
Cocoaのフレームワークはすべてが並列化されているわけではなく、特にGUI周りのオブジェクトは複数のスレッドから同時に変更をかけるのは避けるべきとなっている。
一方、GUIのボタンを押したりスライダーを動かしたときに実行されるIBActionとよばれるメソッドでは、あまり長時間処理に時間をかけるとGUIの処理が滞り「ビーチボール」が回ってしまう。
これまでは、ビーチボールを回さないために IBActionの処理からバックエンドのスレッドに処理を並列化し、またバックエンドのスレッドからは注意深くCocoaのGUIのAPIにアクセスする必要があった。
ところが、GCDを使うとこれが一気に簡略化される。GCDでは、並列にできるブロックの中でGUIを触る部分があれば、そこだけは切り出してメインスレッドで実行する、ということが簡単に記述できるからだ。
 |
|---|
もちろん、単にdispatch_asyncでくくったり並列化したからといっても、それだけでは完全に性能は引き上げられない。これまでと同じで、テストやパフォーマンスチューニングはやっぱり必要だ。
しかし、基本的なスレッドプールを作る部分や、基本的な分散処理はGCDが請け負ってくれるし、Cocoaとマルチスレッドの面倒な部分を気にせずに済むようになる。
プログラマーは、pthreadやNSThreadを使っていたときにおける、スレッドの管理処理などから開放されて、アプリケーション自身の最適化だけに注力できるのだ。これがGCDのメリットである。
GCDの今後と将来
システム標準のアプリケーションはともかく、現状、まだGCD対応のアプリケーションは存在しないと言える。GCDのメリットは即座に得られるという訳ではない。
ただ、停滞するクロックの向上をよそに、CPUあたりのコア数は2から4、4から6と増え、今後も8, 12, それ以上と増え続けようとしている。
アップルは、Power Mac G4で2つのCPUを搭載してマルチプロセッサマシンを世に広めて、現状でもiMacや Mac miniといったコンシューマ向けラインアップでもデュアルコアCPUを採用している。ハイエンドを見てみれば、Quad Coreを2基、合計8コアをMac ProやXserveに搭載している。そんな同社がマルチコア、メニイコアのCPUを将来のOS Xマシンに採用するのは想像に難くない。
そうしたマルチ／メニイコア時代には、Snow Leopardを発端として発表されたGCD対応のアプリケーションが活躍することだろう。
