WWDC2014よもやまばなし（自分の興味あるところだけ）

WWDCの話の前にまず枕話。僕の娘は家ではLogicを使っている（ちなみに仕事ではCubaseを使っているらしい。タバコのテイスタが自宅で一服するようなものか）。Logicに大量に積んだプラグインの互換性の問題から新しいOSにあげることができずに、ずっと10.7Lionのままになっている。先週、びっくりした、と言って父親を呼んだ。もう何年もLogicを使ってきたけどずっと32ビットモードで使っていた、それを64ビットモードで起動すると動作が驚くほど速くなったという。

Logicを使うために標準で2GBのメモリのマシンに8GBも積んだのに、ずっと余らしていたことになる。まあそれはいいんだけど、見せてもらうとプラグインのいくつかは32ビットコードしか持っていないものがある。それもちゃんと使えて、しかも32ビットモードのときよりプラグインのロードはやっぱり速いという。

OS Xのバンドル形式のプラグインは呼び出し側のアプリと同じ仮想空間にロードされる。64ビットモードの仮想空間には当然64ビットモードのコードしか乗らない。いったいLogicはどうやってるんだろう（Logicそのものがやってるとは限らないけど）。

32ビットの別プロセスを持っていてそれにロードしてるんだろうか。でもそれではプロセス間通信が大量に発生してそれが律速してしまうだろう。共有メモリだろうか。64ビットと32ビットの仮想空間のあいだの共有メモリってどうするんだろうか。僕は32/64ビット空間を行ったり来たりするアプリを書こうとは思わないので、研究する元気は無いけど、どうなってるんだろう．．．．

さて、ちょっと古い話になるけど、WWDCが終わった。今回OS X10.10で新しく導入される機能で僕が面白そうと感じるのがふたつあった．．．．

ひとつめはAccelerateフレームワークが地道なバージョンアップを遂げている点。一番重要なのは線形計算のフレームワークができるらしいこと。これまで数値計算に使える高水準な線形演算にはLAPACKを使え、ということになっていた（LAPACKはAccelerateフレームワークの一部という位置づけになっている）けど、LAPACKはFORTRANの文化に支配されていて、C/Objective-Cから使いやすいとは言えなかった。10.10でどうやらそれにかわるモダンなAPIが導入されるらしい。しかもObjective-Cのオブジェクトと互換性のあるCoreFoundationと同じようなスタイルのフレームワークになるらしい。パフォーマンスもBLASにせまる、というものらしいので期待したい。

また、vImageがvideo（動画）にも使えるようになるらしい。これまでvImageは画像に対するいろいろな処理、たとえばエッジ強調なんかのフィルタリングやフォーマット変換なんかを簡単に（実はそれほど簡単ではないけど）できるようにするためのフレームワークだった。でも動画用にはvImageは高機能すぎて無駄が多いのでサポートされなかった。何をやりたかったのか忘れたけど、その昔カメラ画像にvImageの機能を使いたくなったことがあった。vImageとCoreVideoのデータの構造が全く違っていて、かなり不便な思いをした。それが簡単になるらしい。

CPUのベクタユニットを使う演算もインラインに書きやすくなるらしい。でもまあ、これはよほどガリガリに最適化したいとき以外はコンパイラがやってくれる程度でも十分だと僕は思うけど。

ふたつめは、世間でも話題になっている新言語Swift。ざっと見る限りでは、ようするにCとおさらばしたObjective-Cという感じ。

Objective-CはC++と違ってCとの互換性に注意を払っていた。Cに対して予約語を追加することはせず、Objective-C固有のシンタクスは必ず「@」をつけることで区別するようになっていた。そのおかげでCのコードはObjective-Cとしてもコンパイルできた。

ところがObjective-C2.0で構文を拡張して、ブロックやARC（Automatic Reference Counting）なんかの新しい機能を追加したせいで、ランタイムとフレームワークとコンパイラの、それぞれの仕事の境界が曖昧になってしまった。Cはもともと言語仕様とランタイムやOSの機能とを厳密にわけることで移植性を高くして、またコンパイラの吐くコードの中にプログラマの関与しない命令は極力少なくすることでシンプルで効率のいいコードにするという意志を持って作られていた。

最近のObjective-Cはコンパイラが親切になんでもやってくれて、プログラマの手間を省くという方向になっている。それどころかプログラマの与り知らぬコードがいたるところに埋め込まれるようになって、アセンブラをたどる意味はなくなりつつある。そうなってくると今度は逆にCのコードがだんだん異質なものに見えてきたんだろう。だったらCを忘れてObjective-CとFoundationフレームワークの機能だけでプログラミングできないか、そのほうがすっきりするし、Cとの互換性を保つためのあれやこれやがいらなくなって身軽になるだろう、どうせならシンタクスも新しくすりゃいいじゃないか、ということでSwift、なんだろう。

SwiftはあきらかにObjective-CのランタイムとFoundationフレームワークをそのまま使っていて、整数や浮動小数点数なんかのスカラ型も全部やめてObjective-Cのオブジェクトにしてしまってプログラマはその区別を知らなくてもいいようにしよう、となっているみたい。ARCはオフにはできないし局所変数はプロパティしかないしブロックは（Closureとして）当然のように使うことになっている。

気持ちはわかる。でもそのためには山ほどあるCベースのフレームワークがSwiftからでも使いやすくならないといけない。AccelerateやCoreAudioやOpenGLを使おうとすると、C/Objective-Cのコードを書く必要があるのでは、なかなかみんながSwiftを使うようにはならないだろう。

もちろんそんなことはAppleはわかってるだろうから、Cベースのフレームワークにはブリッジを提供したりするんだろう（そのブリッジは実質的にCのAPIをObjective-Cのオブジェクトでラップしたものになる）。iOSのパフォーマンスを考慮するせいで、iOSとOS Xと共通の比較的新しいフレームワークは（特に表示にまつわるものは）Objective-CよりCベースのほうが目立つような気がする。どうせまた中途半端なフレームワークはあっさりと無かったことにされてしまうんだろうな（昔ガベージコレクションというのがありましたとさ。iOSから入った人はよかったねえ）。

Appleはマルチプラットフォームや標準化にはほとんど興味が無いらしいし、オープンソースへの関与も自分たちに都合のいいやりかたしかしない。まあ、企業としてはそれでいいんだけど、プログラマはいつまでもそれに振り回されるんだよな。