日々の破片

_ モニターが壊れた

壊れかけている、が正確かな。突然、プッチンパッチン言いながら画面がパキパキ点滅したり、それは恐ろしいのなんのって、爆発すんじゃないかという感じ。だましだまし使うにもそろそろ限度という感じだ。

一応ビデオカードも疑ってみたが、他のマシンに繋いでも同じだ。

まあ、考えてみれば14"—15"—17"—19"と順調に来たわけだし、こいつも買ってそろそろ5年くらいになるんじゃないか？ ゴミ捨て料金を見ると4000円とか出ていてげんなりするが、しょうがない。

で、履歴を考えると次は21"だが……高いよ。

B00082391C

というわけで20"で妥協。

ちなみに、この10ヶ月でLDプレイヤー、洗濯機、掃除機、ガスコンロ、モニターと順調に壊れてるんだが、購入時期は異なるのにどうしてこうなるんだろう？ というか、コンピュータもなんかおかしくなってきてるし。

_ トリッキーなコードという呼び方

kmt-tさんのトリッキーなコードはちょっと矛盾がある。

最初に、

コードのバックグラウンドにある理論が解ってないと理解できない（特に高度な数学や学術的な内容を含むもの）コードってたくさんあるような気がします。

として、次に

多分、これ読んでも何やっているか解る人は殆どいないと思いますが、正攻法より性能がでるので個人的には有用なコードだと思います。

という例を出している。

最初の言明を次のところで引っくり返しているように見える。高度な数学でも学術的でも無いという言い方もあるのかな。でも、僕には4バイト浮動小数点数のビット構成を一目ではわからないからFP_ONE_BITS 0x3F800000が何を意味しているかはわからない。

この場合、僕の立場（そのコードを見て何をやっているかわからないということ）から少なくても2種類の反応があるのだと思う。1つは、「これはトリッキーだから禁止」。もう1つは、「で、何をやっているのですか？（訊ける場合。または）調べるとするか」。

もし、仕事でこのコードを読むのなら後者を選ぶのは当たり前の話だ。前提が

・そのコードが出て来るプログラムのソースを読むのも仕事のうちである（必要なら、やれ。というだけのことだ）

・それが仕事だということは、可能だという予測がついている（無理じゃないということがわかっているということだ）

・そのコードの界隈に他のメンバーがいる（＝調べてわからなければ、あるいは調べる時間的な余裕が無ければ訊けるということだ）

となるからだ。

もちろん、例示ではなく現実の世界であれば、HOGEとかHUGAという「名前」は切って捨てることになる。HOGEじゃなくてRECIPRO（かな？ 自信なし）、HUGAはEXPにするだろう。だが、コードを変える必要はおそらく無い（JITがインライン展開する可能性を持つユーティリティ関数が存在すると言う可能性があれば、そっちを使うと思うから「おそらく」）。

だから、僕は、2番目の（tbについての点は除いた2番目）のkmt-tさんの意見に賛成だ。正攻法というのはおうおうにして子供の作文になる。小学生用に教科書を書くのか中学2年生用に書くのかでは異なるのは当然だから、そのコンテキストに応じた良い結果を出すのが良いコードだと思うからだ。

したがって「トリッキーなコード」という呼び方は、結局のところ意味が無い。

へたくそや無知であれば、そんなコードが出て来るわけがない。逆に言えば、そのてのコードが出てくるのには理由がある。その理由がどこまで理に適っているか、あるいは理屈は通らなくても利に適う（適正なコストで使える）という切り口もあるけど。その理と利のバランスの問題で、そのバランスをどこに置くかだけの話だ。つまり「トリッキー」なんていう言葉には意味がない。

したがって、「〜という書き方はしないこと。トリッキーなのでどうしたこうした」というのは理由になっていないから「ばかですか？」としか反応できないということを、トリッキーなコードというとこに書いたのでした。で、おそらく、ほとんどの場合、トリッキーという烙印が押されるほうが理にも利にも適っているだろうな、と思う。っていうのは、トリッキーに見えるものというのは、ほとんどの場合は洗練されたものだからだ。洗練されて無駄が殺ぎ落とされたコードは、傍目には妙にコンパクトなので「トリッキー」という妄言の対象になるのだと思えるからだ。でも洗練の過程には必ずそのコードを作った人間の知恵が入っている（ただし、歴史の澱になっていることもあるからちょっと難しい。キャッシュラインを無視して、4バイトのコピーを*(long*)p = *(long*)&buff[3];なんてやったら却って遅くなる可能性があるとか）わけだから、それはイディオムとしてむしろ学ぶべきものだ。

単純な理屈ではfor (i = 0; i < 4; i++) { *((char*)p + i) = buff[3 + i];}（うむ、Cは忘れた。左辺はこんな書き方であってるかな？）よりも、*(long*)p = *(long*)&buff[3];のほうが1回で4バイト転送できるので高速なはずだが、実際には異なる可能性もある。そのあたりが、妙な手動最適化をするな、というような話になるのだが、であればトリッキーなんていう言葉を使わず、JITにお任せ、とかコンパイラにお任せとか、まずは計測とか言えば良い話だということだ。あるいはダブルチェックロッキングのように、なぜかnullチェックを2回やることで高速化を狙い、しかも実はそれがメモリーモデルに反しているという逆転に次ぐ逆転みたいなこともあるのだが、それに対してダブルチェックロッキングのような記法を「ほら、これだからトリッキーなコードは……」というような言い方はできないということだ。少なくても「トリッキー」なんて言葉を不用意に持ち出す人間の100倍は（仮に間違った結果であったとしても）先人の知恵が含まれているからだ。

これは、応用と基本の問題でもあるな、と書いていて気付いた（というふうに脱線するけど、日記だから問題なし）。

レシピブックみたいなイディオム集に問題があるとすると、「なぜそういうコードになったのか」を読み飛ばして単純に結果のコードが利用される可能性があるところだろう。それ自体は利には適っているから必ずしも悪くはないのだが、でも時々は理由を考えたほうが良いし、そのためには原理とか仕様に対する知識が必要となる、ということだ。なぜなら、永遠のコードなんてものは存在しないからだ。CPUがかわったりメモリーバスのアーキテクチャが変われば昨日の最適化は今日には遅くなるかも知れないし、final付ければ速かったものが、final付けなくても速いし付けるとモッキングが出来ないとかにも変わる。なんでそうしたかを知っていれば、それをやめる時期も理由もわかる。単に使っているだけだとやめ時もかっては有効だった理由もわからない。当然代替案も出て来ない。

で、話は飛ぶが、まだまだ粒度が細かい。だからこういうコードの1行とかに関するつまらん規約とかが必要になるんだろう。そういう規約で縛る必要がある世界に対しては、もっと粒度を粗くしなければ無駄だと思う、というように考えは続くのであった。

_ 番場蛮

ばんばん

蛮勇なり 1 (ヤングチャンピオンコミックス)(笠原 倫)

_ るびま

9号。

笹田さんの1周年話をとりあえず読む。というか、この号はいろいろな意味で原点みたいな感じだ。インタビューはなかださんだし。