0xDEADBEAF

6月のことですが、 HotPar ’10 というワークショップに参加していました。

ポイント:

• 逃げ場がないことのは大事
• ライブ感

HotPar とは

HotPar そのものについて。 Hot topics in Parallelism というテーマで、 2009 年からはじまった国際ワークショップです。いまのところ、2年連続でバークレーにて開催されています。 で有名なパターソンさんが取りまとめてる。

面白いのは、 参加するなら論文書いてこい というところでしょうか。手ぶらの参加はなしです。これは、コミュニケーションの始めやすさにつながっていてナイスだと思いました。採択率は、論文で 16/68、ポスターで 20/52。1st author 以外も来ていたので、けっきょく50-60人くらいが参加していた。

企業からと学生とが半々くらいで、学生の人たちはたいていどこかの会社 (Intel, Microsoft, EA, …) にインターンに行っていた。日本からはぼくだけ。

やるしかない

自分は、2009年の初回にふつうの聴講者として参加していて、今回はポスター発表するという位置づけ。2009年のときは聴くだけの立場でしかなくて、透明人間になったような辛さがあった。自分がどんなものを持っているのか、誰にでも分かるかたちで見せることができないとダメだと思ったものです。今年はそのリベンジ。世界で動けるように。

そういうわけで、論文を出し、けっきょくポスターとして通った。初日の最後に LT みたいにしてポスター発表者全員が30秒でポスター紹介をプレゼンする、という時間があり、短いながらも初めての英語スピーチをした。すごくあたふたする… いろいろ準備を考えるんだけど、けっきょくしゃべりだしたら思ってたことの3割くらいしか言えないものです。

そんな中で思ったのは、 逃げ場がない ということが大事なんだということ。ネットがつながらないから、心地良い外の世界に逃避できないし、自分しか日本語話者がいないから英語でしゃべらざるを得ないし、他にごはんの手段がないのでテーブルにつかざるを得ない。テーブルについたら、こちらから何もしゃべらないと1,2時間そのまま、というとてもしんどい状態になるので、なんとかして絡んでいくようになる。まぁそうはいっても雑談はむずいわ…

最初に話さないと、ずっと話さない。まず当たっていくことを心がけようとか。軽い話題 (いつから来た、どこから来た) から入って、専門分野の話 (何やってるの、何がいちばん難しい問題なの?) にもって行く、というパターンを覚えたりとか。

そもそも、自分はカンファレンスや勉強会に参加してもロクにしゃべることがなかったんだけど、ここ 2,3年の積み重ねでだいぶコミュ力が培われてきたんだなーという実感。

とはいえ、英語圏のパーティはやはりノリが違うし、まだまだむずいですね… 雑談力を身につけたい。 と同時に、自分の中に、じっくりと考えぬいたものがないと、けっきょくただのおしゃべりにしかならない。深みが魅力になる。やるべきことはまだまだ、まだまだある。

よかったこと

ポスターセッションは、一杯ひっかけながらポスターについてああだこうだと議論する、というスタイルだったこともあり、よく話せた。あまり考えずにしゃべるようになるというか、勢いづくというか。コミュニケーションツールとしてのワインとポスターというのがある。

あと、わりとアジア圏の研究者とはよく話したな。似たもの同士感があるんだろうか? 英語ラクじゃないよね、とか学校でたあとは国に帰るの? (No) とか、そういう話を夜遅くまでしていた。

チャレンジすること

話したものの、その場で終わりになってしまいがちなので、ネットワークを広げたい。たとえば、これに参加したあと、続けて ISCA ’10 というカンファレンスにも出席したんだけど、そこで「ああ、 HotPar でもいたよね、ひさしぶり」といった風に会話が始まることが2,3度あった。コミュニティによく出入りして、アウトプットを出し続けることだな。

あとは考える深さとスピード、雑談力, …

おもしろかったところ

その場でのコミュニケーション、によく気が配られていた。

