PR

写真1●よしおかです! 手にしているのは,ボロボロになるまで愛用したインテルのドキュメントである
(前回のあらすじ)
 2002年,わたし(写真1)はIPA(情報処理振興事業協会:Information-technology Promotion Agency, Japan)が主催する,情報化人材発掘/育成関連プロジェクト「未踏ソフトウエア創造事業」(以下「未踏=みとう」)に挑戦。合格率14%の難関を突破して,メモリー・プロファイリング・ツールの開発に着手した。しかしプロジェクト・マネジャ(PM)の要望で開発レベルが上昇。ようやく解決方法の糸口を見つけたが,締め切りまで残り3カ月しかなかった…。

 2002年10月,わたしは迷っていた。Linuxカーネル・チューニング用のメモリー・プロファイリング(データ収集)ツール――その開発に,当初わたしは,x86系プロセサに搭載されている性能モニタリング機能を利用しようと思っていた。だが,その方法が本当にベストかどうか,確信が持てなかった。また,開発スケジュールの面でも不安があった。必要な作業の工数を見積もってみると,とてもじゃないが「2003年2月の契約期限までに,すべての作業を終わらせるのは無理!」と予測できたのだ。

 一人のプロジェクトの場合,悪手を指していてもそれに気付くのは難しい。プロジェクトが破綻し最悪の自体になったとき,初めて自分が悪手を指していたことに気付く。それではもちろん手遅れである。技術的課題と工数面での課題――わたしには奇跡(ミラクル)が必要だった。だが,あきらめなければ必ず道は開ける――やがて技術的課題の面で大躍進があった。

Linuxカーネルのキャッシュ・ミスを発見!

 例によってインテルのドキュメントをくまなく調べていると,Pentium 4から,PEBS(Precise Event Based Sampling:精密なイベント・サンプリング)という機能がプロセサに実装されたことを知った。あるイベント(例えばキャッシュ・ミスなど)が発生した時,その瞬間の論理アドレス,フラグ(EFLAGS),各種レジスタ(EAX/EBX/ECXなど)の値を,自動的にカーネル領域に保存する機能だという。それを利用すれば,当初考えていたような「割り込みを利用したプロファイリング」が必要なくなるかもしれない。ごく簡単に言ってしまえば,ハードウエアが自動的にデータを収集するわけで,従来のソフトウエアを使った方法よりオーバーヘッドは低いし,取得するデータの精度も非常に高い“はず”である。

図1●Linuxカーネルのコンパイルで発生するキャッシュ・ミスのデータ。キャッシュ・ミスが発生した瞬間の論理アドレス(キャッシュ・ミスが発生した場所)や各種レジスタの値がわかる
 そこで,実際にどの程度のことがPEBSを使って測定できるかを実験することにした。肩ならしの意味で,Linuxカーネルのキャッシュ・ミスを測定してみる。すると,図1[拡大表示]のような生データが得られた。まさしくキャッシュ・ミスが発生した瞬間の論理アドレス(キャッシュ・ミスが発生した場所)や各種レジスタの値である! レジスタには,アクセスしたメモリーのアドレスなどが入っている。実に素晴らしい!

 ここで論理アドレスをキーにソートしてその頻度を出し,頻度順に並べ替えてやれば,キャッシュ・ミスを多発している場所が一目瞭然となるはず――そう考えてトップ10のリストを作って眺めてみた。どんぴしゃり。カーネルのスケジューラのあたりでキャッシュ・ミスが多発しているのが発見できた。「これはすごい! PEBSというのはなかなかいける」と確信した。

