図2●IPA,プロジェクト管理組織,開発者の関係

正式契約までなんと3カ月!

 内定がもらえればすぐにでも開発に専念できるかと思ったら,開発と並行してさまざまな事務手続きが必要だった。最初はIPA,プロジェクト管理組織,わたしとの三者間契約の手続きだ(図2[拡大表示])。プロジェクト管理組織というのは,開発者には開発に専念してもらうことを目的に,諸手続き(例えば経費精算など)を開発者に代わって行う組織である。「未踏」を支援する企業や研究機関などが事務局をやっている。しかしこういう契約があることは事前にわかっていたので,それほど気にならなかった。煩雑なのは,むしろ自分の所属する会社(ミラクル・リナックス)との調整のほうだった。

 「未踏」が国の事業として画期的なところは,開発した知的所有権や成果物(ソフトウエアなど)の帰属を開発者にしている点である。開発者に所有権を与えて,それをインセンティブにするという考えらしい。目の前にニンジンをぶらさげて一生懸命走らせるという作戦である。

 組織に所属している者が業務上ソフトウエアなどを開発した場合,その知財産権などは通常その組織に帰属する。「未踏」の場合,業務上開発したわけではないので,所属組織ではなく開発者すなわちわたしに知的財産権などが帰属することになる。これを覚え書きとして所属組織とかわす必要があった。

 また「未踏」に参加している間,会社の業務をゼロにして100%「未踏」を行うということは業務の都合上できなかった。そこで休職という扱いではなく,会社業務と「未踏」の業務の比率をあんぶんして給与の調整を行う必要があった。

 さらにやっかいなことに,わたしはミラクル・リナックスの取締役という立場にある。「未踏」への参加が,取締役の競業避止義務(商法264条)に抵触するかどうかが会社で議論になった。すなわち「未踏」における活動が,ミラクル・リナックスの取締役としてのわたしの職務と利益相反が生じないか。あるいは株主との関係により利益相反が生じないかという点が問題になったのだ。簡単に言えば,会社に損害を与えるような活動(競業するようなこと)はしてはならないということなのだが,法律用語は難しい。管理部門および親会社(日本オラクル)の法務と協議した結果,特に問題ないとの見解を得るまでしばらく時間を必要とした。そして,取締役会において「吉岡が未踏ソフトウエア創造事業を行う」という報告をし,議事録に記録するという作業も行った。やれやれである。

 というような経緯で契約書に実印を押し,最終的にその契約書がわたしのところに戻ってきたのは,なんと10月下旬(!)であった。

キックオフでいきなり難題が出現

 とはいえ,10月まで何もできなかったわけではない。7月に採択内定をもらった時点で,先行して開発を開始してよいとIPAから聞いていたのだ。そこでさっそく,京都で開催された他PMのキックオフ・セミナーを見学に行くことにした。夏の暑い日である。新部PM,紀PM,萩谷PM,近山PMの4名のPMが担当する22件の合同セミナーだった。

 開発者の発表を聞いてみると,翻訳システムがあったり,分子言語による生命プログラミングがあったりと採択されたテーマもバラバラな点が面白い。わたしは新部PMのオープンソース系のプロジェクトを中心に発表を聞いた。

 うれしかったのは,懇親会で多くのプログラマと知り合えたことだ。ハワイ在住のゲーム・プログラマの人とか60歳を超えたアマチュア・プログラマなど多彩な顔ぶれであった。皆さん初対面なのでちょっと緊張気味であったことを覚えている。

写真3●インテルから送られたプロセサのドキュメント。英文780ページ。ひたすら読み続けたので,ボロボロである
 京都から戻ると,注文していたインテルの分厚いマニュアルが到着していた。Webサイトから申し込んだら無料で送付してくれたのだ。インテルさんは太っ腹である。このマニュアルの第3巻を「未踏」のために隅から隅までじっくり読むことになる。もちろん英文。780ページである(写真3[拡大表示])。ふー。

 8月,喜連川PMと田中PMとの合同キックオフ合宿が金沢で開催された。両PMのプロジェクト・メンバーが初めて会い,プレゼンテーションを行う機会である。京都ではひやかし気分だったが,今度はわたしが緊張するはめになった。

 ほかのメンバーと比較すると,わたしのプロジェクトは,かなり地味である。色気がない。しかしそこは気にせず,堂々と(?)プレゼンした。

 すると喜連川PMから「未踏」のハードルをぐぐっとあげるコメントが出た。当初はキャッシュ・ミスの回数を計測できればいいや程度に考えていたのだが,PMの要望は,プログラムの「どこで」キャッシュ・ミスが発生しているかを示してほしいというものであった。さすがPMである。いきなり難しいことをおっしゃる。

 その場では的確な実装方法が思いつかなかったので,宿題として持ち帰ることにした。

