米澤研究室 助手さんアンケート


回答者:田浦助手

Q 現在、どのような研究をなさっていらっしゃるのですか?

並列・分散プログラミング、およびプログラム言語です。

Q 研究室で行われているプロジェクトについて教えて下さい。

明確に名前のついてないプロジェクトも多いですが、以下のような研究をして います。

(1) 高性能な並列プログラム言語処理系
(MTCAMPプロジェクト, Schematicプロジェクト)

並列計算機用のプログラム言語の設計や、その実装を研究しています。プロジェ クトの目標は「ややこしいアプリケーションの並列化を容易にすること」にあ ります。これまでに行ってきたこととしては、C/C++言語から利用可能な高速 なスレッドライブラリ(StackThreads/MP)と、それをベースにしたC/C++言語 (MTCAMP)や、Schemeをベースにした並列オブジェクト指向言語Schematicです。

StackThreads/MPというのは、短くいうと、一つのスレッドを作るのに十命令 とかそのくらいの命令数でスレッドが作れるというスレッドライブラリです。 今、共有メモリ上の並列プログラミングというと普通、Pthreadなどのスレッ ドライブラリを用いて行います。あらゆるスレッドライブラリが備える基本的 な機能は、プログラム実行中にスレッドを生成する機能、および実行時に作ら れたスレッドを複数のCPUにマッピングして実行する機能です。例えばプログ ラムがスレッドを10個作ると、あとは実行時システムがそれらの10個のスレッ ドをCPUに割り当てて実行してくれるわけです。CPUが10個以上あれば10個のス レッドが並列に実行されるでしょうし、それ以下の場合は1つのCPUに複数のス レッドを割り当てて実行してくれる、というのが基本的なアイデアです。この 辺のことは普通の本屋に行って「スレッドプログラミング」とかいう題の本を 買えば書いてあることです。

このスレッドがプログラミングをどう簡単にしているかというと、基本的にプ ロセッサ数のことを気にしないでプログラムが書ける、というところにありま す。であれば、プログラム中の並列実行可能な処理に1スレッドを割り当てて 実行したくなるわけですが、実際には、今世の中で使われているPthreadなど のスレッドライブラリでは、スレッドを生成するコストが大きくて、並列にで きる仕事が出現したからそこでスレッドを一個作る、というわけにはいかない のです。例えばquicksortのプログラムを書いていて、再帰呼び出しをする部 分が二つ並列にできるからといってそこでスレッドを作る、というプログラム を書くと、スレッドの数が増えすぎて、全然スピードアップしないか、そもそ も実行できないということもある。だから一般にPthreadを使って並列化をす る場合には、並列に行える「自然な」仕事の単位にひとつのスレッドを割り当 てるなんていうことはできなくて、自分で複数の仕事をまとめて一つのスレッ ドに割り当てて、なおかつ全スレッドに均等に仕事が行き渡るようにしなくて はいけない。これだとせっかくのスレッドの機能「=プロセッサ数のことを気 にしないで書ける」がなんのためにあるのかわかりませんよね。

そもそもそんなややこしいことをして並列化できるのはQuicksortなどのベン チマークとか、並列ソフトウェアコンテストみたいな場面だけ(笑)で、これで は、実用的なプログラムの並列化なんて言うのは到底おぼつかない。 StackThreads/MPが可能にしているのは「スレッドをどんどん作って、スレッ ドのCPUへの割り当てを処理系にまかせる」というプログラミングスタイルで す。それにはスレッド生成のコストを極力少なくし、かつプロセッサ間の不必 要なスレッドの移動を少なくすることが必要です。

これまでに我々の研究室では、StackThreads/MPを直接用いて既存のC/C++アプ リケーションを並列化したり、あるいは高級言語の実行時システムとして StackThreads/MPを用いて、並列言語を実装したりしています。その中のひと つにC/C++の拡張であるMTCAMPという言語があります。またこれとは独立した スレッドですが、Schemeをベースにした並列オブジェクト指向言語Schematic というのも作っています。基本的なコンセプトは同じですが、こっちはScheme というできるだけシンプルな言語をベースにすることで、コンパイラ主導のア プローチを研究しています。また、最近はそれなりに単純でかつ実用的な言語 としてJavaが登場していますからそちらの方面にも進出しています。

