 |
[2003 年 2 月号] |
|
[2003 年 2 月号] |
［ＯＯエンジニアの輪！］
 |
|
-- まず最初に今のお仕事について、簡単にお伺いしたいんですが。
グリッド研究センターという組織に所属しています。 グリッドは次世代のインターネットだと言われているんですね。 インターネットによって静的な情報の交換が飛躍的に促進されましたよね。 僕らはグリッドで、その枠をもっと広げたいと思っているんです。 最近、色んな新聞記事でもグリッドについて取り上げられてはいるんですけれども、日本語の情報源って全然ないんですよね。 SETI@home のような遊休コンピュータの利用が、イコール「 グリッドコンピューティング 」だと述べられていることが多いんです。 けど、僕らとして主張したいことのひとつは、それだけじゃなくて、 上はスーパーコンピュータからずっと下の PDA 、 あとはネットワークにつながった望遠鏡とかセンサーとか、いろいろな種類の情報資源をターゲットにしているということです。
グリッド研究センターは、高性能計算や数値計算の分野で コンピュータの性能を絞りつくすような事に取り組んできた人達が起源ですね。 分散処理の方向に地理的、距離的に組織もまたいでスケールをどんどん広げていって、 今のグリッドというコンセプトに至ってます。 例えば、 1 台のスーパーコンピュータで行っていた計算を、 たくさんの PC でやろう、たくさんのスーパーコンピュータでやろう、 ウェブブラウザから簡単に使えるようにしよう、 PDA でどこからでも使えるようにしよう、 というようにグリッドに組み込んでいって、色んな方面に広がったんです。 ユーティリティコンピューティング*1という言葉もあるように、 自分がどこに居ても容易に、セキュアに、必要なときに望みの計算資源を利用できるようになってきていますし。 ここでいう資源というのは、代表的には、計算能力のことを指しますが、 ソフトウエアやライブラリ、携帯電話に付いているようなカメラ、データベース、 望遠鏡、電子顕微鏡、脳を調べる脳磁計などのいろいろなデバイスも含めた、情報資源全般です。 こういったものをうまく扱うには、そのためのディレクトリが必要だったり、 安全に扱うための仕組みが必要なので、その必要性に応じて、研究が広がっていった分野です。 こう言うと広すぎてなんだかよくわからないと思うんですけど (笑)。 高性能計算って、間接的にしか生活に影響を与えてないので、中々実感しにくいんですよね。 グリッドって言葉の意味はいっぱいあるんですけども、僕は、それをひとつのコンセプトだと思って、日々邁進しています。
*1ユーティリティコンピューティング
企業が IT サービスを必要に応じて購入できるシステム。
自社でサーバ ( や追加のマシン ) を購入し、メンテナンススタッフを雇うのでなく、
単にサーバの利用時間や処理能力を別の企業から購入する。
サーバの保守などの問題には、この別の企業が対処する。
この企業は、電力会社と同じ方式で顧客に課金する。
つまり利用量が多ければ、料金も高くなる。
-- 最近、 π の計算の桁数が増えたというニュースがありましたが、そういう話とは関連はあるのですか？
将来的には、グリッドの上で、もっともっと速く、効率よく出来るといいんですけれど、 現実的にすぐには難しいですね。 でも、そのような研究をしていた人達が、グリッド研究センターに流れている感じです。
-- 首藤さんのお仕事はその中で、具体的にどのようなことをされているのでしょうか？
高性能計算の昔からの本流である、スーパーコンピュータを使うようなテーマをやっている人も、ここにはたくさん居るんですけど、 僕の場合は、もうちょっと身近で、直接肌で感じられるような事に昔から興味を持っていて、 例えば、映像とかのメディアや、人、 PC 、 PDA などを うまくグリッドに取り込んでいくという活動をしています。 ひとつはこの Access Grid です。 他には、ボランティアコンピューティング ともメガコンピューティングとも呼ばれる、 PC を使った大規模分散コンピューティングにずっと興味があって、 新しいプロジェクトを始めたところです。このあたりが僕のタスクだと思って、活動しています。
-- Access Grid っていうのは、この周りに沢山あるモニターに関係しているんですか？
あ、そうなんです（笑）。 簡単に言ってしまうと、「 ビデオ会議 + α 」なんですけれども、 例えば、市販のビデオ会議システムを買ってきてもここまでの事はできないわけなんですね。 これ一つのウィンドウが、例えば韓国の研究機関だったりとか、 ANL というシカゴにあるアメリカの国立研究所だったりとか、 シカゴ大学だったりとかいろいろ表示されるわけです。
-- これは、リアルタイムなんですか？
リアルタイムですね。普通のビデオ会議でしたら、 2 拠点とか 3 拠点とか、いいとこ 16 拠点とかなんですけど、 これはもっとスケールが大きくて、 20 、 40 、 100 拠点ぐらいでインタラクション出来るんです。 製品として見ると未熟な点もあるんですけれども、こういったものを作ってその上でいろいろ実験していこうっていうプロジェクトです。 僕が始めたプロジェクトではないのですけれども、センターの一員としての僕のタスクです。
-- ソフトウエアも含めて、今までどのようにコンピュータと関わってこられたか教えていただけますか？
昔は、コンピュータ少年だったんです。小学校 5 年生の時に 8 bit パソコンから入ったんですよ。 途中、高校生の時は楽器に熱中して離れてはいたんですけど、 大学でどこに行こうかという時に、物理学や数学が好きだったんで、 物理学科、数学科、バイオ、べたにコンピュータで情報学科・・・といくつか考えて、 情報学科に入って。まぁそのままずるずる 10 年位経って今に至っていますね。
-- プログラミング言語は何を使っていますか？ Java は使うというより、 Java のコンパイラは作るけど・・・ という感じですか？
そうですねー。経験があるだけならばいろいろあるんですけども。 それこそ学部生の時には、講義で Lisp とかやりますし、 Prolog もやったような気はしますし。 実用っていう意味では、 Perl を使っていた時期もあったり、 Ruby も使います けど、自分のネイティブというのは C と Java ですねぇ。
-- Java と出会ったのは?
Java を一番最初に知ったのは、95 年の、 Java が発表されてまもなくの頃の、 Sun の何かのカンファレンスでホワイトペーパーを貰ってきたのがきっかけです。 セキュリティであるとか、スレッドを言語組み込みの機能として持っているとか、色々魅力的だなぁ・・・と思ったんですけど、 実はその時は使わなかったんですね (笑)。ちょうどその頃は大学の研究室に入った頃で、そこでは、並列化コンパイラを作っていたんです。 その当時、並列化コンパイラのターゲットと言えば、何千万円、何億円するような並列計算機でした。 大学では、コンピュータのイーサネット接続は当たり前で、 並列化コンパイラのターゲットは、当然、ネットワークにつながったワークステーションや PC 達なんだろうと思い込んでいたもので、驚いたんです。 そんなこんなで、並列化コンパイラの研究開発を始めました。
-- 大型コンピュータではなくて、ワークステーションだったんですね。
今となっては PC もワークステーションもあまり違いはないですが。
それを使って並列処理をしたいと思ったんです。
冷房の効いた計算機室に備え付けてあるような、大型コンピュータでやってもつまらない。
もっと身近なコンピュータで動かしたいと思ったのがきっかけで、
イーサネットでつながったワークステーション群をターゲットに並列化コンパイラを作り始めました。
コンパイラは、何かしらのソースプログラムを読み込んで、オブジェクトコードを出すわけですけど、
僕は、プログラムを処理単位に切って、ネットワーク越しにばらまいて、分散処理をするというコンパイラを作っていました。
その、切り分けた単位というのは関数やサブルーチンなんですけれど、
その中は、コンパイラの内部表現、オブジェクトのグラフになっているんですね。
で、当時はそのコンパイラが C 言語で書かれていまして、
C で表現されたオブジェクトのグラフをネットワーク越しで送るって事にえらく苦労してですね。
それが 95 年です。
96 年になって、どうも Java にはシリアライゼーションという機能があるらしいということを知って。
これを使えば、苦労することなく、オブジェクトをネットワーク越しに転送できると。
その機能が魅力的だったんで、 Java で並列化コンパイラを作り直しました。
これが、 Java を使い始めたきっかけです。
あと、先輩から引き継いだコンパイラのプロジェクトがありまして、 そのコンパイラが C で書かれていたんですね。 抽象構文木 ( AST : Abstract Syntax Tree )とか依存グラフというプログラムの内部表現をメモリ上に作って、 オブジェクトとその間の参照関係を色々いじってると、 要らなくなったオブジェクトがごみとして出てくるんですね。 で、C でもなんとかごみ集めをしようと参照カウントをしたり、結構大変なことになっていて、その当時破綻してたんですね。 で、 Java で書いたらすっきりしたんですけど、反面、すごく大変なこともあって。 当時の Java は遅かったもので、 Java で書いた並列化コンパイラが、 簡単なプログラムを読み込んで解析して、出力を得るまでに、 1 分半くらいかかってた覚えがあります。
-- あぁ、計算機の能力も足りなくて。
そうですね。今だと一瞬だと思うんですけど。
-- Java に、ネットワークやセキュリティとかの機能は、 95 年の時点で既にあったんですか？ 96 年の時にはシリアライズで。
シリアライゼーションはまだ標準ではなかったんですけれども、どうやらそういう機能が入ってくるらしいと聞いて、 また、色んな副次的な効果もありそうで、 Java だとコンパイラが楽に書けるかなぁと。
それで、 96 年から 97 年にかけて分散・並列化コンパイラを作っていたんですけど、 97 年になって気が変わって、動いてるプログラムを、そのまま、別のマシンに移せたら楽しいなぁと思い立って、 スレッド移送システムを作り始めて、コンパイラの開発をやめてしまったと (笑)。 まぁ、楽しい方にポイントを・・・というスタンスなので。 それで、スレッド移送システムを作りながら、 VM の中をガリガリ調べていたわけですね。 そうしたら、調べているうちに、「 お、 JIT コンパイラ作れちゃうぞ 」って気がしてきて、 それで 98 年から JIT コンパイラを作り始めました。 その年に、僕は大学院の博士課程に進学したんですけど、好きなことをやってるだけじゃ 博士課程っていうのは修了できないので、 JIT コンパイラの上なり何なりで研究をして・・・というのが今に至る経緯です。
-- スレッド移送システムは、私も面白いと思ったんですけど。これは、スレッドの情報と、 その使ってるオブジェクトの両方をシリアライズして、送ってまた再現するということですか？
そうですねー、ここでの考えは、オブジェクトシリアライゼーションをスレッドに拡張したということです。 オブジェクトは、メンバ変数をバイト列に落としていけばいいんですが、 スレッドだと、スタックフレームが積まれていって、その中にローカル変数があったり、 そこから指されるオブジェクトがあったりします。 そのスタックフレームを辿って、ごそっとバイト列に落とすのが基本です。 これの難しい所は、例えば、何か走ってる最中のスレッドは一貫性のない状態だったりするわけで、 それをいかにちゃんと送るかという問題がありますね。
-- いくつかのスレッドが使われているようなオブジェクトがあっても大丈夫なんですか?
そこは、将来の課題のまま終わってしまいましたね (笑)。 本当はスレッドを使うプログラムは、マルチスレッドが協調して動いて初めてなんぼなんですけれども、 僕が作ったのは、一つのスレッドに対応したもので、そのスレッドから辿れるオブジェクトを全部ごそーっと持って行ってしまうものです。 本当だったらそこで複数のスレッドをうまく止めて、複数持って行けるべきなんですけど、 そこに手をつける前に、やめてしまったんですね (笑)。
-- それで、スレッド移送システムをやっていくうち、 JIT コンパイラの方に興味が。
そうですね、当時、 Linux で動く JIT コンパイラは存在しないと思ってたんですね。実はあったんですけど (笑)。 それで、 JIT コンパイラを作ったら自慢できるな、というのが JIT コンパイラを作り始めた動機です。 で、作ってみたら、実はすでに TYA っていう JIT コンパイラが存在していて、ちょっとがっかりだったんですけど。
-- FreeBSD では最初だったんですよね？
そうですね、 FreeBSD では最初ですね。 Linux などの環境ではすでに HotSpot VM とか IBM の JDK があるので、実用的な価値はもうほとんどなくなってきてるんですけど、 FreeBSD ではまだ HotSpot VM は安定していないので、実用的な価値も FreeBSD では残っていますね。 エラー報告が来たりしています。
-- FreeBSD でも HotSpot VM とか動くんですか？
最近ようやく HotSpot VM のコンパイルが通ったようで、大きいアプリケーションはちょっとまだ厳しいみたいですけど、徐々に動き出してるみたいです。
少し話が変わるんですが、 strictfp も絡むんですけど、 95 年、96 年頃、Java は遅い遅いって言われてましたよね。
-- 最近あまり聞かなくなりましたけどね。
そうですね、 J2EE とかを使う限りは、例えば Java 仮想マシン ( JVM ) の命令処理性能が 2 倍遅くなってもそれほどは困らない世界だと思います。 数値計算は数 % を追求する世界でして、そこで Java を使うとどうなるか、っていうアクティビティが 97 年頃からあります。 JIT コンパイラを作ってきた事もあって、 Java でどれだけ性能を引き出せるかなっていうのに興味が出たんですね。 その関係で、暗号の高速な実装を頑張ったこともあって。 98 年に某社が出した暗号方式の実装です。 AES ( Advanced Encryption Standard ) って御存知ですか？ DES ( Data Encryption Standarad ) はいいかげん古いということで、 アメリカの NIST ( 米国国立標準技術局 ) という機関が募集をかけて、結果、 Rijndael ( ラインダール, レインダアル )が勝ち残ったんですけども。 そのコンペティションに日本からは某社だけが応募したんです。 応募するには、 C の速い実装や、 C のリファレンス実装や、 Java の速い実装とかを出す必要があったんですけど、 僕はその中で Java の速い実装を担当したんですね。 でも結局、そのコンペティションで某社は勝てなくて。 僕の Java 実装のせいで某社は勝てなかったと、まことしやかに書くライターも居て (笑)。 それは結構苦い思い出ですね。
-- それは大学生のときのことですか？
98 年、大学院生のときですね。
-- それは速さとかで決まるものなんですか？
色々ですね。速いだけではダメですね。 標準として、国が後押しするようなものって色々な環境で使えなきゃいけないわけですよね。 例えば、 Java Card や 8 bit プロセッサのような小さい環境で効率良く動いて欲しい。 でも、32 bit プロセッサ、64 bit プロセッサでも性能が良くないといけない。 スタティックなテーブルも小さい方がいいし、ダイナミックにとるフットプリントも小さい方がいいし、 とにかく色んな要件があって、評価の側面が色々あります。 Java 実装については、 Windows / Pentium Pro が載った PC 上で評価する、と NIST が言っていたので、 高速化のためにフットプリントを少し大きくしちゃってたんですよ。その戦略が裏目に出たと思うんですけども。 性能を優先して、メモリを食うようにしたら、そこを Sun かどこかの人につつかれてしまって (苦笑)。
-- Java 実装とか C++ の実装とか、 C の実装とかがあって、その中で一番速いのを競うわけではなくって、 Java 同士で競ってっていうことでしょうか？
まぁ、すべては参考資料で、総合的に見て判断されるんですけど、 NIST が提出を求めてたのは、 C の参照実装と、 C と Java の最適化実装ですね。 で、あとは、その他参考資料を出すのは勝手で、ハードウェアインプリメンテーションの回路図とかを出してもいいですし。 某社は実際そこまでやってたんですけど。
-- JIT コンパイラである shuJIT の特徴、高速化の秘訣などを、初心者に判りやすく教えていただけるとありがたいんですけど。
shuJIT のピーク性能を聞かれると辛いんですよね (苦笑)。 正直言うと、ピーク性能では、 HotSpot VM や、 IBM の東京基礎研で作られてきたものとは戦えないですね。 本当は戦いたいんですけど (笑)。一人で作るのはなかなか厳しくて。 Sun や IBM の JIT コンパイラって、今は C と戦うくらい速くなっていて、 HotSpot の Server VM なんか、作っている人に言わせると、 C++ の最適化コンパイラが中に入ってるようなものなのだそうです。 その代わり、コンパイル処理が重いので、コンパイルの対象を限定してるんですけども。 shuJIT はコンパイル処理が軽い点が特徴ですね。
JIT コンパイラがあるのに、 JVM にインタプリタも入っている理由は、 JIT コンパイルに時間がかかるからなんですね。 つまり、コンパイル時間が要らないけどピ−ク性能は低いインタプリタと、 コンパイル時間はかかるけどピーク性能は高い JIT コンパイラを持っているんです。 JVM によっては、インタプリタを持たずに、その代わりに、 もう一つ lightweight な JIT コンパイラを持ってるようなものもあったりします。 コンパイル処理が軽くて、ピーク性能はそれほど高くないコンパイラ。 最初はそれでコンパイルして実行しておいて、 プログラム中で何度も実行されるような部分が見つかったら、 そこは、コンパイル処理が重くてピーク性能が高い方でコンパイルし直すんです。 そういう意味では、 shuJIT の性質は lightweight なコンパイラと言えますね。
-- ちなみに、 HotSpot VM や IBM の東京基礎研で作られているもののソースコードは非公開なんですか？
HotSpot VM は出てはきましたけど IBM のソースはないですね。
-- shuJIT のライセンスが、 GNU GPL ( General Public License ) から LGPL ( Lesser General Public License ) に変更されたようですが。
ライセンスはやっかいですね。 GPL の方が厳しかったんですよ。 GPL って、リンクする相手についても制限が出てくるライセンスなので、変更しました。 shuJIT は Sun の JVM と一緒に動くわけですが、 厳密には GPL のライブラリを Sun の JDK とくっつけて動かす事はライセンス上許されない。 つまり、 shuJIT を GPL の元で配布するっていうのは、使うなと言ってるのと同じ事で、 利用者はみんなライセンス違反になっちゃうんですね。 それは、何年か前から知ってたんですけど、変えるのも面倒臭くて、そのままにしてあったんです。 LGPL っていうのは、そこを緩めたライセンスなんです。 ライセンスに関しては、今、そういうところを知っておかないと、ソフトウエアを配布出来ないのが現状ですね。 「 わからないからとりあえず GPL 」っていう時代は終わっていて、 ちょっと知ったかぶって「 GPL ってちょっとアレだよね 」って かっこつけてみるのが 2 , 3 年前からの流行だと思うんですね。 むしろ BSD ライセンス とか Apache のライセンスとかの、もう少し緩いライセンスを使うのが流行といえば流行ですけど・・・ それはさておき、そういうことを知らないとソフトウエアを世に出しにくいっていうのは、もったいないですよね。 ま、じゃあ、ライセンスについてのコンサルテーションがビジネスになるか？っていったら、そこまでの需要はないんですけどね。
僕ら研究所とか大学って、ソフトウエアを作るじゃないですか。 最初に、アイディアの実証をして、それが 1 のコストで出来たとしたら、 世の中の他の人に使ってもらえるところまで完成度を上げるためには、 5 とか 10 のエネルギーが要るわけですよ。 ライセンスとか権利関係についても考えないといけませんし。 一杉さん は、実用的なソフトを出そう、出して使ってもらおうっていう姿勢で、僕は尊敬しています。 研究者は、アイディアの実証をして、論文を書いて、「 わぁ業績になった。 」以上。 そこから先は、その論文を読んだ誰か別の人が、何か実用的な物を作って世の中に広めていく。 この社会的分業が、昔ながらのあるべき姿なんですね。 僕とか、多分一杉さんも、成果は直接世の中に出して、世の中と接していきたいと思っているんです。 でも、研究者という立場での損得だけを考えると、論文を書いた後に、 5 倍 10 倍の手間をかけて外に出していくモチベーションがあるかというとあんまりないわけで。 ・・・その辺りはちょっと問題意識として持ってますね。
-- ところで、 shuJIT をビジネスで使ってもらおうとかそういうお考えはありますか？
使って下さっている方が、驚くべき事に、けっこう居るみたいなんですけど (笑)。 FreeBSD はサーバ向きって言われていて、ファンは根強いですよね。 Java でサーバというと、 J2EE とか、 Web アプリケーションサーバ等いろいろありますよね。 JRun とか Resin とか。 いまどき、サーバ側アプリケーションといえば Java なんで、 それを FreeBSD で動かそうってときに、 shuJIT を使ってくれてる人はけっこう居るみたいですね。 ま、それはすごく嬉しいことなんですけれども、それは shuJIT 開発の当初の目的ではなかったですね。 ( 当初の目的は ) 言葉はアレなんですけど・・・ 作って自慢したかったんです (笑)。
-- shuJIT のテストはどのように行われたんですか？
自分で書き貯めたテストプログラムをシェルスクリプトで呼んで、 結果を標準出力に吐いて、以前の結果と diff をとると。
JIT コンパイラのデバッグは地獄ですね。 マルチスレッドなんで、スレッドライブラリによってはスレッドの実行タイミングとか切り替えのタイミングが実行のたびに変わって、 エラーの出方が非決定的になりますよね。 走らせると 10 回に 1 回落ちるとか、 30 分くらいマウスをぐりぐりやってると落ちるとか、そんなのどうやってデバッグするんだよって (笑)。
JIT コンパイラのデバッグには、デバッガもすごく使いづらくて・・・。 中で自分で機械語のコードを作っちゃうので、ソースレベルではデバッグが出来ないんですね。 それもあって、デバッガは全然使ってなくって、ほとんど printf( ) デバッグですね。 これはこれで大変で、 printf( ) を呼ぶだけでもけっこう面倒臭いです。 printf( ) を呼ぶような機械語の列を生成するコードを JIT コンパイラに追加するんです。 マジックハンドで孫の手をつかんで背中を掻くというような・・・。 直接触れなくてもどかしいですね。
-- それって C の関数とかにはならないんですか？
えーっとですね。 JIT コンパイラの中がどんな感じかっていうと・・・ ( ソースコードの説明 ) 。
-- 今でもメンテされてるんですか？
そうですね。でも最近はほとんどバグも出なくなって。 99 年頃に、 shuJIT を Sun の JCK ( Java Compatibility Kit ： テストスイート ) にこっそりだと思うんですけど、かけてくれた人が居て。 そうしたら、僕が当時気付いてなかったバグが発見されて、 8000 か 10000 あるテストのうちの 200 くらいが fail してて。 気付いてないバグがまだまだあるんだなぁ、と驚きましたね。
-- shuJIT はお仕事とは関係なくやられていることなんですか？
そうですね、それを言うと、元々何が仕事で、何が趣味っていうのが きっちり切り分けられていないんですけど。 ここ産総研での仕事にも、少しはなってますね。 まぁ職業人としてどうかっていうのは置いておいて、 何をやるにしても、楽しそうだからやるっていうのでやってきたんですね。 学生の時は、学位を頂くために論文が必要だったので、やった後で、さて何とか論文にしよう、といって書いてきたんです。 今も論文は書かなきゃいけないんですけど。 今は、自分の興味とグループの仕事をいかにマッチさせるかに苦心していますね。 やっぱ、人間、興味が湧かないと元気出ないんで。
-- そうですね。
話が戻るんですが、なぜ、コンパイラをやろうと思ったのかというと、 コンピュータシステムってハードウエアからアプリケーションまで色んな層がありますよね。 その上に、ユーザ、政治層とかあるかもしれないですけど（笑）。 世の中にはハードウエアだけを一生作ってる人も居て、どの辺りが好きかっていうのは人それぞれ違うわけですよね。 で、僕は割と下の方が好きで、アプリケーションを作るっていうのは、実は興味がないんですよ。 それよりもアプリケーションの足回りを作りたいんですね。その方が、汎用性が高いじゃないですか。 例えば、お客さんに頼まれてアプリケーションを作ったらそのお客さんのところでしか使われない。 ミドルウエアを作れば、その上でいろいろなアプリケーションが動く。 けど、そうは言っても、ある種のアプリケーションしか動かない。 じゃあ、もっと下に行って、コンパイラを作ったら、あらゆる Java のプログラムがその上で動きますよね。 つまり、お客様がいっぱい居るんですよ。その方が楽しいなぁと。 それだったら OS とかハードとか作ればいいんじゃないの？ってことになりますけど・・・ そんな理由でコンパイラを作ってきました。
あと、もう一つ理由があって、 コンパイラの動作って不思議に感じるんですね。 プログラムを食わせると、中で何やらやって、オブジェクトコードか何かが出てくる。 スレッド移送もそうなんですよね。走ってるプログラムが、そのまま別のマシンに移っちゃうのはなんか不思議な気がして。 人間が作った物なんで、中身は知れたものではあるんですけど、魔法みたいな物が好きなんですよね。 プログラムの動きが魔法みたいで理解できないんじゃ困りますし、研究者が魔法って言っちゃいけないんでしょうけど。 ま、技術を考えるとそんなに不思議な事でもないんですけど、なんか不思議なものを感じるんですね。
-- 人間が何処かから何処かに移送されるのと同じような感じで、ちょっと違うかも知れないですけど。
そうですねー。『 THE FLY 』じゃないですけど (笑)、そのようなものに、興味が惹かれるって事ですね。 分散処理っていうのもそうだと思うんですよ。魔法。こんなとこですね。
-- 開発の過程や、出来た成果物などで、オブジェクト指向的な動作だったって話はありますか？
オブジェクト指向って色々あるじゃないですか。 オブジェクト指向プログラミング言語、オブジェクト指向アナリシス、オブジェクト指向デザイン、いっぱいありますよね。 アナリシスは興味がないですし、デザインは、自分が楽しいことをやる範囲では直感に頼って済ませてます。 オブジェクト指向としては、オブジェクト指向のプログラミングをするだけですね。
-- 今たまたま Java がメインで、いろいろ便利そうだからという理由で使っているということですか？
そうですね。オブジェクト指向言語ってのは、もはやあたりまえの技術ですし。 Java は、機種非依存性とかネットワークとの親和性のために使っています。
-- あと、 Java のこういう所が不満だとか、もっとこうして欲しいとか、そういうのありますか？
そうですね、political な面ですね。依然 Sun が強く握ってる部分が多いところです。 JCP の動きは盛んですけど。 例えば、皆さん開発されててわかると思うんですけど、色々なパラメータ、境界条件の組み合わせでテストを行いますよね。 JIT コンパイラのような言語処理系のテストを行うときは、入力のパターン数は無限ですよね。 そうすると、品質を上げるためには、いかに充実したテストスイートが手に入るかっていうのが、鍵になってきます。 「 Hello, world 」が動いたから「 わー完成 」っていうわけにはいかないので。 JVM のテストとしては、Sun の JCK ( Java Compatibility Kit：テストスイート ) がすごく充実してます。 5 年位前の時点でテストの数が 1 万くらい。今はもっとあると思うんですけど・・・。 Sun はいつまで経っても JCK を公開してくれないんですね。 まぁ、Sun の資産なんで出してくれなくて当然なんですけども。 Sun に高いお金を払ってライセンスを受けると JCK にアクセスさせてもらえて、自分のところの処理系の品質をぐんと上げられる。 僕はそんなお金は払えないし、払う気もない。 そういうところで、 Sun のラインセンスを受けないと、依然、品質を上げるのが大変ですね。
Sun が途中で路線変更したなって思うのは、 最初の頃は、互換性のある、別の Java 処理系の開発を歓迎してた気がするんですよ。 それが、 Java 2 のあたりから変わったと思うんですね。 J2SE 1.4 の API を見ると、その量はすごいものがありますよね。 あの規模を他社がゼロから作ろうとするのはもう現実的には無理ですよね。 つまり互換実装を作れない。 最初 Sun は、仕様で勝負してたように思うのですが、 Java2 の辺りから J2SE の実装で勝負しているように見えます。 残念ではありますね。
-- Java 自体の実装がほぼ固まってきたということはないですか？ まだまだいっぱい改良の余地はあると。
実装っていう意味では、まぁ、 Java 2 SDK 1.4 で、 Classic VM という昔ながらの JVM が削除されて、 HotSpot VM だけになったんですよ。 そういう意味では、保険としての Classic VM が不要になったということで、 HotSpot VM が成熟したのは確かですね。 例えば JRockit とか、 TowerJ とか、 BulletTrain とか、 Java の処理系を出している会社は他にもあるんですけど、 ライブラリを全部自分で実装しなおすというのはビジネス的に pay しないだろうから、 Sun の JDK へのプラグインとして作らざるを得ない状況だと思うんですよ。 この状況を、 Sun としてはシメシメと思うんでしょうけど (笑)。 オープンソースって呼ぶと Richard Stallman には怒られそうですけど、 フリーソフトウエアの世界で GCJ っていう、 GCC の Java 実装が成熟してきてはいるんですよね。 GCJ では、ライセンス上 Sun が作ったライブラリを使うわけにはいかなんですが、 それでも、必要な部分から順次開発していくっていう方針で、けっこう実用的な段階まで出来てきています。 でも、 Java 2 SE 1.4 のライブラリを網羅、っていうのはとても出来ない状況なんだなと思ってます。
-- いま、 GCJ っていうのは、 J2SE のどれくらいのレベルなんですか？
ある部分は 1.4 の API が実装されてたり、別のある部分は 1.2 のがなかったりとか、まぁ、必要に応じて、作りたい人が作るっていう世界ですね。
-- サイバーステップの佐藤さんとはどのようなつながりなんですか？
佐藤さんからいきなりメールを頂いたんですよ。佐藤さんはそれが常套手段らしくって (笑)。 で、どういう知り合いかというと、サイバーステップって、 Java ベースのネットワークゲームでビジネスを展開しているじゃないですか。 今後は中国とか韓国とかにも出て行くらしいんですけど。 で、 PC だけではなく、 PDA や、ゲーム機といった色々なデバイスに広げていきたいそうで、 そういった別の環境に JVM を載せていくときに相談にのって欲しいといった内容のメールを頂いたんです。 彼らは、初めに Java ありき、ではなくて、 ビジネスができるようなネットワークゲームを作る際に、 足回りが自然と Java になっていったと思います。 僕もとっかかりはそうだったんですけど。
-- あと、メールの署名で「 私をたばねないで 」という一節が載っていますが。あれってずっと使われてるんですか？
そうですね。いつから使ってるかは正直わからないくらいなんですけど。 手元に残ってる最古のメールが 97 年 3 月なんですけども、その時点で使ってるんですよね。 だからもう、少なくとも 5 年。 メールを使い始めて最初の頃って、シグニチャ変えるのもけっこう楽しいじゃないですか。 それで、色々変えてたんですけれども、まぁ、もう変える気も起きないんで。
-- この詩を知ったきっかけは？
中学の時の国語の教科書に載ってたんですね。作った方は、新川和江さんという方です。 メーリングリスト宛のメールにこのシグニチャを付けてて、それで個人メールが来て、「 これはどういう意味なんでしょう？ 」 って聞かれたことがあります。 あらせいとうって、ストックっていう花のことらしいです。 アブラナとかあじさいみたいにまとまって咲いて、 ごちゃっとした感じに見えるらしいんですよ。 だから、「 あらせいとうのように束ねる 」っていうのは ほんと十把一絡にごちゃっと一緒くたに束ねてしまう事だって、教えてくれた方もいらっしゃいましたね。 新川さんの詩は、女として「 私を、お母さんって、妻って、ひとくくりにしないで 」っていう表現だったと思うんですけど、 その一節が、僕の中ではもっと広い意味になって、20 代になるまでずっと頭の中に残っていて。
-- 初めて知ったのは中学生の時？
そうですね。作者が新川さんだということも忘れてたくらいなんですけど。 ま、若かったなって思う笑い話としては、これ、束ねないで、って偉そうな文言ですよね。 大学に居た頃、村岡研究室という所に居たんですけど、指導教員の村岡先生へのメールにも このシグニチャを使っていたんですよ。 「 私をたばねないで 」って (笑)。 ま、就職した今となっては使えないですけど (笑)。
-- なんか自由に生きたいという表れなんですかね
そうですねー。
-- 先程おっしゃっていた Sun のライセンスとかも関係しているのかなーと思ったりしますが。
やりたい事があって、それが political な理由から制限を受けるのってばからしいですよね。 例えば、技術も、時間も、お金もあるのに、政治的な事で制約されるとか。 ばかみたいなんで。
-- そのような気持ちが・・・。
まぁ多分一貫して流れてるんだと思うんですけど。
-- 今日、 Web で検索してたら、金八先生の中でも・・・。
朗読されたらしいですね。それは見てないです (笑)。 僕も、最近、いまどきなら詩もウェブに転がってるかなーと思って検索したら、案の定見つかって。 改めて全文読むと、やっぱいい詩ですね。 人に何か押しつけるとか、人の領域に踏み込んでいくっていう意味ではないのですが、 自分の大事な一線は、何があっても譲らないって感じはしますよね。
-- そのような所に共感してるんですか？
そうですねー。 僕、謝るのがすごくヘタで。 こう見えても結婚してもう 5 年になるんですけど。 で、家内に怒られた事あるんですよ、「 なんで謝らないの？ 」って。 「 悪かった、悪かった 」とは言うんですけど、 「 ごめんなさい 」って一言も言わないらしいんですね。とにかく謝る事が嫌いなんでしょうね。 最近ちょっと気を付けて、謝るべき時は謝るようにして、譲るところは譲るというように心がけてます。
-- ホームページにある論文か何かに、最後のページで「 奥さんへ ありがとう 」ってありましたよね。
あー多分、修士論文か博士論文だと思います。もう修士の時に結婚してたんで。
-- 早いですね。
そうですねー。さんざん大変な思いをしてもらったと思うので、 学位論文なんてあまり他人が読む物でもないので・・・ま読んで欲しいんですけど (笑)。 感謝の気持ちを。と。
-- 今ご家族は？
2 人だけです。就職もしたんで、いい加減にそろそろ子供を、とも思うんですけど、なかなか親父になるって覚悟も実感も出来ないものですね。
-- 休日とかは 2 人で過ごされるのですか？
暇な時は 2 人ですね。幸いここ、つくばは、道が広くてドライブは快適なんで、 ショッピングモールに行って眺めたり、 あとは、ランチに外食するっていうプライベートが多いですね。 まぁ、そうでなくても、家内が朝昼晩全部作ってくれて。 実は僕、家事を何にもやってないんですよ。 昔、塾でバイトをしていたときの同僚で、亭主関白希望っていうヤツが居たんですけど、そいつ 「 僕は結婚したら、奥さんに全部家事をやってもらいます！ 」って。 「 そんな事じゃいまどき結婚相手居ないよ 」って言っていたんですが、僕がそうなっちゃって (笑)。
-- 奥さんすごいですね。
奥さんすごいと思いますよ。それで、僕が学生の時はフルタイムで月から金まで働いて、 お弁当も作って朝も晩も作って、洗濯もして、洗い物もしてっていう時期があったんですよ。 そういう時期があったんで、今思うと大変苦労をさせたなぁと。
-- 奥さんに食べさせてもらってた時期もあったんですか？
かろうじてヒモにはならなかったですね (笑) 。 月収では負けたときもあったんですけど、年収ではなんとか負けずに来られたと思います。
-- 早稲田大学では、院生が助手として働けるそうですね。
そうですね。他の大学では無くなってきてるらしいんですけど、 早稲田大学には、大学院博士課程の学生が助手を兼ねられるっていう制度があるんですね。 博士課程で研究しながら生活費稼ぐのって大変ですよ。 日本学術振興会っていうところの特別研究員に採用されると、 月に 20 万円もらえて、アルバイトをする必要もなくなるんですが、 でも 5% くらいの狭き門で、実は僕、落ちて。で、助かったのが、早稲田の助手制度。 でも、さすがに、2 人で暮らすためには、それだけじゃちょっと足らなかったですね。
-- すいません、突っ込んだ話を・・・。
いえいえ (笑)。
-- あと、趣味が口笛とか。これで食べて行けるとか (笑)。
(笑)。これで食べて行けるといいですけど (笑)。
-- ちょっと聞かせて下さいよ。
(笑)。そんな事言われるとアガりますね。何か曲があれば。 ( ちょっと披露 )
口笛はホント昔から、中学校入った頃から大好きで。 ビブラートの練習をしてみたりとか、チューナーで音程あわせをしてみたりとか (笑)。 あと、家でテレビを見ていて何かの曲が一回耳に入ると、ずーっと同じ曲吹いてるんですよね。 そうすると、うるさいからやめてよって言われたり (笑)。 「 家ではくつろぎたいんだから吹かせてくれよ。 」って言ってはみるんですけど。 同じフレーズをずっと聞かされる方は嫌なんでしょうね (笑)。
-- じゃあ、最後に、オブジェクトの広場で宣伝したいような事があればお願いします。
そうですね、僕、 4 年間、 JIT コンパイラをすごく楽しくやってきたんですよね。 それだけ楽しめる、同じくらいのめり込めるネタなんてなかなか見つからないわけです。 最近ようやく始めたのが、昔から興味のある分散コンピューティングのためのミドルウエアなんですよ。 これは、 SETI@home みたいなことを皆がやるためのソフトウェアで、 たくさんの計算機を束ねて大きな計算をするためのものです。 例えば「 僕は暗号の安全性を調べたくて、○○という解析をしたいんだけど、手元には計算機が 3 台しかない。だから皆さんパワーを下さい。 」 といったことを始めるための道具ですね。 狙いはいくつかあるんですけど、まずは、組織内のリソースを使い尽くすこと。 あと、 SETI@home では、僕ら参加者はコンピュータ、計算能力しか供出できないですよね。 それだとつまらないので、その上で、誰でもプログラムが書けるようにすること。 3 つ目は、組織内で束ねたリソースを、安全にお互いに融通して、 時にはいっぺんに使って、大きな計算を行えること。 そういったミドルウエアを世の中に提供しようとしています。
-- 計算資源を提供するだけではなく、それを使う側にもなれると。
それも、もちろんありですね。 あと、狙いとしては、計算機のリソースを 「 よし、ちょっとお前に貸してやるよ。 」ってことも簡単に出来るようにしたいなーと。
常々、世の中を変えたい、インパクトを与えたい、影響を与えたいって思ってるんですね。 例えば、携帯電話。僕、 94 年に PHS を 4 万円で買ったんですけど、その当時、 こんなに世の中に普及するとは思ってなかったし、 待ち合わせの場所も決めずに街に出かけるなんて考えられなかったわけです。 それが、皆が携帯電話を持つ事によって、生活ががらっと変わっちゃいましたよね。 携帯電話の基礎技術を作った人っていうのは、別に、世の中を変えようと思って作ったわけではないと思うんですが、 その技術が、僕らの生活をがらっと変えたのは紛れもない事実ですよね。 技術開発、研究っていうのは、こうやって世の中をがらっと変えられるチャンスがあると思ってます。 携帯電話ほど世の中を変えられるかどうかは知らないですけれども、 世の中にそれくらいのインパクトを与えられる可能性は、まだ僕にはあると思っています。 世の中を変えたいという気持ちで仕事をしている、って言うと、なんか、かっこいいですね (笑)。
人生の目標って人それぞれいろいろあると思うんですね。 お金持ちになって隠居して楽しく暮らしたいとか、何か大きい事をやりたいとか。 僕の場合は、自己顕示欲だと思うんですけども、世の中にインパクトを与えて、世の中を変えたいんですね。 本当は、どうやって変える、こうやって変えたい、っていうのが先にあるべきなんでしょうけど。-- 世の中を変えたいっていうのは、アプリではなくって、それの基盤になるような物を作りたいと？
そうですね。お客様が多い方が、インパクトも大きいと思うので。 ま、もちろんお客さんが 1 億人つくようなアプリケーションが作れるならば、それで世の中変えたいとも思いますけれども。
-- 今日はありがとうございました。
こちらこそありがとうございました。
| ©2003 OGIS-RI Co., Ltd. |
|