ランチのときに、各テーブルにトピックがあって (並列デバッグどうやる? アプリはどんなのがある? どう教育する? などなど)、参加者はめいめい好きなトピックを選んで座る。で、ごはんを食べながら 1.5 時間くらいそのトピックについてしゃべる。このスタイルは、学会とか勉強会などで有効なんじゃないかな。初対面の者どうしが同席して話し始めるきっかけとして。コミュニケーションツールとしてのランチディスカッション。

あと、会場ではインターネットが使えない。 Wifi も電源も提供されていない。パターソン曰く「Wifi はここにはないよ。数百ドルも出して参加するカンファレンスで、席に座ってやっていることといったら話も聞かずメールチェック、ではなんとももったいないじゃないか。ディスカッションに参加しよう」。まったくだなー、と。ライブ感、参加している場にある価値といったものが、ネットで損なわれてしまいがちなんだ。

会場はちょっとダウンタウンから離れてるし、近くに店もなく、合宿みたいなノリだった。泊まった部屋もルームシェアリングになっていて、とにかくコミュニケーションが促進された2日間だったな。

ああ、ぜんぜん技術的なことを書いていなかった。主流は、 性能よりも生産性を というところにあったと思う。 100% カリカリに並列プログラムをチューニングするのはコストがかかりすぎるし、人にまるでやさしくない。 80% の性能しか出ないけど、人が考えやすいモデル、というのが今の方向性なんだろう。

---

出て行って交わると、自分の研究者としての能力がどれくらいか、というのがよく分かる。井の中の蛙にならないように、あっちこっちでアウトプットしないとだな。

さんに誘われ、 というセッションに登壇させていただきました。

スライドはこちら:

ビデオはこちら:

まとめテキストなどは、9月になったら…

---

2010-09-01 23:45 追記:

スライドと映像とでほとんどのところは言い尽くしているので、大事なところと端折ったところだけ。

メッセージはなんだったか

• マルチコア時代は、 JVM ベースの処理系が流行るだろう
• メニーコア時代は、メッセージパッシングが流行るだろう
• スレッドを生で使うのはない

順に見ていきます。

マルチコア時代は、 JVM ベースの処理系が流行るだろう

この先5年くらいは、まだマルチコアの時代のはず。メモリを共有するいくつかのコアがいる。そこで重要なのはマルチスレッドでの性能であり、そのあたりをきちんと面倒見てくれる JVM を土台とした言語処理系が流行ると見ています。 Scala, JRuby, Jython, Clojure, Mirah などなど。特に、なんでもあり過渡期言語としての Scala に期待があります。

メニーコア時代は、メッセージパッシングが流行るだろう

その先のメニーコア時代になると、 Memory Wall を崩せなくて、ソフトウェアはメッセージパッシングをベースにすることになると予想しています。 Scala や Erlang といったアクターモデルの並列プログラミングができる LL とか。 MPI は Fortran のごとくしぶとく生き残っていそう… とはいえ、これまでの考え方からのギャップがわりと大きいので、現実的にやるとすれば、いま使っているプログラミングモデルはそのままで、下ではメッセージパッシングで処理系ががんばって動く、という方向だろう。

スレッドを生で使うのはない

でまぁ、しばらくはマルチスレッドでプログラムは並列に動くことになるんだけど、スレッドを生で使い続けることはないだろう。これまで十数年とマルチスレッドプログラミングがなされてきたけれど、いまだに難しいとされている。これはつまり、人間には難しすぎるということだ。学会に行っても、けっきょく未解決問題として扱われているわけで、「難しい問題なら、解かずにおこう (そして研究のネタとして生かし続けよう)」というジョークがあるくらいだ。天才にすら難しいマルチスレッドプログラミングが、エンドユーザプログラミングの時代になんとかなるはずがない。スレッドはアセンブリのようなものなのだ。

そんなわけで、いろんな抽象が考えられている。 Grand Central Dispatch とか、まぁいろいろ。その中でも、メッセージパッシングが重要となるだろう。そもそも状態を共有するからマルチスレッドプログラミングは難しいわけで、状態を共有せず、逐一お互いの状態を問い合わせるようにするメッセージパッシングは、いまはまだ主流じゃないかもしれないけれど、この先はわからんものです。

