一段下のレイヤー位は知ってた方が良いプログラムが書けるとは思う

弾氏のところでこんな話が。
まぁ、マシン語（懐かしい響きだな。アセンブリ言語と言うべきか）知らないと駄目なんてことはもちろん無い。でも、知らなくていいということを強調しすぎるのもどうかと思うので。弾氏も「もちろん、一段下の階層は、知っておいた方が得だ」とおっしゃっているんだけど。

もちろん、「層」があるのは、下の層を見せないように抽象化するためにあるので、基本的に下の層のことを知っている必要はない。けれども、1段くらいの層だと、その抽象化が完全にいかなくて「透けて見えてしまう」ことがある。まぁ、プログラムの意味的に問題になることはあんまり無いとは思うけど、主に性能に影響が出てくることがある。

これは「マシン語」なんて話だけではなくて、ハードウェアの実装とかOSとか、色々な層に当てはまる。例えば、数値計算をやる人は、多次元配列を確保するときに、double a[1024][1024]なんて宣言はせず、a[1025][1025]とかやる（なぜだか分かります？*1）。こんなのは、1段下のハードウェアアーキテクチャの層を知らないと、性能に大きな影響が出てしまう例。本当はキャッシュなんて上位層には見えないようにしたいはずなんだけど。

僕はあまり使わないけど、perlやrubyなんかでも、「この操作はCでいうとこう実装されているはずだから、こう使うべきだ」というのはあるはず。（それはそうと、perlのfork, Windows上では、threadを使ってエミュレートしているそうだが、本当に同じ意味にできているんだろうか。perlに閉じた分には原理的にはできるとは思うけど。できているんだとすると大したもんだと思う。もしできていない部分があるとすれば、それはその実装という一段下の層を知っていないと、という話になる。）

下の層の話も、知らなくてもいいやというんじゃなくて、頑張って勉強するといいことはあると思うよ。
まぁ、使っているうちにハマって勉強するものかも知れないけど。

*1:キャッシュの実装は普通set assosiativeと呼ばれるもののため、キャッシュサイズによるが、最悪a[i][0]がすべて同じキャッシュラインに乗ってしまう。このため、配列全体をなめるアクセスをする際、アルゴリズムの都合で２次元目を先に変化させるアクセスをさせたりすると、例えキャッシュ容量が余っていてもキャッシュに乗らなくなってしまう。Wikipediaに少し解説がある。