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

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

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

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

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

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

みなさんの発表

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

• 並列プログラミングのおさらい (@wraith13)
• FPGA/HDLを活用した ソフトウェア並列処理の構築 (pdf) (@goyoki)
• STM (@hayamiz)
• MUDA (@syoyo)
• ロックフリー (@yamasa)
• Haskell (@shelarcy)
• 東京 Ruby 会議 03 (@ayumin)

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

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

運営、スタッフ、課題

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

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

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

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

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

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

次回

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

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

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

Happy Parallel Hacking!

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

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

詳しくは atnd で!

これまでのポスト:

• 並カン

いつものように、一年をブログエントリでふりかえってみたいとおもいます。

• 1月 : ようやく Milpon をリリース。半年ちかくかかりました。
• 2月 : ばたばたしていてエントリなし
• 3月 : Ditz on Ruby 1.9 というクイックハック。
• 4月 : ToddleDatabase という、 iPhone 用の SQLite ラッパを書いていました。
• 5月 : Milpon 2.0 をリリース。こうやって見るとペース遅いですね…
• 6月 : WWDC で情報がでてきた GrandCentralDispatch を調べていました。
• 7月 : RubyKaigi2009 で当日スタッフをやり、 RejectKaigi で2本しゃべらせてもらいました。しゃべるたびに凹む…
• 8月 : SWoPP にて Molatomium を発表。 FLTV にて Molatomium のさわりをしゃべりました。
• 9月 : 読書会を3つほどはじめて首が回らなくなり始めたころ (PLDIr、鈍器の会、 CTMCP)。論文とか原稿など、日本語を書く仕事が増えてきていました。
• 10月 : 気晴らしに、 Aaron Swartz さんのdjb というエッセイを翻訳していました。
• 11月 : 気晴らしに、 並カン をやろうと思い立ったら、あんがい人が集まってしまったという。
• 12月 : 日経エレクトロニクスに Molatomium の記事がのった ことで、ひと区切りついたかなというところですね。

iPhone アプリづくりと並列プログラミングの研究活動を主にしていたようです。コードよりも文章を書いている時間が多かった。バランスを取り戻さないといけませんね。

今年はあまりブログを書いてませんでした。小物をあまりつくらなくなったからでしょうか。アウトプットが少なくなった。大物をつくるにしても、こまめにアウトプットしていくほうがよいですね。ふむ。

2008年のふりかえり にて、大物に取り組もう、メディア力を伸ばそう、という目標がありました。この2点についてはまずまずの成果。年初に「変化の年にする」と書いたのですが、この点についてはいまひとつ。

2010 年は、小さなイテレーションを繰り返すことで大物にとりくみ、変化を生み出そう。

Analytics

2008年との比較

さすがにさびれが見えますね..

去年までのふりかえりはこちら:

• 2008年のふりかえり
• 2007年のふりかえり

よいお年を。

21世紀テレビ もそうですが、 IT 関係だけでない人々にとってわかりやすい形をしているアウトプットを出せるということが、今取り組んでいるプロジェクトのいいところですね。電気屋とか書店とか、遠くに居る家族にも伝えやすい。

父親に見せてあげたかったなと。会社のニュースが出るたびに、新聞を切り取ってスクラップしていた父。 Milpon が出た当初、すこしの間だけだけど一位になっていたのを病床で見せたら、とても喜んでくれて、意識が朦朧としているなかで何度も「おめでとう」と言ってくれていた。母は明日、近所でいちばん大きな書店に買いに行き、仏前に置いてくれるそうです。正月に帰ったときにまた報告しよう。

話をもちかけていただいた編集の方に感謝です。自分で書いた悪文がすっかり読みやすい文章になっていて、さすがプロ… と感嘆しました。ずっと一緒に開発をしていた仲間のみなさま、文章にたくさんのダメ出しをしていただいたみなさまのおかげで、なんとか出せました。ありがとうございました。

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

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

gist においてあるので、こうした方がよいよ、とかあれば fork して書き換えてください。 gist は web インターフェイスだと差分がみれないんですねぇ… git でとってきたら見れるんだろうけれど。

あわせて読みたい: djb products のコード (読んで、その美しさにふれてみる)

Aaron さんにメールして、訳したから公開してもよい? と聞いてみたら、「もちろん! 原文へのリンクさえつけてくれればよいよ」と、すぐに快諾してもらえた。簡潔でナイスでした。

追記 (2009-010-27 01:34 JST): Aaron さんのサイトでも、公開されました。すごいすごい。

Programming model for a heterogeneous x86 platform (PDF は Google Scholar したら見つかります)

みどころ

• ついに Larrabee のプログラミングモデルが !
• ヘテロプロセッサ環境で共有メモリ
• おどろきの統一的プログラミングモデル

背景

GPU が柔軟で強力になってきました。 Intel も近い将来に Larrabee という GPU のようなものを出します。 CPU がスカラ計算を得意とする一方で、 GPU は大量のデータに一気に同じ操作をするといったベクトル計算が得意です。 じゃあ、 CPU と GPU とで、お互い得意なことを協調させれば速いプログラムができるよね、という流れがはじまって久しいです。最近だと CUDA とか OpenCL とかが有名どころですね。このように、いろんなアーキテクチャのプロセッサがまじっているのをヘテロプロセッサ環境といいます。