いまがチャンス

並列コンピューティングが常識になった時代に、さすがに C でプログラミングし続けるのはないだろう。もはやパラダイムが変わってしまっているのだ。「過去の資産を活かしたい」とかよく聞くけれど、それはもはや負の遺産だったりしない? ごついふつうの C プログラムを、多大なリソースをかけて並列化するのは、なんともしんどいし、最初から並列に書いてしまう方がすっきりするよね。これから現れる21世紀プログラマは、さいしょから並列プログラミングしててもおかしくないし、むしろそうなってるべき。そんなプログラミングの世界を切り拓いていきたいものです。

新しいパラダイムには、新しいプログラミングモデルがあってしかるべきで、それはたぶん C じゃない。 C はアセンブリ的なものとして残るかもしれないけれど、並列に書くところは別の言語になるだろう。つまり、ついに C からの脱却がありそうなのだ。そして、まだ決定打はどこも出せていない。今がチャンス! なのです。デファクトをとって勝つる!

並列プログラミングカンファレンス、略して 並カン を開催しました。はじめてのイベント開催でどうなることかと思いましたが、とてもよい会になりました。

いまそこにある並列プログラミング

そもそも、なぜ並列プログラミングについて語るのか。この会をひらいた目的はなんだったのか。そのあたりについて話しました。

みんながふつうにつかっているコンピュータはすでにマルチコアになっていて、速いプログラムを書きたければ並列プログラミングをするしかない。富豪的アプローチもよいですが、ぼくは遅いプログラムがイヤなのです (これは自戒)。

たとえば。病床にいるとしましょう。もうそんなに時間が残されていない。夜になり、痛みで眠れない。唯一の助けは家族とのケータイによるメールだったりするのです。そんなとき、ケータイに載っているソフトウェアの動作が緩慢で、 UI のレイテンシがひどかったりするのは許せない。雷鳴が閃くかのように高速に走るコードを書き、ひとがコミュニケーションするじゃまをしない UI が実現できるよう、力を尽くしたい。

ん、なんだか話が逸れました… ともかく、並列プログラミングをふつうのプログラマも嗜んでないといけなくなりつつある。しかし、これまで並列プログラミングというと、研究者や一部の必要に迫られた人たちの分野だったりしました。並列プログラミングについて、ふつうのプログラマがカジュアルに話す場ってまず見ない。んじゃひとつ、そういう場をこしらえてみよう、というのが今回の並カンをやった目的だったのでした。

まぁ、「並列プログラミングしているひと！」と聞いたときに、半数以上の方が手を挙げてくださったときにはたまげましたが。

みなさんの発表

ハードウェアから独自言語まで、という幅の広さでした。いずれも浮世離れしたものではなく、現実世界の問題を解決するための話だったのがとてもよかった。

• 並列プログラミングのおさらい ()
• ()
• STM ()
• ()
• ロックフリー ()
• Haskell ()
• 東京 Ruby 会議 03 ()

終わったあとに、「最近のライトな勉強会のノリじゃなく、ひどくテクニカルなところがよかった」という声をいくつかいただきました。発表に名乗りをあげてくださったみなさんのおかげです。クオリティたかい!

特定分野に偏らず、多様な話をまとめて聴けたのはよかったんじゃないかな。分野のまたがりはゆるく、技術的には深く。ぼくはとても楽しめました。発表の途中に質問をはさむ、という主催者の特権を乱用したりして。会場の雰囲気、 Twitter のまとめ を読む限りでは、なかなか盛り上がっていたようでした。

運営、スタッフ、課題

当日に至ってもほとんど計画のないままで、まったくどうなることかと思いました。これはひどい。無事に終えることができたのは、頼りないぼくを見かねて助けを名乗り出てくださったみなさんのおかげです。

• 会場を提供してくださった さん。会場の張り紙準備やプログラム、設営から片付けに至るまですべてやってもらってしまいました。
• 最初の会場設営から懇親会幹事までずっと手伝ってくれた さん。
• Ust のクオリティをあげてくれた さん。
• 寒い中、休憩時間のたびに門を開けに行ってくれた , さん。
• 突発的に手伝ってもらった , さん。

