odz buffer

2007-09-12

どこまで必要か

うけた。

いやでもまじめな話、論理回路がどうとか書いている人もトランジスタの動作やらホール効果について説明できるんですかね。ハイ・インピーダンス、プルアップ、チャタリング、配線遅延、ノイズ etc。

抽象化レイヤってのは下層レイヤブラックボックス化する目的もある訳で。そうは言っても、完全にブラックボックス化してしまうと困るというのはわかるんだけど、その困る状況の方が間違っているという発想にいかないのは不思議な所ではある。

shiroshiro 2007/09/12 19:20 洒落はわかるんですが。論理回路から上は電子回路とは独立して組み立てられるんで、ちょっと外してると思います(cf. Danny Hillis: ”The Pattern on The Stone”)。そこまでの独立性が、高レベル言語と機械語の間にあるかというと、まだ抽象化にかなり漏れがあるんじゃないでしょうか。各レイヤ間の抽象化の壁の厚さにはいろいろあって、壁が厚いところはそれなりに本質的な概念の跳躍があって、だからこそ学ぶ価値があるんだと思います。チューリング機械やラムダ算法もこのような本質的な概念でしょう (そもそもこれらの最初の「実装」は紙と鉛筆or黒板とチョークだったわけで)。OOPにそこまでの跳躍があるかというと、私は「あったら便利な概念だけれど、そこまで本質的な跳躍ではない」と考えます。

各層の間の壁の厚さの差異を無視して全部相対化してしまう議論には反対です。相対化してしまうと、「どれを学ぶのも同じことなので目の前に必要なものだけ学んでいれば良い」ということになります。けれども、下の層を全く違ったものに置き換えても揺らがない、抽象化がすごくうまくいっている概念と、下の層に暗黙的に依存しまくりな便宜上の抽象化といえる概念とが、やっぱり存在するわけです。そして何かを設計する人間なら、よりより抽象化を発見することを常に心がけるべきです。現存するレイヤの抽象化力の差に目をつむって、より良い抽象化を目指すことが出来るでしょうか。機械語なんて要らない、と言えるのは、ストアドプログラムアーキテクチャに比類する抽象化を考え出した人だけでしょう。

みずしまみずしま 2007/09/12 21:16 高レベル言語と機械語の間の抽象化の漏れが
物理的な制約に基づくものを指すなら、
同じ理由でチューリング機械やラムダ計算も
抽象化の漏れがあることになってしまうと
思いますが(それらを現実の計算機に実装
することを考えた場合)。抽象化の漏れが
物理的な制約に基づかないものだとすると
それは一体何なのでしょうか?

odzodz 2007/09/12 23:41 > shiro さん
うーん、もしかして、「機械語」の範囲が私と shiro さんで違うのでしょうか?もし shiro さんがいう「機械語」がノイマンアーキテクチャを含むなら、そもそもほとんどの高級言語はノイマンアーキテクチャを隠蔽していないと思うので、それはその通りだと思いますし、プログラマならノイマンアーキテクチャは理解しておかないとまずいでしょう。逆に高級言語でプログラミングしていて x86 の機械語の知識があるとないとで雲泥の差かといえば、そんなことはないと思います。

shiroshiro 2007/09/13 04:00 私は元のshi3zさんのエントリの「機械語を理解する」は「ストアドプログラムアーキテクチャ+MMU+特権管理+コンテキストスイッチングのメカニズムを理解する」であって、「現時点でそれに最適なのは80386アーキテクチャである」と主張してるんだと読みました。後半のx86が最適かどうかについては議論の余地があると思いますが(私は同意しませんが)、少なくともZ80、8086、68000ではダメな理由にはなりますよね。「機械語を理解する」の意味について解釈がぶれているのがすれ違いの原因でしょうか。

「抽象化の漏れ」については、物理的な制約も含めて構築物の性質がどこまで分解したら説明可能か(それ以下の層からくる性質を単なるパラメータとして扱えるか)というのがひとつの指標になるんじゃないでしょうか。同期論理回路は、その下の実装により動作周波数が限定されますが、逆に言ってしまえば下層からの影響は動作周波数だけですよね (通信とかメモリのソフトエラーまで考えるとエラー率も入ってきますが)。下の実装が何であれ、パラメータとしてそれらを受け取れば後の性質は解明できます。何らかのアーキテクチャを想定した機械語、チューリング機械、ラムダ計算はその意味で同じレイヤにあると言えないでしょうか。高レベル言語でも、KL1みたいに(既存のアーキテクチャだけでなく、並列推論エンジンといった)かなり異なったプリミティブへと分解可能なものなら、そこに新たな分厚い抽象化の壁があると思います。

