0xDEADBEAF

(つづき)

11/8 から、 San Francisco で働いています。 会社の日報に「あっちに行きたい行きたい」と2日連続で書いていたら、「じゃあ2週間後からよろしく」という流れで決まった。動きが早い。 10月からの新しい生活にも少し馴染んできて、本も出て、引越しもようやっと済んだというタイミングでの US 行きというドタバタ展開ですが、またとない機会を活かしてがんばろー。

でまぁ、飛行機から降りたその足でオフィスに直行し、仕事などしている… 広いワンフロアに全従業員がいて、わいわいしながらやる雰囲気が斬新だわー。これから楽しくなりそうです。

10/1 から、初台の DeNA でソフトウェアエンジニアとして働いています。早いものでもう一ヶ月が過ぎた。

何をやっているか

スマートフォンなモバイルでソーシャルなウェブ、というカタカナだらけなことをやっています。これはなかなか親には説明しづらい。 これまで個人活動でやってきた iPhone アプリ開発の経験を買われたのだと思います。いろいろやっとくもんだ。 入って1週間くらいコードを眺めたあと、さっそくモバイルデバイス側、ウェブサーバ側の両方のコードをばきばき書いてたら10月が終わっていた。

何をやろうとしているか

そもそもなぜ入ったか。会って話した人からよく聞かれて、「あまり考えてなかったんだよねー」と答えてたんだけど、多少は思うところもあった。

まず、最先端にいたいというのがある。いまぼくが見えている範囲でいちばんエッジなのは何かというと iPhone をはじめとするモバイルであり、ソーシャルウェブだろうと。思えば、前の職に就いたのも、当時の最先端だった Cell プロセッサの開発ができるから、というのがあった。エッジの効いたところには、尖ったひとが集まるわけで刺激的に違いないと。

次に、やっぱり世界を少しでも良いところにしたいというのがある。 たとえば、うちの両親くらいの歳のひとが、日々何をして暮らしているかというと、起きている時間の半分くらいがテレビをただ見ているだけだったりする。たしかに、外に出てアクティブに活動する、というのはちときついだろう。それでも、ただ流れてくる情報を流すパイプなだけで、やっと手に入れた平穏な日々を過ごすのはちょっとなんだかなとずっと思っている。

人は、人とのあいだで暮らすのが何よりの楽しみだろう。大昔から。それを現在のテクノロジーでできることにもってくると、モバイルなソーシャルウェブになる。生のコンピュータだと、みんなが使えるわけじゃない。でもいまやケータイは老若男女ほとんどが日々つかっている。そのケータイでつながっているのは、家族や近しい友だち。そんなふうに、みんなが日々を過ごす場をつくれればなと。そこで交わすコミュニケーションは、まだ何がよいのかぼくには分かっていないんだけど、そのあたりはつくりながら手探りだなー。

会って話した人からは、「これまでやってきた専門と全然ちがうじゃないの、もったいなくない?」と言われることも時おりあります。でもまぁ、いろいろやった方がおもしろいんじゃないですかね。人生短いし。

pros/cons

何がよいかというと、オーバーヘッドが少ないところ。導入研修もわずかで、ミーティングも長くて30分、きっちりゴールがシェアされた状態で始まる。割り込みも少ないし、コード書きに集中できる。集中しすぎてへろへろになりがちなのが玉にキズではあるけれど… また、戦略が明快なのもよい。仮説、実行、検証が板についている。

逆に、何とかならんかなーというと、やはり街中なのがしんどい。朝の通勤ラッシュとか、散歩しようにも周りがクルマだらけである。あとランチが都心価格..

---

つづく。

関連エントリ

• 退職しました

10/22 に発売される、 の一部を書きました。

目次 でいうと、

• 1-4 : class-dump
• 3-27 : dlopen
• 4-[28..34] : パフォーマンスチューニング
• 6-41 : Grand Central Dispatchによる並列処理

といったあたり。低レイヤ色が濃い… 需要あるのか…

ぼくの書いたところ以外でいうと、アプリの出来を左右する隠し味を加える方法が散りばめられていて良い感じです。 まえがきにもあるように、「ああ、このアプリのこの機能、どうやって実現してるんだろ…」と stackoverflow や Apple の DevForum を探しまわる手間、を少しショートカット出来るのではと思います。あと、全体で180ページとコンパクトにまとまっているので、モビリティもばっちりですね。

主著の sonson さん、 UICoderz のみなさま、長い間おつかれさまでした。慰労会しましょう。

---

2010/9/30 で、株式会社東芝を退職しました。

6年半何をやってきたか、少し振り返ってみます。

最初

組み込み機器向けソフトウェアの先行開発をする部門にいました。組み込み機器といっても、いわゆる黒物家電で、 Cell プロセッサを使ったものや、コンテンツ再生機がターゲットです。

最初にアサインされたのは、画像処理アルゴリズムを Cell で速く動かす、という仕事でした。それで、こういうものができた。

(画像は AV Watch の記事より)

