はじめてのにき

_ LL Tiger

クーラーこわれてる部屋は暑すぎるので とにかく家にはいられないということで 割とさっくり行く決意ができた。

Perl6 の lazy list の例はどうでもいい感じだったんだけど、 こうフィボナッチ持ってる lazy list とかもできるんだろうな… とこれは後で調べる。 ていうかゴルフ場の rakudo も update するか。 あとゴルフ場の rakudo は1秒ちょいで返事かえすので、 LL Eval はちょっとなんなんだろと思った。

LT は例のごとくお前らボケてる暇あったら技術の話しろ… っていうのも多かったなぁ。 記号 x86 とか無説明すぎて結局意味なかった。 まぁあれは当人じゃないからしょうがなかったのかも。

ライセンスと電子出版とフィジカルコンピューティングはそれぞれ 面白かったと思う。それぞれあんま LL ぽくないけど。

JSC/v8 の worker が native thread か否かとか、 まぁ普通に知らん。 まぁスレッド間通信が message passing しか無い以上、 native thread かつ giant lock も無いだろうなぁという 予想は高確率で当たってると思う。 ruby とか python は処理系作ってる人が愚かなのではなくて、 単にメモリ共有する thread だからしょうがなく giant lock …って話だと思う。 いずれにせよ僕は reviewer であるという言い訳ができるので あの場にいた唯一の committer であろう omo さんの罪は重い。

さて message passing というのは、 mootoh さんに完全同意で、並列屋には極めて重要な primitive になるんだろうなーと思う。 message passing って何な質問に MPI を例にしたのはたぶんあまりいい解答じゃなくて、 さっと答えるのは結構大変なんじゃないかなーと思う。

重要なところは、

• 共有メモリによって、こっそり行なわれてる通信を排除もしくは強く制限する
• で、通信は明示的に message passing でやりとり

何が嬉しいかというと

• 最悪のバグの一つであるところの、 race condition が無い
  • これは半分嘘で、同じメモリに同時に触っちゃったー的な race condition が無いだけで、アプリケーションロジックにバグ入れるとかはいくらでもできる
  • が、それもまぁそれなりに message passing 前提な API をうまいこと切ればだいぶ抑制できるんじゃないかね
• データ待つ系の処理は lock いらない
  • これはメリットなんだろうか

あと僕の強い希望として

• 言語作る人は message 送ってきた元の stacktrace を送られた側から参照できるようにしておいてください…

でまぁ、これまたオブジェクト指向並に 「短くて必要性を強く訴えられる例」を 考えつきにくい機能なんじゃないかなぁとか漠然と思った。

オブジェクト指向で猫と犬がニャーワンって、 結構あれがわからんという人は 身近にもネットにも結構いたと思う。 僕はオブジェクト指向ってのは それなりにすぐにわかったんだけど、 まぁ僕が天才であるとかではなくて、 単純にそれまでに書いたコード量の問題だと思う。 message passing とかも それまでに thread のコード書いて、 race ったり race ったり race ったり してるとまぁ感覚的に必要な気がするんだよね。

でもまぁうまい例を考えてみるのはいいと思う。

それにしても暑すぎるので明日もどこかに行かんといけない… 最近よくりなっくすかふぇというのを見るし、 電源もありそうだしトプカ行きたいし行ってコード書きの続きするかな…

あああと一個宿題があったんだった

(21:48)