みなさんが自ら動くことでイベントが組み上げられているのをみて、まじめに感動しました。レベルたかい!

課題は山ほどある。やってみて初めて気づくことというのがありますね。

• ちゃんとしたプログラムがなかった。終わる時間がのびてしまったのはまずかった。
• ひとつひとつのセッションがちょっと長かったかな。おもしろい話ばかりだったので、短くするのもつらいところ。時間をちゃんと区切っておけばよかったんだろう。
• 当日やることは前日までに洗い出しとかないと。
• atnd はやはりつらい。キャンセル率は、だいたい予想どおりだったのでよいのですが、全員に告知する方法がないのが致命的。 twtvite とかがよさそう。
• Ustream。事前にお伝えしていれば、ちゃんとした方法で中継することができた。マイクは必須ですね。あと、録画しわすれてた。次は Ustream Producer を試そう。
• wave はあまり使われなかった。勉強会といったチーム作業で威力を発揮するだろうと踏んでいたんだけれど、まだまだ市民権を得られていない。

次に何か企画するときには、このあたりを踏まえて精進します。

次回

終わってから、「第2回も楽しみにしてます！」といった声をいくつか見ました。むむむ… ので、投票いただければ。

やるとしたら。今回は並列プログラミングの話題を中心にしましたが、 Web の世界のような分散システム、並行プログラミングについての話があればよいな。みんなが実際に手を動かすワークショップもいいですね。あとぼくも例のやつについて続編をしゃべります。

いずれにせよ、おもしろ発表者が幾人か集まれば開催したいとおもいます。

---

Happy Parallel Hacking!

113人もの注目をあつめている並カン ですが、日時と場所が決定しました。

• 2010/01/31 13:00 to 18:00
• IIJ 本社
• 懇親会の atnd もつくっておきました ので、並列トークに花を咲かせてみるのはいかがでしょうか。

atnd には全員に連絡する方法がないので、ご友人ご同輩で参加される方がいらっしゃれば、 atnd ページ を日々チェックするようお伝えいただければ幸いです。

詳しくは atnd で!

---

これまでのポスト:

• 並カン

atnd::並カン

世の中はすでに並列コンピュータだらけなのに、並列プログラミングはまだあまり浸透していないように見えます。アカデミックな世界では、並列プログラミングは長い間研究されてきたわけですが、エンジニアがいる開発の現場ではまだまだふつうの直列プログラミングが大多数。スレッドこわい! Perfume Locks!

そんなギャップを埋めるには、並列プログラミングについて語り合う場があるといいんじゃないか。ということで、並カンをやってみようと思いました。学会よりは勉強会に近いノリをめざします。 12月中旬から1月下旬のあいだです。お誘い合わせのうえ、おこしください。

いちおう Twitter をつかったアプリ (その1、その2) の作者なので、参加資格はあるだろう。 ということで、 Twitter Developers Meetup in Tokyo のために原宿まで行ってきました。原宿というのはおそろしいところですね。

さいしょの説明セッション中では、iPhone アプリ開発者仲間4人で最前列に座り、態度大きめで話を聞いていました。あまり目新しいことはなくて、

• Location
• ReTweet

を開発者に提供していきますよー、というところで終わった。 あと、US では頻繁にこうした Developers meetup をやってるけど、国外でこうしたことをするのは初めての試みで、世界中の開発者とうまくやっていきたいんだよねー、と。

もちろんそれだけじゃつまらないので、質疑応答のセッションに突入したらみんなによる質問の集中放火状態だった。まぁでも、彼自身はプロキシみたいなものだからあまり面白い答えを引き出すことはできなかったんだけれど。 US の meetup だと、各チームの人間がいるだろうから、より中身のあるディスカッションができるんだろうな。

