見えにくいSnow Leopardの明と暗：元麻布春男のWatchTower（1/2 ページ）

[元麻布春男，ITmedia]

PowerPCのサポートをやめることでインストールサイズが減少

Snow Leopardのパッケージ

　アップルがMac OSの新バージョン「10.6 Snow Leopard」をリリースして、約1カ月が経過した。10.4 Tiger、10.5 Leopardと、豊富な新機能を加えてきたアップデートに比べて、Snow Leopardには新しい機能が少なく、マイナーチェンジに過ぎないようにも見える。だが、実際は多くの技術的な変更と追加を含んでおり、特にデベロッパにとっては見過ごせないリリースとなっている。

　Snow Leopardで加わった技術に触れる前に、まずなくなったものから確認しておこう。それはPowerPCのサポートだ。インテル製CPUを採用する前、1994年から2006年まで使われてきたPowerPCにSnow Leopardは対応しない。最後のPowerPCベースのMac（Power Mac G5）が生産完了を迎えてからすでに3年以上が経過していることを思えば、やむを得ないとも言えるだろう。

　逆に、PowerPCのサポートを打ち切ったことで、Snow Leopardはインストールサイズが小さくなった。アップルは、クリーンインストールした場合、Snow LeopardのインストールサイズはLeopardより約7Gバイトも小さくなるとしている。アップグレードインストールの場合、環境によってはさらにインストールサイズが小さくなることもあるようで、筆者が利用している初代MacBook Airでは、Snow Leopardを導入することでSSDの空き容量が約11Gバイト増加した。Snow Leopardになってコードが増えたと思われる部分があることを考えれば、これ以上の容量がUniversal Binaryのオーバーヘッドだったのだろうか。

　HDDが大容量化した今日、数Gバイトの容量はたいした問題ではないと考えがちだが、まだまだ容量に制約のあるSSDのことを思えば、容量が少なく済むのは悪いことではない。もちろん、容量が小さくなることで、OSのインストールや起動時間も短縮されているはずだ。

Snow Leopardでの目玉は「GCD」「OpenCL」「64ビット化」

Snow Leopardのポイントとなる「64ビット化」「GCD」「OpenCL」

　一方、Snow Leopardになって加わった技術で主要なものは3つある。マルチコア／マルチスレッド環境に最適化されたアプリケーションの記述を可能にする「Grand Central Dispatch」、GPUの処理性能をグラフィックス以外の目的に利用することを可能にするGPGPU技術の「OpenCL」、そして「64ビット化技術」だ。

　Grand Central Dispatch（GCD）のポイントは、CPUコアに対するアプリケーション中のコードの割り当て（スレッドのディスパッチ）をOSが行う、という点にある。マルチコア時代の初期（デュアルコア時代）、ソフトウェアがマルチコアCPUに対応するには、プログラマがソフトウェアを適切にスレッド化することが必要だとされた。

　しかし、1つのアプリケーションを複数のスレッドに分割して実行するよう、プログラム中で指示するのは容易ではない。ただやみくもにスレッドに分割してしまえば、そのオーバーヘッドでかえって実行速度が低下する。そもそも実行時に、どのくらいのCPUリソース（コア数）が利用できるのかも、プログラム時には分からない。アプリケーションはデュアルコアのシステムで実行されるかもしれないし、クアッドコアのシステムで実行されるのかもしれない。実行時にバックグラウンドでほかのアプリケーションが動いているかもしれないし、そうでないかもしれない。そもそも、コアの数と同じ数だけスレッドをディスパッチすればよいというものでもない。これではプログラムをいくつのスレッドに分けるのが最適なのか、判断ができない。

　GCDに対応したアプリケーションを作成する場合、プログラマは明示的にスレッドのディスパッチを指示することはない。プログラム中でスレッドとして分割可能な一塊のコードを「ブロック」として指示しておく。すると、実行時にOSのGCDが、利用可能なCPUリソースなどの状況に合わせて、ブロックをスレッドとしてディスパッチするかしないかを動的に決定する。逆に、あるアプリケーションがアイドル状態にあるときは、そのアプリケーションがディスパッチしたスレッドからコアを解放し、ほかのアプリケーションがCPUコアを有効に利用できるようにもしてくれる。

　Snow Leopardに添付されている標準アプリケーションのうち、一定数はすでにGCDを活用していると言われる。ただ、そうしたアプリケーションの多くは64ビット化も行われているため、純粋なGCDによる効果がどれくらいか、ということは分からない。例えば、アップルは、Snow Leopardによる性能向上の一例として、Finderの高速化を挙げている。その中でPDFアイコンのリフレッシュが1.8倍、JPEGアイコンのリフレッシュが1.4倍になったとしているが、アイコンのリフレッシュなど並列してリソースにアクセスするコードは、GCD向きだという気はする。

特定条件下で威力を発揮するOpenCLだが……

現行のMac Proで採用されるRadeon HD 4870／GeForce GT 120搭載グラフィックスカード

　GPGPU技術であるOpenCLは、極めて高性能になったGPU（グラフィックスプロセッサユニット）のパワーを、グラフィックス以外の目的に応用しようというものだ。これまではGPUベンダーごとに独自のAPIセットを用いていたこともあり、あるアプリケーションの実行を高速化するには、特定のベンダーのGPUが必要になる、といったことが多かった。OpenCLは、オープンな標準に基づくGPGPU向けプログラミング言語であり、GPUベンダーを問わず、GPUのパワーを引き出すアプリケーションの開発を可能にする。