これからさらにやりたいこととしては、アプリケーションに存在する並列度を 自動的に発見したり、並列化の誤りを発見したり、ということがあると思いま す。この分野はこれまで、前者は自動並列化、後者は競合検出、というような 分野で研究されてきましたが、それらを総合的に用い、あるいは拡張してプロ グラムの並列化を助ける道具、環境にしていくことが必要だと思っています。

もうひとつは同じ並列プリミティブでもこれまでの言語にある並列プリミティ ブのような、並列化のすべての責任をプログラマに負わせるような並列プリミ ティブではなく、よりプログラマに親切な並列プリミティブの研究をしたいと 思っています。

並列プログラム言語の研究は、私と、大山君(D2)、外山君(M2)、田中君(M1)、 大門君(M1)がやっています。StackThreads/MP, MTCAMPプロジェクトについて は、http://www.yl.is.s.u-tokyo.ac.jp/sthreads/ および、 http://www.yl.is.s.u-tokyo.ac.jp/mtcamp/ を見てください。

(2) 並列・分散ごみ集め

並列プログラミングのためのアブストラクションという観点から、並列・分散 ごみ集めは非常に重要です。特にごみ集めは高級言語の処理系を作ろうと思う とほとんど必須の機能で、かつ性能上ボトルネックになりやすいところですか ら、ごみ集めの研究をしないと、言語処理系を作るといってもおもちゃのよう なものになりがちです。並列・分散環境となると、どこかその辺のごみ集めの 処理系をとってこようにも、そんなものはほとんどありませんし、並列環境で は性能に対する要求も高いですから、覚悟して気合を入れて望まなくてはいけ ないところです。

ごみ集めはもっとも簡単に言ってしまうと単なる「グラフの走査」アルゴリズ ムです。プロセッサのルート(レジスタなど)からポインタをたどってたどり着 けるオブジェクトを生きているものとして残し、そうでないものを再利用にま わすという、原理は至極単純なものです。

並列環境でのごみ集めはというと、早い話しがこのグラフの走査を並列にやる。 でもこれを64台くらいまでちゃんとスピードアップさせようと思うとなかなか 苦労がいります。

分散環境では、ポインタに2種類あってローカルなポインタ、これた通常のポ インタと同じで単なるアドレスとしてあらわされます。一方、他のプロセッサ へのポインタは遠隔参照といって、各プロセッサが単なるメモリの読み書き命 令で参照することはできません。したがってGCはグラフの走査をするのに他の プロセッサにメッセージを送ったりしながらやらないといけなくなります。

