msfukuiの日記

おおまさのみみはそらのみみ。

国会図書館に行ってみました

タイトルは、前回に引き続き 2355 のおやすみソング「小石川植物園に行ってみました」へのオマージュです。

時間がたくさんあるので、隙間を見つけてはお出かけしているのですが、先日ついに憧れの地に踏み入れました。

とても古い記事になるのですが、

msfukui.hatenablog.com

調べる予定にしていた「構造的プログラム設計の原理」の内容について、4年越しに実際に調べてきました。

その話は後で書くとして、その後は NORTH CAFE で美味しいカツカレーを食べて幸せでした。*1

投稿者: @msfukui
Threadsで見る

3時間くらいの滞在でしたが、能動的に調べ物をしたい場合は、周りの雰囲気も含めて最高な場所でした。また行きたい！

肝心の調べ物について

該当の箇所は、序文と第12章の両方に見られていて、その前後の文章を含めてとても興味深いのですが、一旦、第12章の記載を引用してみます。

最適化(optimization)という言葉は間違って使われている. ラテン語からの意味では(プログラムを)最適化するということはできるだけ良くすることである. しかし, われわれが最適化されたプログラムを使うのは, できるだけ小さく, 又は速くすることである. 小さくしたり速くしたり, またはできるなら両者を行うときには色々な意味で悪くしがちである. 理解が困難になり, 保守がむずかしく, そして間違い易くなることであろう.

簡単に言えば, 最適化にはお金がかかる. 我々の最適化についての基本的態度を２つの規則で定義しておこう.

  • 規則1: 最適化を行ってはいけない.
  • 規則2: まだ最適化を行ってはいけない.

最初の原則は, われわれが最適化する前にそうすることの積極的ではっきりした根拠を必要とすること, およびしばしば正当化する根拠が存在しないことを述べている. もしその結果が使用されない計算機の CPU 時間を大きくするだけならプログラムを速くすることは意味がない. もしメモリの標準サイズにより分類された部分で使われない場所の数を多くするだけなら, プログラムを小さくすることは意味がない. もしプログラム・エラーのためにできたプログラムを 5% だけ再実行させることになりそうなら, 実行時間で 5% 減らしても意味がない.

2番目の規則は, 最終的には最適化するつもりでいても, 最適化されてない設計でいつでも始めなければならないことを述べている. 最適化されていない設計のみが十分な理解に必要な明白さと単純さを持ちうるものである. もし論理的エラーを導くことなく最適化するつもりなら, われわれは自分のプログラムを十分理解しなければならない. プログラム保守にたずさわってきた者はどうみても単純でないプログラムを変えるのがどれほど危険かよく知っている. 明らかに無害な変更でも驚くべき, かつ悲惨な影響を持つものである.

この後の記述では、計算機パラメータのチューニングとアルゴリズムの変更による最適化はその対象外であることと、「カントールの有理数の数え上げ」を題材にして、その最適化をどの様に行うか、またその際に発生する特定のデータ構造や変数、プログラム順序に対する依存性について、COBOL でのプログラムを例に、ところどころでちくちくと刺しながら書かれています。本当に最適化というものが嫌なんだな、、というのが伝わってきてとてもいいなって思います。

私は COBOL についても他と同様さっぱりなので、コードの中身は雰囲気でしかわからなかったですが、上記の引用文だけでも、それぞれの規則(ルール)とその理由が明確に述べられていて、当時の時代背景を差し引いたとしてもとても面白く読むことができました。

あと、序文ではもう少し違う観点も含んで、最適化についての記載が書かれています。

最適化に関しては, 次の2つの規則に従っている.

  • 規則 1 最適化を行うな.
  • 規則 2 (専門家だけのために) まだ, 最適化を行うな -- すなわち, 完全に簡明で, 最適化されていない解決を得ないうちは行わない.

..(中略)..しかし, 2つのポイントは常に憶えておくべきである. 第一は, 最適化はシステムの信頼性を下げ保守を困難にする. それ故作ったり実行させたりするのがより高価になる. 第二には, 最適化が構造をあいまいにするので, すでに部分的に最適化されたシステムの効率を改良するのがむずかしい.

かなり薄い感想ですが、個人的にまとめるとこんな感じかと思いました。

  • 最適化にはお金(と労力)がかかる

  • 実益のない最適化には意味がない

  • 最適化は保守性の低下を招く

  • 早すぎる最適化は部分最適を招き、その後の全体最適の大きな妨げになる

その他序文では、システム設計者とプログラマを分けるのはばかげている、などの何故か今に繋がる話であったり、日本語版に際しての M.A.Jackson さんから訳者の鳥居さん (https://ja.wikipedia.org/wiki/%E9%B3%A5%E5%B1%85%E5%AE%8F%E6%AC%A1) に書かれている賛辞も読めて、とても楽しい読書体験でした。（全部は読めていませんが。。）

調べるものをもりもり見つけてぜひまた行きたい！

プログラミングも頑張ります。。

*1:今のところ食べたもの系は Threads に放り込むことにしています。