未来のソフトウェアは多少の間違いを許容するのか

👻 道化師 🃏 @wraith13

マルチスレッド関連の問題を直接的に回避する手段(ロックおよび狭義のロックフリー)って使ったら負けだと思うんだよなぁ。レアケースに対してコストかけ過ぎと言えるし、正しく対処コードが書けてるかの検証も困難だし。

👻 道化師 🃏 @wraith13

進むべき方向としては広義のロックフリーに含まれることになるんだろうけど、マルチスレッド関連の問題を隠蔽あるいは軽減してしてしまう実装だよね。

くまぎ @kumagi

@wraith13 そして伝説はSTMへ…

👻 道化師 🃏 @wraith13

@kumagi う～ん、自分的にはSTMも「これじゃない」感が・・・。STMは方向としてロックと同じく「完全に正しい状態」を維持するアプローチだと思うんですよ。で、自分が目指すべきだと思ってるのは「多少の間違いは許容」する設計なんじゃないかと。

くまぎ @kumagi

@wraith13 「多少の間違いは許容」というのは難しいと思います。「多少と読んで良いか」というふわふわしたラインを守る事が幸せそうに見えないです。「完全に正しい状態」を守れないという前提を敷くべきなのは分散システムぐらいの物なんじゃないかと思います。

👻 道化師 🃏 @wraith13

@kumagi システムが複雑化していく以上は完全に正しい状態を維持するってのはどんどん困難になっていくでしょうし、悪貨は良貨を駆逐するという観点からハードウェアもたまにエラーを起こすような代物が市場を支配することになるでしょうし、「多少の間違いは許容」ってのは必然の帰結かと。

くまぎ @kumagi

@wraith13 分散システムの場合は故障を設計に織り込まないと立ちゆかないのですが、マルチスレッドプログラムの場合は特定のコアが故障して足し算の結果が合わないとかそんな状況になったらおとなしくノードごと全死亡で良くて、その外側で解決するべき問題じゃないかな、と思うのです。

くまぎ @kumagi

@wraith13 その維持のラインをどのレイヤーで取るか、という問題だと思うのです。いかに安くても、で、ミス訂正をプログラマに依存するようなCPUが席巻するとは思えないのです恐ろしく遅くなりますし。だからその上のレイヤーでどうにかするのが経済的と考えます。

👻 道化師 🃏 @wraith13

@kumagi 自分がイメージしてるのモデルは、生物なんですけど、コンピュータもどんどん複雑化していくことで様々な特性がどんどん生物に近づいてるんですよね。で、生物の体って割と大小様々な問題を常に内包しているもので、コンピュータも最終的にはそうなるのではないかと。

くまぎ @kumagi

@wraith13 生物の細胞も、基本的には損傷に修復を試みますが、修復が難しそうと判断したら諦めて自殺します(たまにその自殺にさえ失敗した時にガン細胞になったり)　コンピュータも同様にどこかに「これが死んだら諦めるライン」があって、一番経済的なのがどこなのか、と。

👻 道化師 🃏 @wraith13

@kumagi 仰る通り最終的には総合的にどうするのがもっとも(あるいは概ね)経済的なのかというライン(ゾーン)に収束すると思います。

Masahiro Kasahara @mkasahara

@kumagi @wraith13 「間違い」がどんなモノか想像つきませんが、運が悪いと正しく実行されないかもしれない命令セットってのはあっても良いとおもいます。BINC [mem] するとベストエフォートでメモリの値を INC するとか。

Masahiro Kasahara @mkasahara

@kumagi @wraith13 最近研究で私が書いたプログラムはrace conditionがあるんですが、本当にたまにしか競合しないし、大雑把な集計をしたいだけなので0.01%ぐらい数え落としても問題無かったりします。BINCでマルチスレッド動作が速くなるなら便利。

くまぎ @kumagi

@mkasahara @wraith13 高速化に伴って現れるキャッシュライン競合の都合をプログラマが認めて折り合いを付ける方法を考えた一つの結果がHTMだと思っていて、他にもまだ現れるんじゃないかと思っています。BINCはちょっと用途が細かいですが…。

👻 道化師 🃏 @wraith13

@mkasahara たまにエラーが起きるのを許容するほうが製造コストもうんと下がるでしょうし、そのうちそういうチップが市場を席巻するのは必然だと思います。

Masahiro Kasahara @mkasahara

@wraith13 現状売られているほとんどのチップは既にある程度のエラーを許容してると思いますよ。（そうでないとまともに動かないとも言う。）

Masahiro Kasahara @mkasahara

@wraith13 起きたエラーをハードウェアレベルで対処せずにソフトウェアでリカバーするという意味ならば、メインフレームの縮退みたいな感じのものを想定しているんでしょうか？

👻 道化師 🃏 @wraith13

@mkasahara それでも現状は、内部的にエラーを補正し外部的には割と完全性を維持してるんじゃないかと思いますが、そのうち(より)外部的にもエラーを出すようになるのではないかと。

👻 道化師 🃏 @wraith13

@mkasahara まだ具体的なイメージがあるわけではないんですが、「ハードウェアの問題をソフトウェアでカバーする」ってのじゃなく「ハードウェアもソフトウェアも問題を内包しつつも外部的には大きな問題を起こさない」設計が求められているのではないかと。

👻 道化師 🃏 @wraith13

@kumagi 最終的にプログラマに依存する形になるかどうかは別にして、メモリバリア云々、アウトオブオーダー云々はすでにハードウェアの都合をプログラマに押しつけてますよね。(==；

くまぎ @kumagi

@wraith13 メモリバリアについては確かにそうですね。先端を突き詰めるほどに隠蔽しきれる範囲が減ってきて血なまぐさい物に触れる事になるのは仕方ないと思います。でもSTMはそういう血なまぐさい物を隠し切るふんばりラインとして新設されたもので、個人的には筋が良いと思っています。

👻 道化師 🃏 @wraith13

@kumagi なるほど。それでも、スレッド間で共有される値に対してD言語のようなホワイトリスト方式を採用していない言語では結局、正確にSTMを使えてるのかどうかは検証が困難なままですよね？　そうでもない？

👻 道化師 🃏 @wraith13

今回の教訓：辻ロックフリーは大きなタイムラグを伴って現れることがある。　・・・思わぬタイミングの辻ロックフリーに気をつけましょう。

くまぎ @kumagi

@wraith13 うーん。検証が簡単だとは言いませんが、STMより簡単なモデルはちょっと思いつかないです。難しさを速度と引き換えに解決するものは出るかもしれませんが、STMの方向は間違ってないと思います。

👻 道化師 🃏 @wraith13

@kumagi 完全性を死守しようとする前提から離れない限りはそうかも知れませんね。とかいいつつも、私が言ってる間違いを許容するってのもそのアプローチとして結局の所、「たまに失敗するけどリトライすればおｋ」的なものに落ち着いちゃうと本質的にはTMとそう変わらないかも。