Twitter 自身に、これ以上機能を加えてもらうのは特に望んでいなくて、ただ安定した、より自由に (たくさん) 使える API を提供してもらえれば、あとはこっちでいろいろ遊ぶから、と何人かの人が言ってたのが印象的だった。インフラとして安心してつかえることが求められている。 Twitter は場なんですよね。今回の Meetup でもそうで、開発者どうしが交流する場を提供してもらえるのがありがたいわけで。

どんどん、知らないひとたちとのつながりが大きくなっていけばいい。

FLTV に参加して、 並列に動かす何か というタイトルでしゃべらせていただきました。 主催者の さん、会場提供のチームラボさん さんありがとうございました。チームラボの環境ナイスでした。

ぼくの話は、いまつくっている並列プログラミングのための何かについてのものでした。 SWoPP 2009 で話した内容そのままですが、日頃あまり並列プログラミングについて考えることないなー、といった方にも興味を持っていただければ、という。

WEB+DB PRESS vol 52 でも takiuchi さんが並列プログラミングのイントロを書いていたり、ちょうど前日に行われた LLTV でも並列プログラムのデバッグ方法について語られていたようで、じわりじわりと並列プログラミングがその地獄への穴を拡大してきているように感じます。 ranha さんは未来なんてない! と叫んでおられましたが、近未来は並列地獄なのかもしれません。

そんな中で、「性能が足りなければハードを買ってくればいいじゃない」というだけでなく、もう少しソフトウェアにできることを考えてみたい。また、単にハードウェアを買い足すだけで性能がそれに応じてスケールする、というそのメカニズムについて、秋の夜長に思いを馳せてみるのはいかがでしょうか。

---

他の方の発表を聞いていて思ったのは、ただのテキストファイルに、よくこんなにもたくさんの意味を持たせるなープログラミング言語というのは、ということでした。解決したい問題の多様さと、自分の意志を実行可能な形式に落とすための表現力の幅の広がり。 ここ最近では、プログラミング言語なんてどれも大差ないよねー、もとい、同じパラダイムのプログラミング言語ならどれを使ってもその表現力はオーダーが変わるほどじゃないと思うようになってきています。定数項にすぎないだろうと。 それでもなお、こんなにたくさんの表現方法がある、というのはなんなんだろうねと思わされました。 言語が思考を規定する一方で、思考のレベルで言語を使い分けるというのもある。 自分の伝えたいアイデアやメッセージを、かんたんに、正確に、美しく、聞き手が分かるように、伝える方法をずっと探しているのかな。

あと未来では脳直結プログラミングができるようになるからプログラミング言語いらなくなるよ説についてその後考えてみたんだけれど、考えた軌跡としてのプログラムというものを残すためになんらかの言語は残るんじゃないかなと。

そこに残るのは結局 C なのかもしれない。

---

ふまじめなまとめ

• “継続とは、一言で言うと、死亡フラグのことです”
• 未来派言語使いは Haskell / C++ ラバーが多い模様。どっちも東西の横綱ってかんじするものな
• 未来派言語使いはのんびりしゃべる、というかマイペース
• というか未来なんてない

RubyKaigi 2009 の2日目、 Beer bust 片付けを終えたあと。なんか無性にこの昂りをつたえたくて RejectKaigi キャンバスにふせんを貼っていた。

電波にあてられて、3日目の RejectKaigi 直前につくっていたスライドが以下のもの。 RubyKaigi スタッフになるのおすすめだよ! という勧誘でした。

終わってみると、ひたすら「ともだちほしいんです!」「ともだちできました!」と連呼する稚拙な発表になってしまい、72時間は自己嫌悪から抜けられませんでした… なんか自分の話ばっかりしてしまった。これはひどい。

たしかに、輪の中に入ろうよ! ということも伝えたかったことのひとつだったんだけれど、それよりももっと伝えたかったのは、こんな nice なチームがあるんだということを中に入って体験してほしい ということ。そして、あなたが RubyKaigi というこの場、Ruby という不思議な魅力をもつ何かのためにできることがここにもあるんだ 、ということです。