でも、 CPU と GPU はぜんぜん ISA (Instruction Set Architecture) が違うから、別々の考え方でプログラムを書くことになります。また、それぞれがもっているメモリが独立しているので、いちいちデータ転送のためのコードを書かないといけません。それぞれのコアで扱えるような形式でデータを組み替えてあげる必要もあります。要するに、めんどい。

そこで

ほとんどふつうの C プログラムで、ヘテロプロセッサ環境のプログラムを書けるようにするよ! (特に x86 CPU + Larrabee 環境向け)

• 共有メモリ が使える。異なるアーキテクチャでも、同じコードで共有メモリ領域にアクセスできる。差異はランタイムが吸収
• 共有メモリにあるデータは、型修飾子 shared をつけて表す
• 共有メモリと、プロセッサローカルなメモリとの間のコピーは、単にキャストして代入するだけ。つじつまはランタイムがあわせる
• Larrabee コアで動かしたい関数には、アノテーションをつける
• 異なるアーキテクチャの関数呼び出しは、ランタイムが RPC として実行する
• 共有メモリを使うので、いちいちデータを組み替える必要がない

驚きのサンプルコード、実装の詳細については原文をどうぞ。

疑問

共有メモリなので、同時アクセスする際には排他制御しないといけないと思うんですが、ロックをどうするかとか書かれていませんね。自動的になされるのかな。

まとめ

ヘテロマルチプロセッサ環境向けの、共有メモリをつかった単一的プログラミングモデルのお話でした。 Larrabee は、どうやってプログラミングするのかなー、 Ct とかなのかしらん、などと考えていた想像の斜め上をいく感じですね。

練習問題

Larrabee と似た構成のアーキテクチャに、 Cell プロセッサがあります。ここで紹介したプログラミングモデルを Cell プロセッサでも使えるようにするにはどうしたらよいでしょうか?

1.6 での変更は、 following と follower を間違って取得していた問題の修正で、 1.7 での変更は Growl サポートを入れたことです。

Growl をアプリでサポートするのはわりとかんたんで、

1. .plist を書く
2. 通知 API を呼ぶ

たったこれだけで OK 。なのだけれど、 QSTwitter みたいなプラグインで Growl を使うにはそこまでかんたんでなく、以下のような手順になります。

1. .plist を書くかわりに delegate を実装
2. 通知 API を呼ぶ
3. Framework のライブラリパスを @executable_path から @loader_path に変える

3つめで1時間ほどハマってしまいましたが、 install_name_tool というものを使えば OK でした。

% install_name_tool -change \
    '@executable_path/../Frameworks/Growl.framework/Versions/A/Growl' \
    '@loader_path/../Frameworks/Growl.framework/Versions/A/Growl

プラグイン (bundle) は、アプリケーション本体のパスと別のところにあるため、 @executable_path ではまずいわけですね。また、バイナリ配布されている Growl.SDK は @executable_path でビルドされているため、 @loader_path を指定してやらないとプラグインからはそのままでは組み込めない、と。

参考

• Growl – Developer Documentation
• HMDT Apr 2007
• Cocoa builder

@cesare さんと、 Introduction to Algorithms という殴ったら人の命がなくなりそうなほどに分厚い本を読む会を始めます ( ML )。 アルゴリズム ・イントロダクション の原書ですね。

まず方針など決めましょう、ということで第0回のミーティングを、女子ファッションのフロアしかない新宿マルイ上のスタバでやってきました。 最初に、各自のこの本を読むにあたっての目標を明確にして (基礎から CS 学びたい (@cesare)、アルゴリズムコンテストで泣きたくない (@mootoh))、以下のような進め方でやることになりました。

• 毎回のゴール: 各自が、自分なりに理解すること。理解できないとやる意味ない。
• 2週に一度、2時間くらい。50ページくらいずつを、全員が読んでくること。練習問題は分担する。
• 場所は新宿あたり(もうちょっと西でもベターでございますよ)。
• アウトプット: 特にないけれど、練習問題の解答や本文中のコードを好きな言語で実装してみるとかやってもよいですね。
• あとはやっていくうちに適宜、軌道修正。

そんな感じで、第1回を 10/1 (木) 19:00-21:00 でやります。 さてさて完全読破なるか。

ぼくは数ヶ月前に 2nd edition を購入したのですが、 @cesare さんが 3rd edition を持ってきてたまげた。章立てはぱっと見変わってないけれど、 ChangeLog によると、2章を削って2章加えた、みたいなことが書いてある。

Introduction to Algorithms, Third Edition

posted with amazlet at 09.09.15

Thomas H. Cormen Charles E. Leiserson Ronald L. Rivest Clifford Stein
The MIT Press
売り上げランキング: 14237

Amazon.co.jp で詳細を見る

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

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

• Location
• ReTweet

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

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

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

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