Cell に本気出させたら何ができるか、というものでした。当時は F1 というプロジェクト名だった。これは後に発売される CELL REGZA のマルチチャンネル表示につながったそうな。

ここで学んだのは、「少数だけど精鋭がチームを組むと、不可能としか思えないことも実現できる」ということでした。性能の見積もりはぎりぎりいけるだろうレベル。しかしプロジェクトの期限は1ヶ月で、手持ちのコマはばらばらのパーツのみ。実担当は2人。それでも、毎日力を出し合って、周りの優秀なメンバーからアドバイスをもらい、日々がんがん進化していった。最後の方のある日は、入社以来はじめての泊まりこみデバッグを経験したりしたなー。それでけっきょく、3週間でできた。

完成した展示はそれなりの反響があった。1年目で、これを期限内に達成できたことは、その後のエンジニア生活にとって大きな自信となったと思う。

製品開発部

そうこうしているうちに、直近の製品を開発する部署に移りました。 HD DVD という規格があって、そのプレイヤーソフトウェアをつくっていました。

( )

最初は、あるプラットフォーム向けに書かれたコードを別のプラットフォームに移植したり、ややこしいバグの解析などをしていました。そのあと、 HTTP ストリーミングを実現する部分の実装をスクラッチから書いた。実際の製品に載るコードを書く、というのがどういうことか知る経験になりました。あと、この頃にテストの大事さや開発プロセスについてよく学んだ。自分の書いたコードがちゃんと動くようお守りしに、ラスベガスの展示会に行った思い出も (けっきょく、問題は何もおこらなくてホッとした)。

Molatomium

そっちの話が一段落したあと、元の部署に戻って Molatomium という並列プログラミングモデルをつくるプロジェクトに合流しました。

それまでインタプリタ型の処理系だったのを、 VM で実装しなおす、という仕事をはじめました。そんな、言語処理系とかつくったことないよ.. と思いつつも、るびまの連載 を参考にしてコツコツつくり、半年くらいで仕上げた。

VM つくるってのはいい。いわゆる全能感がありますね。自分の設計したマシンの上で、自分たちの設計した言語をつかって、ユーザがプログラムしたコードが走る! これぞプログラミング、てかんじだ。昔から OS つくりたい! みたいなのを思っていて、それは結局なにかというと自分がコンピュータを完全に制御したい、ということなんだと思う。 VM をつくるというのは、それに近い。

その VM はけっきょくいくつかの製品に搭載され、世の中に出た。やっぱり、自分の書いたコードで動いている製品を電気屋さんでみるのは、ちょっとした感慨がある。

そうしてつくった VM の話をちょいちょいと学会などでしていたら、雑誌に投稿する機会にめぐり合ったり、アカデミアの輪に片足つっこんでみたりで研究者っぽくなった。国際学会に出すんや! と論文をちまちま書いて、最終的には2つの国際ワークショップで発表する機会を得た。

要約すると、念願の全能感をてにいれ、製品に載り、論文も書いた。雑誌投稿もし、国際ワークショップで発表もした。 で、まぁこれはいい区切りだな、と。

間接的なもの

どんな貢献ができたかなと思い出してみます。

自分のコードが入った製品はたしかに世に出たけれど、その売上に寄与できたか、というのよりは 間接的なことに取り組んできたのかなと思います。 Web 周りの整備をして、 Trac, Redmine, SVN, Git, Hudson といった世間の最新技術を利用することを啓蒙したこと。 読書会を開催して、組織を横断したつながりをつくったこと。場をつくり、文化のタネを蒔けたかなと。 あと、国際ワークショップでの発表や雑誌への寄稿、アカデミアとの交流によって、技術力というブランドの向上には多少寄与できたかなと。

次へ

思い出しながら書いてきたんですが、読み返してみると 好きなことを、自由にやってこれた なーと改めて。それはたぶん、周りの人たちのおかげで、ぼくがぼけーっと好きなことをしている横では苦労してたり迷惑をかけてしまっていた人がいたんだろう。すみません、ありがとうございます。こんなやりやすい職場環境で、エンジニアとしての基礎素養をつけることができたのは、とてもラッキーだったんだと思います。

で、もう明日から別のところで新しいチャレンジがはじまります。というかもう今日じゃないの.. 眠くなってきた..

次回作が最高傑作!

6月にフランスの Saint-Malo というところで開かれた、 A4MMC という国際ワークショップで発表してきました。 今さらだけどつらつら書き残しておこうと。

ポイント:

• 初めての英語での発表だった
• contribution, contribution, contribution!
• アプリケーションはまだ模索中

A4MMC とは

Applications for Multi/Many Core で A4MMC です。 ISCA というコンピュータアーキテクチャについての国際会議があって、それの併設ワークショップ。マルチコアとかメニーコアとかになってくるけど、じゃあどんなアプリケーションがあるの? という問いに対して、各自アプリケーションを持ちよって発表する、というのがテーマで、今回のが第1回目。 セッションは Cell, GPU, その他 に分かれていて、半日のこじんまりとしたワークショップだった。 採択率は full paper が 7/8 (87%) とだいぶ緩い.. ぼくは half paper として出していて、そっちの採択率は 1/6 (16%) 。全体としては 8/14 (57%)。

