0xDEADBEAF

Ruby 会議 2010 が終わりました。 今年は、実行委員としてお手伝いさせてもらいました。 やっていたのは、中ホール番長と翻訳まわり。

参加するのは 2007 に はじめて参加してから 4年連続だったんだな。

参加する目的について

ここ 2, 3年は、日常であんまり Ruby のコードを書いてなかった。そんな自分が、 Ruby のコミュニティにできる貢献ってなんだろかなーと考えたときに、スタッフとして何かお手伝いする、というのがあった。 当日スタッフとして参加した Ruby 会議 2009 のスタッフ打ち上げで さんから「次は実行委員でよろ」と言われたとき、ん、やろうと思ったのであった。

とはいえ、 2009 年の秋から始まったスタッフミーティングにちょこちょこと顔を出していたんだけど、何かこう、うまく役立てていなかった。ぱりっとしない。自分のできることが増えていなかった。なんだか宙ぶらりんなかんじがしていた。

もやもやしていた冬の終わりごろに、「あ、スーパースター方面でよろ」と言われ、春の終わりごろに「そうそう、中ホールの番長になったから」と。これがよかった。 2007 年にはじめて参加したときから、発表中に IRC で野良翻訳していたし、ここ最近は国際学会にちょこちょこ参加していたので、だいたいの勝手は分かる。こういう風に振ってもらえたのはとても助かったなー。でもまぁ、自分からもっと動くようにしよう…

中ホール番長について

大ホールが日本語、分かりやすげなセッションが多かったのに対して、中ホールは基本的に英語でテクニカルなセッションだった。でもそれがいい。いいぞもっとやれ。 番長の仕事は、全体を取りまとめることと、司会。中ホールはこじんまりとしていてあまり会場での実作業はなく、身体的にはラクだった。司会は何をするかというと、発表者にマイクをつけてもらったり、何分しゃべるつもりなんやと聞いたり、雑談 (!) したりする。あと、発表のタイムキーパーをしたり、発表が終わったら質問を煽ったり、連絡事項があればアナウンスしたりといったところ。 中ホールは KaigiFreaks の , , さんとで基本的に回していて、 Q&A のときのマイク持ちや会場案内といったところで当日スタッフの担当の人たちに助けてもらっていた。みんなのおかげで、とてもスムーズに運営できていたんじゃないかなー。安定感があった。ナイスチーム!

スーパースターについて

スタッフで、翻訳というか海外勢まわり全般をやるひとを ☆スーパースター☆と呼んでいた。

会議前には、スライドに訳をつけていた。ぼくが担当していたのは、 Sound Programming のと Chad Fowler の基調講演のもの。特に Chad Fowler のスライドは、自分がつけたあとに、の手直しが入り、すばらしいものになったと思う。もちろん、元のコンテンツが素晴らしいのは言うまでもないのだけれど、その素晴らしいメッセージをより多くの人に届ける助けになれたかな、と思うとぐっとくる。というか、 Chad Fowler の発表中にぐっときていた。翻訳者はメッセンジャーだったんだな。

会議中には、会場横スクリーンに表示される IRC に、日→英、英→日の同時通訳をベストエフォートで。じっさい、聞き取れないところや、発表のスピードについていけないところはスキップしてしまうこともしばしばだったけれど、言葉のギャップへの架け橋に、多少なりとなれていればうれしいな。あと、「みんなオラに力を分けてくれろ」と書いていたら、会場の中から翻訳を手伝ってくれる人たち (野良スーパースター) が出てきたりして、やっぱりぐっとした。

ああそうだ、あと懇親会でぽつんとしていた海外からの参加者に酔った勢いでしゃべりかけていって、楽しい時間を過ごすことができた。懇親会で、けっこう日本人の集団と海外勢クラスタが分かれてしまっていて、まぁそうなるわなーと思いつつももったいない。もっとごたまぜになるように、動いてみよう。

来年に向けて

自分は技術方面の人なはずなので、ハックして技術発表する。 2008 で LT, 2009 で RT (Reject Talk) と発表はやってきたものの、対した技術の発表じゃなかったし、このまま終わるのはふがいない。今年は何の発表もせず、純粋なスタッフなだけだったけど、次は staff / attendee / speaker / sponsor の4タイトル制覇をしたい。あ、 committer もあればグランドスラムなんだな… どれだけ進めているだろうか。

というわけで

参加者のみなさまありがとう! スタッフのみんなありがとう! ホテル39#107 はいい思い出です。 Ruby のコミュニティは、感謝することが根付いているのがすごいと思うのでした。

ハックしよう!

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

スライドはこちら:

ビデオはこちら:

まとめテキストなどは、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 からの脱却がありそうなのだ。そして、まだ決定打はどこも出せていない。今がチャンス! なのです。デファクトをとって勝つる!

あした 8/27 から Ruby 会議 2010 がはじまります。ぼくはいちスタッフとして参加します。



主に中ホールというところの番をしていますので、見かけたら話しかけてやってください…!

---

これまでの Ruby 会議についてのエントリ:

2009:

• RubyKaigi 2009 Reject Talk 1
• RubyKaigi 2009 Reject Talk 2

2008:

• Ruby会議2008で話してみて
• Ruby会議2008を聴いていて

あるいは RubyKaigi タグ.

SIMD の練習がてら、 ARM NEON で画像の二値化を SIMD 化してみる。

元コードは、 実践! iPhoneアプリ開発 : カメラアプリの作り方 (4) – 写真にエフェクトをかける で、 RGB から Y に変換するところと、 UIImage とビットマップとをやりとりするところを流用しています。

SIMD 化戦略は、単純なピクセル並列。 RGBA 各1バイトのピクセルを複数ピクセルまとめて処理するだけ。スケーリングとかのアルゴリズムと違って、近傍のピクセルを考慮しなくてよいので、端の処理も気にしないで済む。

RGB は1バイトなんだけれど、 Y に変換する際に 1バイトで表現できる以上の整数値を扱うことになるので、2バイトの整数で計算する。なので8ピクセルの SIMD にしたのが以下のコード:

まぁ分かりやすい。

iPhone 4、 -Os、 2592×1936 な JPG 画像で試したところ、

• naive な実装 : 0.689s
• NEON SIMD : 0.613s

と僅差で勝利した.. 詳しく追ってないけれど、最後のメモリ書き戻しのところが遅そう。

あとはこれを VFP でもやりたいんだけど、ちょっとめんどうげな。最初に RGB を float に変換してしまって、 4並列の SIMD でやることになるかな。果たして naive な実装に勝てるんだろうか.. GCC/Clang こわいです。