STM
http://d.hatena.ne.jp/kilrey/20090214#p1に繋がる話。
現状の手続き型言語でマルチスレッド対応する場合にはセマフォなどの排他・同期条件を利用する。その排他・同期条件を利用する文法としてはJavaのsynchronizedがもっとも洗練されているだろう。単純な条件ではthisを用いて、複雑な条件では同期オブジェクトを用いてロックを行う。ロック解除を自動化するなど、間違える可能性の高い箇所を減らしている。
トランザクションの戦略次第ではまったく同期と同じ振る舞いを保つことも可能だろう。例えば、
synchronized { this.update(); }
をソフトウェアトランザクションに変換して
while (true) { synchronized { clone = this.deepCopy(); } clone.update(); synchronized { if (this.unchanged()) { this.copyFrom(clone); break; } } sleep(); };
というように(外部環境まで擬似的にコピーすることが必要だが)。
手続き型パラダイムではメニーコアに向けた解としてトランザクショナルメモリが有効だと思う。それでもコストが大きいのは事実だし、それだけのコストをかけるなら関数型パラダイムで排他・同期が必要な箇所自体を減らした方が良いのではないかなあ。
「セクハラ」に関わる問題三つ
http://d.hatena.ne.jp/Britty/20090214/p1の話。↓のブクマの続きを書こうとしたら長くなったのでエントリに。
これは明確な「harassment」だけど、当人に「いやがらせ」る意志がない以上話が通じないのも当然かと思う(適切な訳は「迷惑行為」?)。
あまりにも問題が錯綜しているので横から整理してみるよ。当然、以下は私個人の見解。
「harassment」と「セクハラ」のずれ
日本では「harassment」が広がっていないうちに「セクハラ」が広がったため、「性的」という部分が重要だと思われている。しかし「harassment」の本質は自己決定権の侵害である。必ずしも差別的な価値観を伴うものではない。
例えば、見知らぬ人から「おい、そこのお前！」と呼びかけられて不快に感じるのも「harassment」の一種である。そのような「harassment」の中で「セクハラ」が重大な問題として扱われるのは道徳規範に反する度合いが大きいからだ。
ただの下ネタと他人を題材にした下ネタは区別しなくてはならない。前者自体は「harassment」とならないが、後者はそれ自体が題材にされた人に対する「harassment」になり得る。前者が問題になるのは、特定の人に向かって言う、という行為に関する場合。つまり、今回は二重の「harassment」というわけだ。
道徳規範のずれ
道徳規範というものは人によって大きく異なる。あるジョークを面白いと評する人もいるし、不快だと評する人もいる。今回のような下ネタは人によって大きく異なるものの代表だ。これが差別ネタだったとしたら発言者を非難する人はもっと多かったのではないか。
また状況によっても評価は大きく変わる。友人と部屋で飲み会をした後の深夜に酔った勢いで猥談をするのを問題とする人は滅多にいない。しかし、まったく同じ内容を日中の山手線でしていたとしたら軽蔑されるのが当然だろう。
さて、はてなブックマークは私的な領域か公的な領域か？……微妙なところか。(ここでの「公的な領域」には「公共」の意を含む。)
事前評価
メニーコアに対応したプログラミングについて考えてみた。
手続き型パラダイムでは辛い。何故かというとシングルコアにしか対応していないから。現状の同期・排他モデルでは並列度の上昇に対応することが難しい、というより面倒くさい。さらにpthreadはあくまでもタスクを動かすためのもの、粒度が大きすぎてそのままでは使えない。
関数型パラダイムは有効。副作用なしであれば並列度の上昇にも問題なく対応できる。ただし、現状では並列計算の速度ではFortranに負けている。ライブラリやコンパイラの完成度に差があるのも大きいとは言え。
関数型パラダイムがこの壁を越える契機は「事前評価」にあるのではないか*1。
従来の評価戦略の分類では、正格評価とは関数に引数を渡す際に完全に評価した値として渡すもの、非正格評価とは関数に引数を渡す際に評価前のメモとして渡すもの、といった扱いである。この場合の非正格評価とは「計算しないでも済むものは計算しない」という戦略として解釈される。
私の言う「事前評価」とは「計算できるものは片っ端から計算しておく」という戦略である。実装レベルで考えるならば、関数や式をすべてワーカーコアに投げておいて準備が整ったものから返していく。分岐があれば両方計算しておく。
ただ、これは原理上最速の評価戦略だが、一つ大きな欠点がある。メモリ周りのアーキテクチャとの整合が取れていないのだ。特にワーカーコアの終了をどのように検知するか、どのように値を受け取るか、が問題になる。簡単な計算ならメモリアクセスするよりも自分で実行する方が速いだろうし、単独コア計算速度とコア間通信速度の比に応じた割付が必要だろう。