初めての英語での発表だった

いやー、さすがに緊張しました。日本語での発表ならなんだかんだで回数重ねてるからなんとでもなるんだけど、英語でしゃべるとかまるで勝手が分からない。15分発表のつもりで用意していたんだけど、当日「10分発表、3分質疑ね」と言われて、ぜんぜん調整できなかった。場数がいるな… ぱたぱたと焦ってしまって、ストーリーを十分に伝えることができなかったのが 反省点。

あと、ちゃんと練習せねばだ。しゃべることは Keynote のメモに書いていて、 iPhone の Keynote remote アプリからカンペとして読んでいたんだけど、やっぱり読み上げプレゼンは伝わらない。日本語でしゃべる場合だと、メモにキーワードだけ書いておいて、しゃべってる最中に文章を組み立てる、というのはアリなんだけれど、英語だとまだその場でさっと文章が浮かばないのがまずいところ。

なので、やるべきは 1. しゃべる英文を丸暗記、 2. 英文をとっさに思いつけるようになる 、の2つ。 2 を目標としながら、 1 でしのぐ、が現実的かな。

質疑応答のときにはいちおう、聞かれたことに対してささっと拙い英文を返すことはできたので、進歩してはいるのだ… では、どうやって即時応答ができるようになってきたかというと、単に量の問題な気がする。国際会議にちょこちょこと足を運んでノリをつかんだり、レセプションに飛び込んだり。ふつうの英会話と同じ。詳しくない話題で盛り上がっている場で受け答えするならいざしらず、発表したことについての質問ならこれまで散々考えてきたことだから答えられないわけはない。

contribution, contribution, contribution!

発表した後の質疑は、「これは Cell でしか動かないの?」「私たちにも使えるようになるの?」といったものでした。つまり、「こんなものをつくったよ」「それはナイスだね。で、我々のコミュニティに対してどういう貢献になるの?」ということだと思う。

当たり前なんだけど、ただ発表するだけじゃ自己満足でしかなくて、そこで得られた知見をどうコミュニティに活かせるか、という視点が足りなかったなーと。研究だけじゃなくて、どんなコミュニティでも言える。この視点が足りなかったから、「一見さん」ぽい立場からいま一歩出ることができなかったんじゃないかな。

学会とか何かのコミュニティに初めて参加したときに感じる「一見さん」感というのがある。周りの人たちはそれぞれに楽しそうに談笑していて、自分がなんかぴたりとはまっていない感じ。

そういうときは発表してしまうに限るんだけど、その内容がコミュニティに対してどれだけインパクトがあるか。を考えておくとよいなーと。

あと、継続して貢献することがキモだなと。点をつなげて線にする。複利効果も期待できる。すごく fundamental なこととかだと単発でもいいんだろうけど、凡人のぼくはホームランを狙うよりヒットでつなげたい。あぁこれはオープンソース活動とかだと当たり前なんだろうな。

アプリケーションはまだ模索中

ワークショップの内容について書いてなかった.. そもそも、並列処理能力を活かせるアプリケーションはどんなものがあるか、というのを知るのが目的で参加していたのでした。けど今回の結論としては、まだみんな模索中だなーというところ。

プランクトンのシミュレーション、巨大望遠鏡、といったアカデミックなアプリケーションというのがまずあり。こういう系は、これまでにあったアプリケーションの規模を大きくするというものなので、あんまり新しい感じはしない。他の発表は、 GPU を MPI でつなぐ、とかオレの FPGA で CUDA を動かしたぜ、とかいう話でこれまたユーザレベルのアプリケーションっていう感じじゃない。

たぶん、もっと他の分野の人たちとの交わりが必要なんだろうなー。じっさいに困っている問題を抱えている人といっしょに仕事をする、という。自分たちの世界で考えてしまうと、どうしてもこれまでの延長になってしまいがちだ。コンピュータを (意識せずにせよ) を使っていて、遅くて困っていることってなんだろう?

そのほか

先に出席していた HotPar ’10 で話した人がちょこちょこといて、声をかけてもらったり、声をかけたりできたのがよかった。点がつながる感じがするよね。継続的にコミュニティに参加して、コミットしていくことが大事だな。

あとは、TGV のチケットがなかなか買えなくてやきもきしたり、ホテルの近辺が城塞都市メルキドっぽかったり、帰りのフライトの日にストライキが決行されて帰るのがやばかったりした。

まとめ

英語の発表、もっと数をこなそう。コミュニティへの継続的な貢献がつながりになる。日没が遅いのは文化に大きな影響を与えるる。

かれこれ1年ほどやってきた研究者もどきの生活もこれで一区切り。これからはまた開発者生活にもどります 。

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% の性能しか出ないけど、人が考えやすいモデル、というのが今の方向性なんだろう。

---

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

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 こわいです。