週に4日は「未踏」専念でSOHO生活をスタート

 金沢から帰ると,すぐに開発兼実験用PCサーバーを発注した。Intel Xeon 2GHzが2個のSMP(対称型マルチプロセサ)で,メモリー1GBの高性能マシンである。本格的な開発は9月にこのマシンが到着してから始まった。試しにLinux カーネルをコンパイルしてみたところ,2.4.20カーネルが1分程度でビルドできてしまった――。なんという速さ! 会社のマシン(Pentium III/700MHz,メモリー256MB)では4分弱もかかるのに…。会社の環境の立場がなくなった。

 会社の仕事と明確に分けるため,「未踏」の作業は自宅で行うことにした。通勤に片道1時間半かかるので,往復3時間が浮く。朝の8時から深夜まで,文字通り朝から晩まで集中できる。自宅のインターネット回線はADSLで,これまた会社のネットワークよりバンド幅があったりする。しかも,(家族には申し訳ないが)朝/昼/晩と三食ついている。生産性が上がらないわけがない。とはいえ仕事も辞められないので,土日も含め週に4日は自宅で「未踏」,残り3日は会社で「仕事」ということにした。

表2●Intel Xeon 2GHz/メイン・メモリー1GBにおけるベンチマーク結果

予備実験でびっくり

 まず,予備的な実験として,メモリー・アクセスのコスト(時間)を計測してみた。さまざまなLinuxシステム・コールの処理時間を計測するLMbenchという定番ベンチマーク・ソフトがある。これを改良して測定した。その結果,得たのが表2[拡大表示]の数字である。

 x86系プロセサには1次(L1)キャッシュ/2次(L2)キャッシュと二つのキャッシュがあるが,なんとメイン・メモリーのアクセスは1次キャッシュへのアクセスの約200倍もコストがかかるというのだ。何かの間違いかと思うほどギャップがあった。つまりカーネルを扱うプログラムは,キャッシュを意識しないと本質的な性能向上が望めないということになる。

 プロセサはいわゆるムーアの法則にしたがって18カ月で倍のペースで性能が向上している。一方,メモリー・アクセスの性能向上は年率数%程度である。その結果,年々プロセサとメモリー・アクセスの処理スピードの差が広がっていく。

図3●メモリー・プロファイリング・ツールの課題
 話には聞いていたが,実際にベンチマークを実施してみて,メモリー周りの性能向上がどれほど大きな課題であるか実感した。しかし問題はここからである。キャッシュ・ミスの回数と,それがプログラムの「どこで」起きているのかを見つけなくてはならない(図3[拡大表示])。

プロファイリングの仕組みを思いつく

 前述のように,x86系プロセサには,性能モニタリング機能が搭載されている。あるレジスタに計測すべきイベントを設定しておくと,その性能カウンタに何回イベントが発生したかを格納してくれるのだ。例えばL1キャッシュ・ミスの回数を測定したければ,レジスタに必要なフラグを設定し,性能カウンタを読めば何回L1キャッシュ・ミスが発生したかがわかるという仕組みである。

 ただしこれを利用しただけでは,回数はわかっても,どこでキャッシュ・ミスが発生したかはわからない。

 そこでインテルのマニュアルを徹底的に読む。通勤電車の中でもひたすら読む。とにかく読む…。やがてパフォーマンスに関しての記述がある15章に,性能カウンタがオーバーフローした時に割り込みがかかるという記述を見つけた。ひらめくものがあった。

 例えば,性能カウンタに-100という値を入れておけば,100回目のキャッシュ・ミスでオーバーフローの割り込みが発生する。そのときプログラム・カウンタの値や各種レジスタの値を保存しておけば,割り込みを繰り返すことでキャッシュ・ミスが多発しているプログラムのデータを取得できるのではないか?――。アイデアとしては何となく良さそうである。後はこの仕組みを実装すればいい。

 念のため,性能カウンタを利用するツールをインターネットで検索してみると,Brink and Abyssというツールと,perfctrというツールを発見した。いずれも,わたしのニーズとはやや違うものであったが,Brink and Abyssは,Pentium 4系プロセサから実装されたPEBS(Precise Event-Based Sampling)というイベント・サンプリング機能を利用していた。これは従来の性能カウンタよりも精密なサンプリングを可能とする機能で,後にわたしの開発の最大の目玉となる。

締め切りまであと3カ月

 メモリー・プロファイリング・ツールが何を目指すべきものかというイメージも自分なりにはっきりしてきた。予備的な実験によって実装のイメージもだんだん固まってきた。

 しかしそれにつれて課題や問題点もはっきりしてきた。メモリー・プロファイリングをとれば,本当にアプリケーションのチューニングに必要な情報を提供できるのか。このツールによって性能向上に役立つ情報を的確に提供できるのか。ツールの有効性をどうやって示し客観的に明らかにするのか――ツールの実装と検証,論文執筆…まだまだやるべきことが山のようにある。時間は足りない。どう開発を加速するか。ツールを利用して未知の問題を発見できるのか。ふとカレンダを見ると,プロジェクトの締め切りまで,もう残り3カ月しかなかった…。

気になる後編は…
ついにプロジェクトが始動。
しかし,技術上の課題,経費処理,論文執筆と問題が噴出。
果たして締め切りに間に合うことができるのか!?