2007/09/14
収束
あちこちで議論して、なかなか自分としては有益だった。だらだら書いてみる。
私の下のエントリの問題のひとつは、 (a) 現場でトラブル発生時に実際に「降りてゆく」必要性とか、計算機を「使いきる」ための 下層からくる物理的制約、という話と、(b) システムを理解してゆくための論理的、 あるいは数学的根拠、という話の2つがごっちゃになっているから、であるようだ。
鵜飼さんとこで 出たように、トラブル発生時に降りてゆく必要という意味では CPUのインストラクションセットアーキテクチャ(ISA)までわかっていればほぼ大丈夫なはずで、 というのは論理回路のバグはたとえ気づいたとしてもソフト屋さんには手の出しようが無い。 (TTLで組んだクロック2MHzとかいう時代ならロジアナやオシロで追いながらジャンパ 飛ばしてって話はあったろうけれど、今のマシンでそこまで追えないし、たとえ 追えたとしてもジャンパひとつ飛ばすのにだって分布定数回路の知識が必要になるから、 「論理回路」の下層まで降りるってことになる。そこはもうハード屋さん、あるいは ファーム屋さんが触るところで、ソフト屋さんの領域ではないと言い切っていいだろう。) ISAの上にはOSやミドルウェア、言語処理系、各種ソフトウェアツール郡が乗り、 抽象化の層を為している。
一方、ソフトウェアを支えている理論的な骨組みを学ぶ、という意味では、個々の CPUのISAはあまり問題ではなくて、抽象機械としてのチューリングマシンやラムダ計算、 それを実装するノイマンアーキテクチャのモデル (仮想的なCPUでいい)、 それを実現するための論理回路 (組み合わせ回路と順序回路)、って具合の話だ。 こちらは、現実の計算機に沿ってはいるものの、特定の面だけに注目して 他を捨象したモデルを取り扱う。こちらも抽象化の層があり、 下層のモデルは上層のモデルの振る舞いをある程度定量的に議論するために 必要だ。Knuthが "The Art of Computer Programming" で仮想機械語MIXを 導入したのは、アルゴリズムの計算量をO(n)などの見積よりもより細かく (係数レベルまで)算出するためにCPUのモデルが必要だったからだ。 もちろんMIXのモデルは現実のCPUにあるいろいろなgotchaを捨象している; キャッシュやパイプラインの振る舞いとか、アドレッシングモードによる 命令長や実行時間の違いとか。
こう考えると、抽象化には2種類あることになる。現実の部品と、そのモデル。 そして、部品を組み立てて、より大きな部品とすること (論理回路→組み合わせ/順序回路→ノイマンアーキテクチャ)。 モデル化にも、必要に応じていくつかの段階があろう (論理回路を理想的な ブール代数演算とみなすか、遅延やファンイン/ファンアウトまで考慮するか、等) 抽象化の網はこのようにふたつの方向にひろがっていることになる。
さて、現場で問題になる「抽象化の破れ」は主に、 モデルと現実の部品との間の差異に起因するように思える。 出力が1に確定しているはずなのが間に合わなくて時々0に見えたりする、とか、 「nextNode」を指すリンクにはノードクラスへのポインタか終端を表す値が 入っているはずなのにごみデータが混入していた、とか、 がんがん再帰してたらスタックが伸びすぎてヒープを上書きしてしまった、とか。
この時、トラブルシューティングをするには、まず「小さなモデル-大きなモデル」 という抽象化の階層を降りてゆき、破れが生じているレベルで「モデル-現実」 という抽象化の壁を越える必要があるわけだ。
「論理回路とその下の間に非常に強固な壁がある」というのは、そこでは 「モデル-現実」の壁が非常に厚いので、現場でそこの破れが問題になることが ほとんどないってことだ。より大きなモデルへと見て行った時に、 破れが起きやすい最初の場所が、CPUのISAなのだろう。だからトラブルシューターは 最悪、モデルの階層をCPUまで降りていって、現実との齟齬を調べることになる。
次はなんだろう。メモリとCPUからなるノイマンアーキテクチャのモデルかな。 スタックオーバーフローなんて話は、現実的には容量制限があるメモリと、 抽象的なスタックマシンというモデルとの間の齟齬と言えるかな。 あるいはバッファオーバランとか。言語モデルで見えている データは独立しているはずなのに、現実にはメモリ上に一直線に並んでいて 干渉することがある、とか。
あるいは、整数の演算というのは、モデルの階層は数学で作られている。 加減乗算については閉じているけど除算については云々、とかそういう話。 その世界では 1 + 1 も 10^100 + 1 も似たようなものだけれど、現実とのマッピング の段階でオーバフローを起こしたり多倍長演算が入って一方が極端に遅くなったりと、 齟齬が発生する。
まあ、この論自体もひとつのモデルであって、つっこみどころはたくさんあるけれど (「2種類の抽象化」って常に綺麗にわけられるのか、とか)、ここから何か無理矢理 考察を引き出すとすれば、
- 「理解する」というのは「小モデル - 大モデル」の階層を降りてゆくことになる。 これはある意味きりが無い。一直線ではなく分岐があって、ひとつの流れにおいては 一番基礎となるモデルがあるかもしれないけれど、別の流れを降りて行くとどんどん 先が続いている、という具合。
- 現場でトラブル解決には、「モデル - 現実」対応が破れている場所を 探す必要がある。こちらについてはある意味「きりが有る」。 現在の計算機を相手にしている限り、量子力学まで降りる必要は無い。
- トラブルが「モデル - 現実」の齟齬だとすれば、 「小モデル - 大モデル」の構造を知らずに現実の部品ばかりを相手にしていても 役に立たない。CPUが大事だからって80386のアセンブラに飛びついても、 「CPUのモデル」からアプリケーション層に至るまでのモデル階層の理解が無ければ、 現実のトラブル解決が出来るようにはならないだろう。
うーん、結局「どっちも重要」っていうありきたりの話にしかならないなあ。
Tag: Programming
2007/09/12
子どもは何にも知らないの
元のshi3zさんのエントリが断定調で、一般論と具体論が混ざってることもあって 異論反論パロディが続出したようで。つい黙ってられなくて あちこちにコメントしてしまったけど まとめとく。
解釈が割れた点は：
- 元の論の対象となる「プログラムが書ける人」は一般の職業プログラマや趣味プログラマまで 含むのか、それとも抽象化の破れにいつも直面してそれを何とかしてしまえるような 一部のタフな人材を指してるのか。
- 元の論の「マシン語を理解する」は80386アーキテクチャ特有のバッドノウハウまで 理解してばりばりアセンブラを書き下せることを指すのか、それともストアドプログラム アーキテクチャ、MMU、特権命令、割り込み、コンテキストスイッチなどの現代の 代表的なマシンアーキテクチャを理解するということを差し、80386を持ち出したのは 単なる代表例にすぎないのか。
あたりかな。私は両方とも後者と取ったけど、別に解釈すれば異論が出るのがわかる。
ただ、どういう解釈をしても次のような意見が出てくることには首をひねる。
「抽象化はレイヤの積み重ねで、論理回路の下にも半導体があり、電磁気学や 量子力学を知る必要があり、と続いてゆくから程度問題にすぎない。結局「自分は 論理回路から知っているよ」という優越感ゲームにすぎないのでは」
そう思う人にはDaniel HillisのThe Pattern on the Stone (翻訳: 思考する機械 コンピュータ) を勧めとく。翻訳は読んだことが無いが、原書の内容はとても平易なので、 内容だけなら中学生でも理解できるだろう。
第1章は論理回路。第2章で論理演算と状態機械。第3章でプログラミング言語。 第4章でチューリングマシン。第5章でアルゴリズム。以降、暗号や並列計算、 機械学習などを扱う。これを読んだからってプログラムがかけるようにはならないし 紹介された個々の概念を理解したことにはならないけれど、少なくとも現代のコンピュータが どういう概念の積み重ねで出来ているかという構造がわかるようになっている。
で、第1章の論理回路なんだけど、Danny Hillisはここで「スイッチとランプ」 「棒とばね」「パイプと弁」などで論理回路を作って見せる。つまりデバイスが 何であろうと、1と0が表現できてそれを伝達する仕組みさえあれば、残りの全ては その上に構築できるということだ。もちろん物理的に実現可能な規模で現代の CPUを作ろうとしたら半導体以外では非常に困難だろうけれど、今後全く新種の デバイスが出現して物理層がごっそり置き換わったとしても、上の層に 変化はない (ちなみに量子コンピューティングになったらどうなるの、という話は ちゃんと同書の中にも出てくる)。
私は高周波回路も量子力学も苦手だったし、数百MHzのバスクロックに乗るパルスの 波形や数GHzのチップクロックの中を走る電子の雲がどうなってるかなんて 考えたくも無いんだけれど、それらがデジタル回路の抽象化の壁を越えてくる確率と 「高級言語」で書かれたプログラムのSEGVに出会う確率にはあまりに大きな差がある。 抽象化力を指標とすれば、論理回路は非常に強力で成功した抽象化であり、 一方現代の高級言語の多くはまだその域に達していないとも言える。
このような抽象化の壁の厚さの違いに自覚的であることにより、次のようなメリットがある。
- 学ぶものごとに優先順位をつけられる。たくさんの層があっても、 壁が分厚くなっているいくつかの層を重点的に学べば安定した足場が得られる。
- 良い抽象化と悪い抽象化の区別がつけられる。自分で抽象化を設計する時に、 自覚的に壁の厚さを選択できる。
抽象化力の違いを無視して相対化してしまう危険は上のメリットの裏返しだ。
- あまりにたくさんの層があって全部は学べないから、とりあえず目の前の層を学んどいて、 漏れが出てきたらすぐ下の層、というふうに広げてゆくしかない、と思う。 でも時間に限りがあるから安定した足場までなかなか到達せず、いつも不安を抱えている
- 自分の設計した抽象化が良いのか悪いのか、判断基準が良くわからない。 また、与えられた問題に必要とされる抽象化の程度を判断できない。
なんだかんだで、ネタにマジレスな野暮だけど、せっかく書いたから貼っておく。
Tags: Programming, Assembly, Hardware
2007/09/09
前線からのニュースについて、 USと日本では大学入試の制度が違うから当てはまらないのでは、という意見があるが、 見るべき問題はUSの入試制度そのもの(admission officerだとかなんだとか)に あるんじゃなくて、 「ものをつくる能力、あるいはものをつくるために学ぶことができる能力と、入試で問われる能力との間に関係が無い」ことにある。 その点では日本の大学も同じようなポジションだろう。
(もちろん、全ての大卒がものをつくる人になる必要はないんで、 今の大学とか入試とかを変えるべき、という議論ではない。 「もしあなたがものをつくる人になるつもりなら、大学は関係ないよ」という話である。)
傾向として入るのが難しい大学には面白いものを作ってる人が多そう、 ということはあるのかもしれないが、個人的にはそれは入試によって ものつくりの能力が直接選別されたわけじゃなくて、高校までの段階で 「学業ができる生徒ほど、好きなことをやっていても干渉されないで済む」 というバイアスがかかったからではないかと思っている。
たぶん高校までで成績が良いことの最大にしてほぼ唯一のメリットは、 好きなことをとことん追求する自由が手に入りやすいということだ。 もちろん全体的な傾向としてであって、局地的には成績にかかわらず 自由なことをやらせてもらえる環境というのはあるだろうし、 そういうところからはやはり面白いものをつくる人が出てきているように思う。 (というよりも、好きなことを好きなだけ追求できる環境を経験せずに ものをつくる人になるのは不可能だろう)。
2007/09/05
久しぶりにPaul Graham節爆発って感じだったので思わず訳してしまった→ 前線からのニュース---News from the Front。
ところで野暮を承知でちょいと背景解説。
- Paul Grahamのエッセイのほとんどは、ハッカーもしくはハッカー的なるものを胸に秘めた 人に向けてかかれており、胸に秘めたハッカー性を積極的に追求して創造行為を行う人の 後押しをするという意図がある。もちろん目指すのはハッカーの創造によって 支えられる社会である。
- この話は、大学Aからランダムサンプリングした学生aと、大学Bからランダムサンプリング した学生bとの比較ではない。また、普通の企業に就職したり公務員になっていったり することを選択した(現在は大部分を占める)学生の話でもない。
- タイトルを "News from the Front" とつけたということは、Y Combinatorが "the Front" ということ。何に対する「前線」なのか。 もちろん、現在変わりつつある世の中の、変わって行く先にY Combinatorがいる、 という自負のあらわれであろう。
Tags: PaulGraham, 翻訳
Comment (1)