助っ人登場!

 しかし,もう一つの課題である工数不足は,なかなか解決しなかった。当初の計画では,プログラミング経験のある学生さんをアルバイトとして雇って,ベンチマークやらテスト・プログラムの作成やら,比較的単純な力仕事(失礼!)をやってもらうつもりだった。

 リクルートのつもりで出身大学の先輩の研究室に遊びに行った。駅前のミスタードーナツでドーナツを大量に買い込み,「未踏」の話や,わたしのプロジェクトのあれやこれやを小一時間ほどプレゼンテーションした。しかし,あまりにも地味なプロジェクトだからなのか,学生さんの琴線に触れなかったのか,質問もほとんど出ず反応は今一つであった。寂しい徒労感だけが残った。

 知り合いの学生さんにも声をかけた。だが,最終的なところで彼らのスケジュールに合わず,こちらもふられてしまった。八方塞がりとはまさにこういうこと。いよいよ焦りを感じた。

 そんな折,あるメーリング・リストで知人が求職中であるという情報を偶然目にした。YLUG(横浜Linux User's Group,わたしが所属しているLinuxのユーザー・グループ)でご一緒している久保健洋さんである。早速メールで問い合わせた。以前からYLUGのメーリング・リストで,今回の「未踏」についてあれやこれや紹介していたこともあって,とんとん拍子に話が進み,11月末から仕事をしてもらうことになった。

 しかし,すぐに別の問題が出た。どこで久保さんに作業してもらうかである。久保さんにわたしの自宅に来てもらうのは無理だった。我が家の住宅事情が許さないのだ。未踏と会社の業務とは一切関係ないので,会社に来てもらうわけにもいかなかった。

オープンソース・ソフトは横浜で開発しよう

 久保さんは,大切な助っ人である。ここで手放すわけにはいかない。そんなとき,わたしは「“あそこ”だったら,メモリー・プロファイリング・ツールの実装/試験/ベンチマークに使う機材と場所を提供してくれるかもしれない」とひらめいた。

 OSDL (Open Source Development Lab,http://osdl.jp/)という非営利団体がある。米Intel/米IBM/米Hewlett-Packard/富士通/日立製作所/NEC/三菱電機/ミラクル・リナックスなどがスポンサとなって,Linuxやオープンソース・ソフトウエアのエンタープライズ分野での利用を促進しようという国際組織である。日本では,横浜に研究施設(ラボ)がある。

 OSDLには,個人では到底用意できないような,多数のPCサーバーやストレージがあって,オープンソースのプロジェクトなら自由にしかも無料で利用できるようになっている。スポンサ企業の会費によって,費用がまかなわれているのである。このOSDLの施設と機材を利用できないかと思ったのだ。

 早速OSDL Japanの高澤真治ラボディレクタに相談したところ,オープンソースのプロジェクトであれば問題ないという回答を得た。そこで,今回の開発案件をOSDLプロジェクトとして申請した。やがて,OSDLからの許可が下りた! これで懸案の作業場所/機材の問題は解決だ。停滞しかけていたプロジェクトが,ようやく息を吹き返した瞬間だった。

役割分担して開発が再スタート

 そんなこんなで久保さんとの二人三脚が始まった。まず,二人でいろいろ相談をして,作業分担などを決定した。

 各種ベンチマークを実行し,その分析/評価/性能向上などを実施して論文にまとめる作業をわたしが行い,久保さんには主にツールの開発をお願いすることにした。当然,久保さんにもインテルのプロセサについてのドキュメントを読んでもらわなければならない。そうしないことには話が始まらないからだ。

 久保さんはオープンソース・ソフトウエアの開発経験が長く,いくつか自分自身で開発したプログラムをフリー・ソフトウエアとして公開しているほどの実績のある技術者だ。実にたいしたプログラマだった。わたしの伝えた意図を十二分に理解し鼻歌まじりに素早くコードにしてしまうのだ。まさにミラクル。今回のプロジェクトに,これ以上望むべくもない人材だった。わたしは彼の書いたコードを読みながら,あーだこーだいろいろ注文をつけさせていただく,という感じになった。

ツールの実力をPosgtreSQLで検証する

 ところで,Linuxカーネルのキャッシュ・ミスを発見していたことで気を良くしたわたしは,次のターゲットを,フリーのデータベース・ソフトPostgreSQLに決めていた。ソースコードが入手できるからだ。Oracleなどの商用データベースだとソースコードが入手できないので,ボトルネックの分析が難しい。その点,PostgreSQLはソースが見られるというだけでなく,日本のPostgreSQLコミュニティのプログラマの何人かを個人的に知っていたので,いざとなったら相談できるのではないかという目論見もあった。

 12月末に中間報告の合宿が沖縄である。それまでにPostgreSQLでのベンチマーク結果をある程度まとめておく必要があった。ツールのデモも必要となるかもしれない。そこで,デモ用にPentium 4搭載のノートPCを購入した。Pentium 4はIntel Xeonと同じマイクロ・アーキテクチャで,PEBSの機能を持っているからである。

 ところが,そのノートPCでPostgreSQLのベンチマークを実行してみると,どうも結果がピンとこない。PostgreSQLの実装についてわたしが詳しく知らないためかもしれなかったが,どこか特定のコードにキャッシュ・ミスが集中している感じがしなかった。

予算の内訳

 今回のプロジェクトの予算で,あらかじめかっちり決まっていたのは,全体の金額と,わたし自身の人件費およびプロジェクト管理組織費用である。この金額については,仮に予算をオーバーしてもその分はIPAからは支払われない。わたしの人件費は時給とか日給のたぐいではないので,全体でいくらという予算である。

 その他,PCサーバーなどの購入費,学会参加費,旅費(海外/国内),アルバイト費,実験機材のリース費,文献資料費,消耗品費,雑費などなどを,事前に計上していた。10万円以上はいわゆる資産となり,50万円以上の物品の購入は認められていなかった。これらの経費に関していえば,総額を超えない限り科目間の経費の充当はPMの了承のもとに認められた。

 プロジェクトで使用したPCサーバーは50万円以下だったが,十分なスペックのものを調達できた。ソフトウエアの研究開発というのは,極論すればPCさえあれば,どーにかなるのである。大規模な実験設備や資産は必要ない。自分の「頭脳」だけがたよりの世界である。

 文献資料費も,せいぜい各種マニュアルの購入や専門書の購入だから,たかがしれている。海外出張に関して言えば,8月のLinux World(開催地:San Francisco)の参加,12月のOperating System Design and Implementation(同Boston)という学会の参加があった程度だ。

 予算の計上と執行は,プロジェクトによってかなり違う。興味を持った方は,IPAのサイトで調べてみるといいだろう。


なぜ「未踏」が必要なのか

 実は「未踏」に対する批判というのは結構ある。インターネットの某巨大掲示板なんかでは,よくボコボコにされている。それについて,参加者としてちょっと触れておきたい。

 よくある批判が「そもそも未踏の成果は上がっているのか」である。次にくるのが「そもそも国が,個人のソフト開発を支援すべきなのか?」という意見。そして「(建設土木のような)公共事業とどう違うのか?」というものだ。

 まあ,どれもおっしゃる通りごもっともな指摘である。

 確かに,本来なら国なんかに頼らず,自らの知恵と情熱によって出資者を見つけだし,自分のリスクでアイデアを実現するべきだろう。それはそうなのだけど,ビジネスうんぬんの前の技術的シーズの場合,それを支援する仕組みというのが,あまりにも日本にはないのも事実だ。

 米国の場合,技術的シーズ開発は大学が国の研究予算を利用して行うという仕組みがあると聞く。国際競争力のあるソフトウエア研究は大学などが主に行っている。大学という場で若いプログラマが経験を積み,自分のアイデアを実装できる程度の実力をつけ育っていく。

 日本という地域では,そもそも国際競争力のあるソフトウエアを開発販売している会社が絶望的に少ない。人がいないからソフトウエアを開発できないのか,ソフトウエアを開発する機会がないから人が育たないのか――ニワトリと卵の関係がここでもあるような気がする。

 日本の大学発のソフトウエアというのもあまり聞かない。たぶん,わたしが知らないだけのことだと思うが,存在感は非常に薄い感じがする。

 わたし自身は,日本という「国」の国際競争力がどうだとかいう話にはほとんど興味がない。しかし,日本人が開発した国際的にも存在感のあるソフトウエアというのがもっとたくさん出てきてもいいように思う。それはわたしが日本語を母国語とするからで,日本語でそのような人とあれやこれや議論してみたいし,何らかの形でコラボレートできたら素敵だと思うからだ。

 そういう意味で「未踏」というのは,未来への一つの可能性をもった事業だと思うのだが,皆さんはどう思うだろう?