　ところが、このOpenCLの恩恵を今すぐ受けられるかというと、それは難しい。サードパーティにとっては、Snow Leopardで初めて利用可能になる技術であり、本格的な対応はこれからだ。ではアップルの手によるSnow Leopardの標準アプリケーションはどうかというと、どこにもOpenCLによって高速化された、という表記が見られない。Snow Leopardには新しいQuickTime Xが付属するが、ここにもOpenCLに関する記述はない。次のバージョンのiLife（に含まれるiMovieやiPhoto）あたりに期待したいところだ。

　OpenCLに限らず、GPGPU技術の利用が難しいのは、コードの実行をGPUで行う必要があるからだ。当たり前のようだが、GPGPUで実行されるコードは、プログラムのメインルーチンが実行されているCPUのメモリ空間（メインメモリ）から独立した別のアドレス空間、GPUのアドレス空間で実行される。実行に際しては、メインメモリ上で必要なデータやコードをそろえ、それをGPUのメモリ空間（物理的にも独立していることが多い）に転送し、そこで実行する。CPUは、その途中経過や発生した例外などを逐一知ることはできない。インタラクティブな処理にはあまり向かず、まとまった量の浮動小数点演算処理を与えてその結果を受け取る、という形のアプリケーションに向いた技術だ。スーパーコンピュータならともかく、一般的なクライアントPCに、こうした処理を行うアプリケーションはそれほど多くない。あるいはまったく異なる発想のアプリケーションが必要なのかもしれないが、それがいつ登場するのかは誰にも分からない。

徐々に完全64ビット化に近づくMac OS

Leopard（10.5.x）でも4Gバイト以上のメモリを扱うことは可能だった

　最後の64ビット化技術は、少し説明を要する。実はアップルがMac OSの64ビット対応をうたうのは、今回が初めてではないからだ。Mac OSで最初に64ビット対応がうたわれたのは、2005年4月にリリースされたTigerの時である。Tigerでアップルは64ビットのアドレス空間をサポート、ユーザー空間が64ビット化されると同時に、一部のライブラリが64ビット対応となった。2007年10月にリリースされた次のLeopardでは、メインAPIであるCocoaが64ビット化され、64ビットのGUIアプリケーション開発が可能になった。

　そして、今回のSnow Leopardでは2つの部分で64ビット化が行われた。1つは64ビットカーネルの開発と提供、そしてもう1つが標準アプリケーションの64ビット化だ。言い換えると、これまでTigerとLeopardでは、カーネルのサービスは32ビットのままだったことになる。さらに初期のIntel Macが64ビットモードを持たないCore Duoなどを採用していたことを考えれば、32ビットのユーザー空間にも対応していたことになる。

　これらを考え合わせると、TigerおよびLeopardは、32ビットのユーザーから32ビットのカーネルサービスを呼び出すパターンと、64ビットのユーザーから32ビットのカーネルを呼び出すパターンの両方があったことになる。だからこそ、Core Duoを搭載したマシンであろうと、4Gバイトを越えるメモリが利用可能なMac Proであろうと、共通の32ビット対応のデバイスドライバやカーネルサービス（カーネル拡張）を、そのまま利用できた。

Snow Leopardになっても、クライアントのMacで64ビットカーネルが使われることは通常ない

　こうした一種のハイブリッドは、必ずしも珍しいものではない。例えばWindows 3.xやWindows 9xでは、32ビットのユーザーから16ビットのカーネルサービスを呼び出すこと（サンク）が行われていた。こういう書き方をすると、サンクを行うことがOSの安定性を損なうような印象を持つかもしれないが、Windows 9xが時に不安定になったのは、16ビット空間が手狭でリソースが不足していたからだ。もし32ビットのカーネルを利用することが不安定の要因なら、多くの32ビットOSも不安定ということになってしまう。

　話をMac OSに戻すと、Snow LeopardではTigerとLeopardでサポートされていた2パターンに加え、64ビットのユーザーから64ビットのカーネルサービスを利用するパターンが加わる。が、これをもってSnow Leopardはカーネルからユーザーまで完全な64ビットOSになった、というのはちょっと気が早い。上述したように、Snow LeopardはすべてのIntel Macで動作する。つまり64ビットモードをサポートしないCPUでもSnow Leopardを利用できるということは、32ビットのユーザーや32ビットのカーネルも残されていることを意味している。

　また、せっかく加わった64ビットカーネルだが、ほとんどのユーザーがこれを利用することはない。まず64ビットカーネルを利用できるMacは限られている。64ビットカーネルを起動可能なMacは、第2世代以降のMac Proや、最新のMacBook Pro（15インチおよび17インチモデル）とiMacなどだ（ファームウェアがEFI64対応であることが必要条件だが、十分条件ではない）。これら64ビットカーネルを起動できるMacでさえ、64ビットカーネルを起動する際には起動時に6と4のキーをホールドしておかねばならない。これをする必要がないのは、現時点ではXServeだけだ。結局、Snow Leopardになっても、一般のユーザーが利用するのは、32ビットのユーザーあるいは64ビットのユーザーと、32ビットのカーネルサービスの組み合わせになる。