これまではこれらの基本的な方式の実装や評価をして、それらの処理系が今後 言語処理系を作ったりするために再利用しやすいような、ライブラリ(使用上 の制限が非常に少ないパッケージ)として提供しています (http://www.yl.is.s.u-tokyo.ac.jp/gc/ を見てください)。

今後、これらの研究はJavaのような環境が広まるおかげで実践的にもますます 重要になり、(これまでと違い)よく陽のあたる研究分野となるでしょう。我々 の今後の方向性としては、(1)より大規模で、かつ多様な通信コストを持つプ ロセッサ(分散共有メモリ計算機や、ソフトウェア分散共有メモリ計算機)での 統一的な性能モデルや、高性能アルゴリズムの研究, (2)モーバイル計算のよ うな、異機種の計算機にまたがり、かつ環境(ノード数や通信性能)が動的に時 間とともに変わるような設定の元での分散GCの研究、(3)並行性や実時間性を 導入した高性能GCの研究、などをやっていきたいと思っています。

並列・分散GCの研究は私とともに、遠藤君(D2)、山本君(D1)がやっています。 やる気のあるワカモノの参入を求めています。

(3) モバイル計算用プログラム言語

モバイル計算というのはネットワーク上のホスト計算機を動きまわる計算のこ とで、要するにnetwork wormですね。モバイル計算用プログラム言語というの は、その名の通りモバイル計算を書きやすくするプログラミング言語です。こ の話しは、重要になっているインターネット上の分散アプリケーション(WEBア プリケーション)を開発する言語として重要になります。

研究テーマとしては、(a)言語設計上の問題、(b)柔軟な安全性モデル、(c)実 行効率、などに焦点をあてて取り組んでいます。

(a)は、モバイルアプリケーションを容易に開発するための基本的な言語機能、 抽象化は何か?という観点です。もっとも単純にはプログラム中の任意の地点 で新しいホストに移る、という機能(goという文で、Telescriptという言語で 採用されています)が便利なのは容易に想像がつきます。また、移動プログラ ムがホストに到着した時に、そのプログラムとホスト上でのプログラムを、プ ログラマの手を煩わせることなく結合するのも基本的な機能です。簡単な例で は、"hostname"という変数が、現在実行中のホストの名前をあらわしていると すると、この変数は"go X"とやってXというホストに移ったときに自動的に変 更されてほしいわけです。また、インターネットで買い物をするプログラムが、 "priceList"という変数で価格表を参照していたら、その中身も新しいお店に 行った瞬間に自動的に変わってほしい。ムズカシイ言葉で言えば、"hostname" や"priceList"のような変数は移動のたびに動的に再束縛がおこってほしいわ けです。そのような再束縛は通常の静的束縛の言語ではおこらなくて、どこか にプログラム言語レベルの名前空間とは違う名前空間を仮定して、そこをアク セスして"priceList"オブジェクトを取り寄せる、などというまわりくどいこ とをしないといけないわけです。

(b)の安全性モデルが重要な理由は容易に想像がつくと思います。なにをする かわからないnetwork wormをさあどうぞと受け入れるホストはありませんよね。 でもftpやらmailやら、アプリケーションごとに通信プロトコルを決めて、ク ライアントプログラムとサーバプログラムを各所に配置するとようやく一つの アプリケーションができあがる、というこれまでの開発モデルは今後のWEBア プリケーションの開発モデルとしては柔軟性に欠けます。明らかに、ある形式 で書かれた任意のコードに対して、こちらが意図しない資源へのアクセスを防 止するような手段が必要です。Javaのsecurity model (sand box)がそれを部 分的に達成しているわけですが、我々はさらなる柔軟性(と研究課題 :-)を求 めて、任意のオブジェクト(memory領域)を、細かい粒度(1 word)でかつ動的に その方針を変更しながら保護できるシステムを研究しています.

(c)上に上げたような特徴を持つシステムを効率よく実装するのは明らかに challengingな課題です。これまでに、go操作を効率よく(他の部分の効率を落 とさずに)実装する方法、上述のsecurityモデルのオーバーヘッドに関する研 究などを行ってきました。

これらの研究は私、関口君(PD)、橋本君(PD)、後藤君(D1)、多賀君(M2)、大岩 君(M1)、星名君(M1)がやっています。

研究は、先にプロジェクトありきで始まるものではありませんから、当然上の カテゴリーに収まらない研究もやっています。杉田君(D1)は動的コード生成に ついて研究しています。これは一般的なプログラムの一部の入力が定まった瞬 間に、その入力に特化したプログラムを非常に高速に生成するという技術で、 進んだプログラム言語処理系の核技術として注目を集めています。明らかにモ バイル計算への応用が考えられます。今井君(M2)はコンポーネントソフトウェ アについて研究しています。

Q 所属していらっしゃる研究室ならではの特徴がありましたら、教えて下さい。

僕がこころがけている・目指していることなどは大概は当たり前のことで、きっ と他の研究室の人も考えていることでしょう。なので以下は、うちの研究室な らでは、ということに限らず述べたいと思います。

ひとつは学生との議論をたくさんすることを心がけています。研究が未熟な段 階からそういう議論をいっぱいする。特に最近は、自分が議論のネタを振るの ではなく、あくまで学生が、未熟な考えでも良いから言い出したことに対して リアクションをして、それを発展させていくよう心がけています。今までは、 若気の至りというか、ついついネタ自体を最初から与えてしまいがちだったん だけど、そうするとそのネタで一個論文書いたところで満足してしまう場合が、 わりかし多いんですよ。

そうならないためにはやはり、ネタ発見の段階で苦労してもらって、それを支 援すべく、研究が始まる段階での議論に付き合うという考えにしたのです。そ うやって生みの苦しみを味わった方が、すればその過程であれこれ思考錯誤し たことがちゃんと頭に残っていて、今書いてる論文は、より大きな目標の中の サブゴールに過ぎないってことがわかるでしょう。すると、次にやることが自 然に見つかるし、実践的にはその論文の"introduction"や"future work"の章 を書くのに苦労しないですみますから(笑)。これから卒論を書く人は introductionを書くのが一番しんどいことを経験することでしょう)。

