StudioでGUIをつけた「高速富士山.app」から技術のフィードバックを行ってみた。なんてことはない、ただ単にダウンロードを並列処理で行うように変更しただけだが、その影響たるやとてつもなく大きい。メイン処理がすぐにダウンロードから解放される(shellコマンドで並列処理する)ようになったため、いくらダウンロードに時間がかかってもおかまいなしである。Xに移行した当初にはそういうこともあった。してクラッシュするのか、ひたすら苦悩した)。いう状態になったというべきだろうか。システムが頑丈になったのだ。開発中のGUI版の高速富士山.appに110か所ばかりライブカメラを登録し、ためしに巡回させてみたところ......さすがに並列処理モードでも、巡回数が増えた分だけパラメータの組み立てなどのオーバーヘッドが大幅に増加し(ダウンロードの処理要求部分は一瞬で終わる)、ひととおり処理するのに45秒ぐらいかかった。処理させた場合には3分ぐらいかかったので、並列処理のメリットが最大限に発揮されているのだが、驚きだ。9の時代から比べてソフトウェアが単純に50倍程度のパワーアップを果たしたことになる。昔は、2か所ぐらいでひーこら言っていたのだ。Xは足回りが強くてピーキーな処理でもめげないのがよい。9のときには、かなり厳密にシミュレーションを行って、「このぐらいの仕事量ならクラッシュしない」という確認を事前に行う必要が、どうしてもあったのだ。基本的にOSを信用していなかったともいえる。ほとんど冗談のような110か所のライブカメラ巡回......そのまま、ムービーの生成までひととおり試験運用してみてもよいが、地球上の異なるタイムゾーンに位置するライブカメラを一括して管理するような機能は、まだ実装されていない。最終的には、異なるタイムゾーンに所属するライブカメラの巡回を行うダウンロード用マシンと、ムービー圧縮をキューイング&実行するコンプレッサー用マシン数台とでクラスタ構成にして、地球上のあらゆる場所のライブカメラを随時高速ムービー化するシステムにしてしまいたい。地球上のありとあらゆる景色を高速ムービー化し、時間と空間を超えてムービーの中に地球上のあらゆる風景をタイムカプセルよろしく封じ込めてしまうのだ。いうのにものすごく男のロマンを感じる。男のロマンというのは、基本的に非経済的かつ無駄で元のとれない話ばかりだが、これはその最たるものだろう。採算面はともかく無視することにして、技術面ではどうだろうか。RAIDを使えばすぐにできそうだ。この構成でパフォーマンスがどの程度出るか、実機で検証してみないと分からないが、ムービー圧縮を同時に複数プロセス走らせることができれば大丈夫だろう。最低構成で、ダウンロード用のXserveが1台に、圧縮用のXserveが2台。それぞれ、共通のディスクアレイにアクセスして、地球上のさまざまなタイムゾーンにあるライブカメラを攻略するのだ。なったらなったで、新たな管理ツールが必要になる。各ライブカメラがどのようなフェーズにあるかが一目見て分かるタイムゾーン別のタスクスケジューラや、処理分散の様子が分かるパフォーマンスメータ。この調子で処理を行ったら、すべての計算機資源が能力オーバーを起こさないか事前に予測するオーバーフローチェッカなども必要になる。ほとんど、宝くじにでも当たらないかぎり実現しそうにない構成なので、想像すること自体が無意味といえば無意味なことだが、いざやろうとした時に、最終的なイメージがあるのとないのとでは大きく異なる(なにが?)。......なんの話だったか。110か所もテストデータを登録してまわった(チェックしたライブカメラはその数倍)ので、かなり疲れたのだ。公開版の高速富士山.appには最初から100か所以上のライブカメラのデータを登録して出すつもりだ。いっても、それらをすべて巡回させた場合には、1日で0.5Gバイト程度......ワーク用を含めればGバイトオーダーのディスクスペースが必要になるし、ムービー圧縮にしても8時間程度で終了するかどうか......。冗談半分で試算してみたところ、1拠点あたり4分以内で画像の破損チェックと自動補完処理、さらにインポートと圧縮が行えれば、なんとか100か所程度を1台のマシンで処理できそうだ。G5のデュアル機でも使えば実現できてしまいそうな話である。現在、すべての画像をダウンロードした後に画像の破損チェックと欠損フレームの補完処理を行っている。高速富士山用システムでは、ほとんどの時間、CPUはリアルタイムクロックを監視して、次の「分」になるまでの待ち合わせ処理を行っているだけだ。ほとんどの時間は遊んでいるのだ。この間に画像の破損チェックを行えていたら、かなり時間の節約になるだろう。別プロセスで画像の破損チェックと自動フレーム補完を行う、バックグラウンド処理専用のツールを走らせておけばよいのだ。いうものこそ、先日のNSTaskを用いてバックグラウンドで走らせておくべきか。画像ダウンロード処理の、残り2時間程度になった時点で、このフレーム補完プロセスを別途立ち上げ、自己診断して異常フレームの破棄と欠損フレームの補完を行わせてみるとよいかもしれない。16時間ダウンロードを行っているうちの14時間分だけでも処理しておければ、ずいぶんと時間の節約になる。残りは、すべてをダウンロードした後で処理すればよい。なんだ、すごくできそうな気がしてきた。これで、自分がObjective-Cでも書ければ、Xserveなどと言わずに普通のマシンで、100か所の処理でもなんでもできてしまうのかもしれない。そこまで言わないまでも、時間のかかる処理だけでもCやObjective-Cで書けると楽しいにちがいない。