odzodz 2007/09/13 23:18 > 物理的な制約も含めて構築物の性質がどこまで分解したら説明可能か
そういう意味では OS や高級言語はMMU、コンテキストスイッチ等に関してはかなりブラックボックス化に成功しているんじゃないでしょうか?
論理回路は抽象化に成功しているとの事ですが、実際問題として構成する部品の電気的特性を把握せずに論理回路を構成するっていうのはかなり無理があるような気もします。

shiroshiro 2007/09/14 06:59 なんか論点がすれちがっちゃている感じがしてきました。私が言いたかったのは「どこまで降りることが必要か」ということよりも、「もちろん必要に応じて降りてゆく先に違いはあるけれど、全てのレイヤは同じではなく、何箇所かに強固な足場があるから、その足場を中心に学んでおくべき」ってことなんです。大元のエントリもいろいろごっちゃになってる感じですし、それに私が自分の主張を持って乗っかったので私が議論を混乱させてしまったんだと思いますが。

論理回路を物理的に作るときは部品を知っている必要がありますが、「マージンを含めた組み合わせ回路一段あたりの遅延特性」という単純なパラメータがわかれば、半導体内の量子的解析とか配線の分布定数的な性質だとかは一切捨象してもその上に乗るものの動作の理解には差し支えないですよね。遅延がなぜ起きるかまでは知る必要がないと(もしかするとそれはパラメトロンの位相反転が安定するまでの時間かもしれない)。この抽象化が破れる時というのは、電源の容量が足りないとか、電源配線回りのインピーダンスが高すぎてノイズの影響を受けちゃうとか、環境温度が定格外になったとか、そんな感じじゃないですか。ハードを組み立てる人は気にする必要があるけれど、ちゃんと組み立てられて定格内の環境に置かれているマシンを使う人にとってはまず関係無いですよね。

一方MMUだと、アプリケーションプログラマでさえページフォールトの起きる仕組みとそのペナルティを知っている必要があると思います。ジュニアならともかくシニアレベルなら。もちろん抽象モデルでの理解で良いのですが、「一段あたりの遅延特性」とか「インストラクション毎に要するサイクル」みたいなブラックボックスではなくその中身のモデルが必要だ、という点で、論理回路の抽象化と同列には論じられないと考えます。

同様に、現在の高級言語の多くも、ちょっとでも突っ込んだことをしようとするとすぐにISAレベルまで降りないとならないという点でかなり薄い抽象化だと思います。予期しないバスエラーへの対処、並行/並列プログラムにおいて排他制御の手法の選択に気を遣わなければならないこと (性能を出すにはひとつのロックプリミティブに頼るのでは無く、アトミックな操作をアプリケーションプログラマが意識して使い分ける必要がある)、インナーループでキャッシュを意識すること、等々。こちらもジュニアプログラマならともかく、シニアプログラマとしてアウトプットに責任を持つ立場なら現状では避けて通れない話じゃないでしょうか。

言語処理系も書いている身としては、現在の実用言語による抽象化はハード屋さんがやっている仕事に比べてあまりにお粗末で比べるのもおこがましい、と思っています。言語研究の方はずっと先行しているので、その成果を何とか貪欲に取り込んで、機械語なんて知らなくても普通に書けばばりばりに最適化されて、かつ言語の提供するプリミティブ以外の部分で決して壊れない、というところを実装者は目指すべきだろうと。それが作れた時にはじめて胸を張って「機械語なんていらないよね」と言えるようになるだろうなと思います。

odzodz 2007/09/14 12:08 高級言語を利用する側で ISA レベルまでおりないといけない、といった経験はない(インラインアセンブラぐらいなら使ったことはありますが)のでいまいちよくわかりませんが、メタファとして「ハードを組み立てる人」とあるレイヤの「プログラマ」が同じなんじゃないかな、と思いました。
抽象化された概念も実装段階では下位のレイヤの特性に左右されたり(例えばできるだけ誘導リアクタンスを作らないように配線しないといけないとか)、トラブルがあった場合に下位のレイヤの知識があると推測しやすいというのは程度や頻度の差はあれど、プログラムも論理回路もあまりかわらないんじゃないでしょうか。
もちろん、そういう「ある程度強固な足場」がいくつかあって、それが論理回路だったり CPU だったりして、それらのモデルについてきちんと学んでおくといい、というのはその通りだと思います。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証