で、そのようなことをすることの結局の目標は、学生をちゃんとした研究者に 育てることで、それは言葉を変えれば、研究という場においてちゃんとルール を守ってプレイをし、他の研究者から、それも日本だけじゃなくて世界の同業 者にきっちり認識・一目置かれる選手に育てることです(注:自分もそうなる よう鋭意努力中)。ルールというのは例えば、論文を書くときには関連する研 究をきちんと調べてそれとの差分をきちんと論文の中で触れるとか、そういう ことです。当たり前のことなんですけど、これが実際にできるようになるのは 結構大変なのです。そのためには、さあ論文を書こうという段になって一生懸 命他の研究を調べ始めて、無理矢理違いを見つけて書くとかいうことではダメ で、普段からたくさん論文を読む、それも目的意識を持って読むということが 重要になります。そういう研究する選手としてのルールを怠りなく指導すると いうのが基本目標としてありますね。実践的にはこれで論文の"related work" の章を書くのに多大な苦労をしなくてすむようになるわけですね(笑)。

ちなみにこの手のことは本屋にでもいって「論文の書き方」みたいな本を見る と表面的には似たようなことが書いてあります。曰く「論文が受かる落ちるは introductionとrelated workで決まる」みたいなことが書いてある。「だから introductionとrelated workをちゃんと書け」みたいな。それらをちゃんと書 け、という結論は僕も同じですが、僕としてはそららを充実させるのは単なる 「論文の書き方」なんていう小手先の技術でできる話じゃなく、そもそも日常 どういうvisionで研究やってるかってことがそのまま現れるもので、だから重 要なのだといいたいです。

あ、このページはこれから研究室に来る人のためのページのはずが、なんだか 今すでにうちにいる人のためのページになってきてしまいました(笑)。

さて、研究の内容について目指すものですが、これについては確固たる意見は ありません(笑)。というか、要するにちゃんとした研究ならなにやったってい いでしょ、というのが思想としてはありますね。これ以上「研究というのはこ うじゃなきゃいけないのだ」というspecificな考えはありません。スペースの 都合もあることにして省略(笑)。

でももちろん、今我々がテーマとしているプログラム言語とか、並列・分散処 理の研究がどーたらこーたらという考えしたら、少しはあります。

まず、プログラム言語の研究の持つ他の分野にない恵まれた特徴は、研究と実 用との距離がエラク短いというか、ほとんどないというのがあるんじゃないで しょうか。基本的に個人とか数人で、ちゃんとしたものを作ることが可能で、 それを使ってもらうことも簡単ですよね。今自分がgccの作者だったら、なん かいいな、って思う人は多いと思います。