nice なチームといっしょに働くことは、自分が nice なチームをつくるための第一歩になるんじゃないかと思うのです。 nice であるというのはどういうことなのか、体験できる機会はなかなかない。 RubyKaigi スタッフとして活動するというのは、そういう貴重な機会に飛びこめるということなのです。

ん、RubyKaigi スタッフをやらせてもらって感じたことは、また別のエントリに書きます。

---

スタッフなのに2日連続で RejectKaigi でてしまってほんとすみません ＞＜ 来年はテクニカルなセッションでしゃべります ＞＜ 翻訳もがんばります ＞＜

UI特集というのに釣られて builder techday に行ってきました。

ソシオメディア の人による基調講演がよかった。ユーザにとってはUIがすべてである。

よいユーザインターフェイスとは、自然で気づかれないもの。なので評価もされにくい。

あの機械のUIはサイテーだよね、とかあのソフトのUIはなんであんなことになってんのか理解できねえ、とか言う声はよく聞きますが、じゃあよいユーザインターフェイスってどんなのがあるの? と言われると困ってしまう現象の正体ですね。

あと、ソシオメディアのサイトには iPhone 用のものがあり、そこのツールバーには電話、地図といったユーザがまず使うであろうショートカットが用意されている。あれは実に気がきいてる。 個人のサイトだったら、メール、Twitter ID にreplyするためのリンクなんてのがあればいいのかもしれない。

その他、マイクロソフトの人による「なぜOffice 2007ではあのようなツールバーになったのか」話やAdobeの人によるAIR話なんてのがありました。パネルディスカッションはZDNetとCNETの中の人たちによるサイト構築のあれこれ話だったんですが、なんだか内輪の話っぽくて距離感を感じたり。

---

デザイン主導開発ってのはアジャイルにあるまずユースケースを描こうよ、みたいな話ですよね。 プログラマの視点だとつい機能面からつくり出しがちなんだけど、そこを一歩引いてユーザ目線でつくりはじめること。 できてるかな? んー、まだまだか…

秋刀魚を食べながら まとめ買いしたGithub Tシャツを受け渡しするの会、通称 秋刀魚.git をやってきました。ことの経緯はこちら。

最初はどうなることかと思いましたが、 さんや さんをはじめとした炭職人の奮闘のおかげもあり、16匹の秋刀魚をたいへん美味しくいただけました。秋バンザイ!

参加してくださった方々:

半分がはじめて会う方、とかいかにもTwitter時代を感じます。

けっきょく秋刀魚に必至で LT の時間を設けるのをすっぱり忘れてしまっていまして、Github Tシャツをトリガーにした秋刀魚を食べたい若人たちの群れになり下がってしまってました。まあ、たまには昼から外でテクトークとか非テクトークとかを飲みながらしてもいいじゃない。

今回、はじめてこうしたイベントの幹事をやりました。4年前に社会人になった頃、ひっこみ思案だったのが嘘みたいですね。

よかったこと:

• みんな協力的だった。自分ひとりじゃとてもまわせない
• 呑む前に会費を徴収した。 さんのアドバイスによる
• 電話番号交換をしてるひとが何人かいた。Twitterによる連絡だけでは心もとなすぎる

改善ポイント:

• 連絡が直前すぎた。もっと早めに動いて決められるとこを決めてしまったほうが、みんな参加の意思を決定しやすい
• 優柔不断的だった。みんなの意見は聞きつつも、ずばずばっと決めてしまったほうがよい場合もある。仕切り力をつけねば
• 秋刀魚&ビールに夢中でいろいろと仕切るのを忘れがちだった。自己紹介タイムが遅れた
• 大根まるまる一つはでかすぎた。あと下ろし金わすれてきたとか

---

、 さんの奥様によるおにぎりが、間をつなぐhubとして機能していました。 さんの奥様においては、Perler B’z というかわいらしいおみやげの品を全員に用意してくださるという女子力っぷり。

エピソードつき七輪を担いできてくださった さん、すばらしい炭の火おこしに貢献してくれた さん、そして場をつくってくださったみなさん、ありがとうございました。 炭があとはんぶん残ってるので、またやる?