【しばらく編集不可モードで運営します】 編集(管理者用) | 差分 | 新規作成 | 一覧 | RSS | FrontPage | 検索 | 更新履歴

TenQuestionsWithJoeArmstrong - 並列プログラマに 10 の質問 - Joe Armstrong さんの場合

目次

並列プログラマに 10 の質問 - Joe Armstrong さんの場合

この文書について

並列プログラマに 10 の質問 - Joe Armstrong さんの場合

この記事は "並列プログラミングのアイドルに突撃インタビュー!" シリーズの第一弾です. 今日のお相手は Joe Armstrong さん. プログラミング言語 Erlang の父です. いまは Ericsson で働いています. Ericsson はごく初期のバージョンの Erlang を設計しました. (ずっと昔, 1986 年のことです.) 彼は "Concurrent Programming in Erlang" の共著者でもあります. この本は古くなってしまいました. しかし喜ばしいことに, もうすぐ彼の書いた新しい本が一冊でます. Pragmatic Programmers シリーズから, 今度は彼が主著者です. "Programming Erlang: Software for a Concurrent World" . (Amazon でも予約できます.) 本を書いたり言語を発明する傍ら, 彼は Erlang の授業をしています. また計算機科学の博士課程に進んでいます. Erlang を使うスタートアップ企業を興したり, 自動車で遊んだりもしています. そんなに色々やる時間をどこから捻出しているのか, 私にはおどろきです:D

さて, 前置きはこのくらいにしてインタビューを始めましょう. 最初の 5 つの質問は, 並列プログラミング全般に関わるものです.

Michael: メニーコアの時代が始まりつつあります. あなたは並列計算が世の中の主流として受け入れられると思いますか? それともこれは一時的なものにすぎず, 並列計算に興味を持つのは (再び) HPC 分野の人々だけになるのでしょうか.

Joe: なるよ. 主流になるにきまってる. なにしろ性能が, デュアルコアなら二倍, クアッドコアなら四倍になるかもしれないんだから. 32 コアで 18 倍高速に動くプログラムを書いたことがある. これは 18 倍だ. これまで私達は 5% から 10% の高速化のために アプリケーションのコードを部分的に書き直そうとしてきた. 400% や 1800% じゃない. これはどのソフトウェアにも影響のある話なんだ.

Michael: 今日まで, ある白熱した議論がネット上で続いています. 共有メモリ(shared-memory)を使うのと メッセージ通信(message passing)と, 並列プログラミングをするにはどちらが優れているのかという議論です. あなたの意見を教えてください.

Joe: 共有メモリのシステムを理解して正しく動かすのは難しすぎる. 無理だよ. エラーが起きた時は特にね. エラーがなくてもまずいけれど, エラーがある時のことは考えただけでも致命的だ. あるプロセスが共有メモリをロックして刺さったままクラッシュしたとする. この困った事態に, 他のプロセスはどうやって何がおきたかを知り, 事態を復旧できる?

トランザクション・メモリや純粋なメッセージ通信には, こうした問題が何もない.

Michael: あなたから見て, 最近の並列プログラミング分野でもっとも面白い進展や発明は何ですか? 現在進行中のものや, ここ数年のなかでは.

Joe: P2P のアーキテクチャはいいね. 分散ハッシュテーブルや, 地球規模でのシステム統合も面白い. planet lab とか.

bit torrent のようなものは既存の産業をぶちこわしている. 1770 年代にジェニー紡績機が家内製の紡績業を破壊した. それと同じことを bit torrent はレコード会社にやっているんだ. 事が起こるかどうかは問題じゃない. いつ起こるかが問題だ.

Michael: 並列プログラミングの未来はどちらに進んでいますか? その向こうに "銀の弾丸" はあるのでしょうか.

Joe: あるとも. 純粋なメッセージ通信のインフラ(amazon の simple queue service みたいの)は 多くの問題を解決するだろう. Paul Morisson の flow based programming まで さかのぼるわけだ.

Michael: もっとも深刻な問題のひとつは, 並列プログラミングが直列的なものと比べて 難しく, 非生産的であることだと見られています. これを変える方法があると考えられますか.

Joe: 別に難しくないよ ... 難しいのは世のモデルがロックやスレッド, 共有メモリを使っているからでしょ. それだ 難しいよ. 純粋なメッセージ通信なら, プログラムするのも理解するのも簡単.

世界は並列なんだ. ... 僕達は並列なんだよ.

...

前半は以上です. ここからは後半, Erlang についての話に進みます.

Michael: 他の並列プログラミング・システムと比べたとき, Erlang 固有の長所と短所はなんですか? どこを改善していきたいですか?

Joe: 利点からいこう. フォールト・トレラントなシステムを作るために設計されていること. おかげでソフトウェアやハードウェアの異常があった時にうまくデグレードできる. 異常事態を真面目に扱っているんだ. プロセスや異常処理は言語の一部として定義されている. なにかと OS を頼りにはしない.

弱点. 分散 Erlang には有りか無しか(all-or-nothing)のセキュリティしかない. 異なるレベルのセキュリティや機能設定(capacity), 信頼ベースのセキュリティモデルがあると良いだろう.

Michael: もしあなたがスクラッチから Erlang を再設計できるとしたら, どこを違うものにすると思いますか?

Joe:

Michael: Erlang でプログラミングをしたいと思っている人におすすめのツールは 何かありますか. IDE, エディタ, デバッガ, プロファイラ, 正当性検証などはどうでしょう?

Joe: ないね ... 楽しみのうち 95% はコンパイラさえあればいけるよ. それから人は IDE とかにはまりだすんだ. 僕はというと, emacs と make と xterm を使っている. ポチっとクリックする類のものが好きな人もいるけれど, ほとんど経験がないのでなにもいえないね.

Michael: Erlang 初心者のプログラマへ, 勉強を始めるにあたってのアドバイスをおねがいします! どう手をつければいいでしょう. 本やチュートリアル, インターネットの情報は何かありませんか? それと質問をするのに一番いいのはどこでしょうか.

Joe: 本は(厚かましいけれど)私の新刊がおすすめ. もうすぐ出るよ.

Michael: あなたが Erlang のプログラムを書く中でやってしまった, 過去最悪の失敗は何ですか?

Joe: 文書の無いプログラムだな. 僕は "コードを読め" というのが嫌いでね. コードは問題の "解法" だ. コードを読むときは, 問題が何だったかを "推測" しないといけない. これは間違いやすい. 問題は教えてもらえる方が嬉しい. 推測するんじゃなくて.

だから最悪の失敗はこうだ. 私は複数ページにまたがるコメントを書いたことがある. プログラムの特別トリッキーな部分を説明するものだった. でも後のバージョンで, そのコメントは誰かに丸ごと消されたよ. そんなもんだよな.

Michael: インタビューは以上です. お時間をいただきありがとうございました.