こういうことが、がんばればできる世界というのはそもそもコンピュータのソ フトウェアの世界以外にはあまりない。その、コンピュータのソフトウェアの 世界であっても、言語とかその周辺は特に恵まれている。同じソフトウェアの 世界でもOSやDBとなると規模も大きいし、なかなか普通の人が、「ひとつ試し てみようか」といって使ってもらうというわけにはいかないですよね。もちろ んもっとお手軽なアプリケーション(MP3エンコーダ)だったら気軽に使っては もらえますが、それだと今度は単に便利に使われてるだけ、って感じでいまい ち人々のコンピューティングライフのクリティカルな部分("根っこ")を押さえ てるゾッて感じがしませんよね(それにしてもやけに独断と偏見に満ちた文章 だね。まあ、あまり気にしないで)。というわけなので重要なことは、やはり 言語をやるからには、少なくとも姿勢としては、そういう「根っこ押さえるチャ ンス」を常にうかがっていてほしいなと思うわけです。何か独創的なもの作っ て名をあげてやるぞ、みたいな。「どうだ、私の作ったツールがなくてそれが 作れたのか?」みたいな。要するに「自分の研究は一般コンピュータ利用者に はそもそも関係なし!」って思ってはいけませんよ、と。

誤解してほしくないのは、別に最初から万人に役に立つことを目指して研究せ よといってるんじゃなくて、プログラム言語、システムソフトウェアの世界は 自然と結構そういうチャンスはころがっている。そういう、研究と万人の日常 との距離が近いということを意識しながら研究をやった方が色々チャンスが増 えてくる、といいたいのです。役に立つことを第一義に考えたらGNU FSFの contributorになるのが一番の近道だということになってしまう(笑)。あくま で研究としてのオリジナリティが優先で、でもそれを一般コンピュータ利用者 に使わせるために必要なことに努力を惜しまないように、ということです。そ れが、ソフトウェア、それも言語やシステムよりのソフトウェアの分野では大 事だと思います。これは研究を推進する上でも直接的な効果があって、そうやっ て使い勝手のレベルが高いものを作ることでしっかりした実験ができるように なり、論文を書くときにも役に立ちます。そしてそこで見つかった問題点は、 次の研究ネタになり、処理系がしっかりしていればそれを拡張して次の研究の 効率が断然あがります。つまり研究成果の蓄積がきくわけです。

米澤研では先に上げたスレッドライブラリや、並列・分散GCを作って、世間に 配ったりしています。これはC/C++などのGCのない言語からライブラリとして 使えるというもので、C/C++で並列・分散プログラミングをする人はもちろん、 それを使って言語を作る人にとっても有用な道具です。それらは、1プロセッ サ向けのGCを元に学生が一人で作ったもの(並列一人、分散一人)です。

Q 研究室を目指す学生にひとことお願い致します。

とりあえずどの研究室にいってもいえることは、「自分で研究ネタを見つけ、 それを正当化(それをやることの意義を説明できるように)し、それを実現でき るようになること」が目標です。

研究と「与えられた課題」を同じだと思っている人は、まずそこでつまずきま す。もちろんいきなり研究ネタを自分で考えるなんて言うことは無理だから、 とりあえず最初は普通決められたネタで研究するわけですが、それを実現して いく過程で新たに生じた問題を心にとめて、「自分の問題」にしようとしない 人は、論文ひとつ書けといわれて書くことはできても、結局独り立ちはできま せん。

重要なことは、最初は与えられた仕事であっても、それをしながら問題を広げ る、新たな問題を見つける。そうやってその問題を自分の問題にしていく。そ して次の仕事をし、それをしながらまた次の仕事を見つける、ということだと 思います。卒論をやるときにも、まずはそのことを念頭において頑張ってくだ さい。

Q 情報社会についてひとことお願い致します。

携帯電話、PHSはいまだに持っていません(笑)。

 

〔トップページへ〕 〔「研究室紹介」のindexページへ〕
<vu@is.s.u-tokyo.ac.jp>

Last updated on 29 May, 1999