design010 :: OSASK計画

アプリが小さくなっていくことの意味

• (by K, 2008.12.28)

(0)

• これは当初「川合のぼやき」に書こうかどうか迷った内容のものを書くことにしたわけだけど、ここは僕のホームページではなくOsaskWikiなので他の誰が書いてもいいものだと思う。
• ただこのシリーズの趣旨としては、OSASKの設計に関する話を書いているので、他の人が書く場合もそれには準じてほしい。で、僕以外の人がOSASKの設計に関する話を書くなんてことはまずないと思うかもしれないけど、そんなことはなくて、たとえばこういう考え方のもとでこうしたらどうかという提案はできる。
• 基本的に一つの話題に1ページ使ってしまうので、ちょっとした提案であれば、OSASK-MLやimpressionsを活用してもらうほうがいいと思う。

(1)

• たとえばmakefontというアプリを例にとろうと思う。これはテキストファイルで書かれたフォントのデータをただバイナリに変換するだけの、大して芸のないプログラムだ（でもてっとりばやく8x16のフォントデータを作るには結構役立つ）。このプログラムは最初tolsetを使ってwin32用に書かれた。これをtolsetでmakeすると（そして当然UPXすると）3,072バイトだった。これでも普通の人が作る場合に比べればダントツに小さい（かなり多くの人はhello程度でも5KBくらい平気で使う）。
• このプログラムはやがて「ぐいぐい01」のAPIを使うようにソースを書き改められて、abcdw005～abcdw006向けのバイナリが、691バイトでリリースされた。
• さらにabcdw008で実装予定のAPIを使う形に修正され207バイトになり、ついにASKAで書き直されて72バイトになった。
• こうして3,072バイトもあったものが、72バイトになった。機能は全く失われていない。この差し引き3,000バイトは一体何なのか。それを考えてみようと思う。

(2)

• 僕の考えるところでは、これはムダである。API設計者とコンパイラ開発者とアプリ開発者がしかるべき努力をすれば72バイトでできるプログラムを、三方の怠惰（いわゆる手抜き）によって3,072バイトにしてしまっていたのだ。
• このままだとなんか毎度のwin32批判に見えて僕の趣旨が誤解されるかもしれない。じゃあこうしよう。3,072バイトから691バイトへの改良をひとまず脇においておいて、691から72バイトへの変化だけに注目しよう。
• 691から207への改善の理由を考えれば、これはAPIの設計を（さらに）まじめにやり、そのAPIを利用するようにアプリを書き改めたからに他ならない。明らかに手抜き度が減少したから改善したのだ。また207から72への改善も、「レジスタの使い回しなどで頭を使わなくてもとりあえず動くプログラムが作れる」C言語から「それらに配慮しなければいけない代わりに小回りのきく」ASKAで書き直したからこそ達成されたのだ。これも手抜き度の減少したからだ。
• ここから演繹すれば、つまり僕たちが本来72バイトで十分なものを3,072バイトも消費して使わされていたのは、ありとあらゆる手抜きが集積していたからである。3,072が本来のサイズで72ががんばった結果なのではなく、72こそ本来の姿で3,072は手抜きに手抜きを重ねた結果なのだ。

(3)

• 3,072バイトのmakefontにせよ、691バイトのmakefontにせよ、リリースしたのは僕なのだから、僕は非難されるべきだと思う。まあオープンソースで品質未保証だから、文句を言われる筋合いはないのだけれど、しかし72バイトで済むものを691バイトや3,072バイトでリリースしたというのもまた事実だ。これは絶対に褒められたことじゃない。ただabcdw008ができるまで待たなくてもよかったということだけが、せいぜいのいいわけだろう。・・・非難が無理だとしたら、せめて72バイトのmakefontはよくやったと賞賛されるべきだろう。でも、単にやるべきことを（やっと）やっただけだから、やっぱり当然ということで、賞賛って言うのもなんか違うけど。・・・僕は自分の過去のヘボアプリを自分で直しただけだから、ただの「自業自得」？

(4) 2008.12.30追記

• プログラムは結局CPUに対する作業手順を並べたものに過ぎない。これが大きいということは、手順が複雑で長いということだ。一方で「ぐいぐい01」アプリとして全く同じ処理を記述すると手順は短く簡潔に書ける。どちらがあるべき姿だろうか。
• これはあるインタビューアから聞いた話だが、有名な問答として、こんなものがあったらしい。
  • 質問「現在ソフトウェアエンジニアリングはどこまで進んだと思いますか？」
  • 回答「エンジニアリングとは不要な要素を排しその上で残った要素がどのような役割を持っているかを研究することであるから、現状でソフトウェアエンジニアリングなど始まってもいない」
• この回答者は現状ではまったく「不要な要素を排し」ていないと言いたいのだと僕は感じたのだが、しかしこの回答者が言うところの不要な要素というのが、僕がここで書いているムダに長くなったコードを指しているかどうかは分からない。もっと別のことを想定して言っていたのかもしれない。
• それでもとにかく僕がコードのムダを指摘したのは間違いのないことだし、それはきっとエンジニアリングに少しは役立つだろう。その効果は3,072を基準としても（繰り返し言うがこれでも世間の平均よりは十分に小さい）、その差は3,000バイトだ。どんな天才でも72バイトから更に3,000バイト減らすことはもちろんできないから、一番多くムダを刈り取ったのは間違いなく僕ということになる。
• 上記の問答の原文らしきものを発見。 http://gihyo.jp/dev/serial/01/alpha-geek/0024
  • 弾　「ソフトウェアエンジニア」としてもっとも重要なのはなんでしょうか。何をもってソフトウェアエンジニアというのでしょう。
  • Dave　ソフトウェアエンジニアというものはありません。少なくともまだないです。どういうことかというと、これ以上削れないところまで削るのがエンジニアリング。これ以上削れないところまで削るということは、どこまで削るとそれが壊れてしまうかというのがわかっていることです。まだソフトウェアに関しては我々はそのレベルに達していないんです。達していないから、まだソフトウェアエンジニアという言葉は嘘である。
  • 弾　じゃあ、我々がやっていることは何て呼んだらいいんでしょう。
  • Dave　コーディング。

(5) 2009.01.03追記

• 「ぐいぐい01」では、ただ正常終了するだけのアプリというものを書くことができる。それはヘッダだけの3バイト（シグネチャ2バイト＋フラグ類1バイト）になる。これはメモリ上ではRETだけの1バイトのプログラムになる。・・・同じことをDOSでやると、RETだけを普通に書くことになるので、1バイトで書ける（誤動作防止のためのシグネチャも何もない）。だからこの勝負ではDOSの勝ちだ。
• しかし何もしないで正常終了するなんて、はっきり言って意味がない。そんなもので勝ってもしょうがない。ささやかでもいいので何か意味あることをしなければいけない。そうすると次に一番短いプログラムは、適当なエラーコードを返して異常終了することだろう。DOSならこれは5バイトでできる。それに対して「ぐいぐい01」はどうかというと、エラーコードを指定せずに単に異常終了なら4バイト、きちんとエラーコードも指定するなら5バイトになる。だからこれは引き分けだ。
• では一文字表示して終了なんていうのはどうだろう。DOSなら6バイトになる。そして「ぐいぐい01」でも6バイトになる。だからこれも引き分けだ。
• そしてhelloやechoやcharsに見られるように、それ以上に複雑になってくると、「ぐいぐい01」はDOSに勝つ。ヘッダの分の不利さによって極めて簡単なアプリ（RETだけのこと）では負けるが、それ以上ではさまざまな工夫のメリットのほうが生きてきて負けないのである。

• たとえば10バイトで何かプログラムを作れといわれたら、普通ならひどく面食らうだろう。上記の通り1文字表示でも6バイトなのだから。でも「ぐいぐい01」ならechoくらいは作れる。
• では20バイトではどうだろう。日本語の文章でも10文字しか書けない。でも「ぐいぐい01」ならそれだけあれば、helloもcharsもつくれる。50バイトでも普通のOSならほとんど何もできないに等しいと思うが、「ぐいぐい01」ならcpyが作れる。たった50バイトのくせに、単なるファイルコピーだけではなくtek展開にも使えるし、ファイル連結もできてしまう。
• さらに100バイトならどうだろう。100バイトもあれば、makefontができるし（72バイト）、calc1もできる（usageを少しケチれば100バイトにできる）。・・・「ぐいぐい01」では100バイトがこんなに有用なのだ。
• naskはwin32版→abcdw009版で4821バイト減少した。これはつまり27.0KBが22.3KBになったということであり、見た目のインパクトとしてはmakefontの3072→72にはかなわない。しかしnaskが4.7KB減少したというのは間違いないことだし、それは上記で指摘した100バイトの48倍である！あいたスペースにそれこそいろんなものを入れられるだろう。

• 上記を書いて思ったのだけど、アセンブラで本気で書いた「ぐいぐい01」アプリのサイズを円に直したものは、僕がそのアプリに感じる価値にかなり近い。・・・たとえばhelloは17バイトだけど、僕はこれに17円くらいの価値を感じる。駄菓子屋さんのお菓子気分。echoもcharsも6円、13円というのはかなりしっくり来る。cpyが45円、makefontが72円というのも納得だ。
• naskは現在22KB程度だが、きっとアセンブラで書き直せば3～5割くらいは減るだろう。そうすると1万円台前半くらいか。確かにそれくらいの価値はあると（自分では）思っている。
• また、3072→72での、この-3000バイトに対する達成感も、本当は72円の価値しかないものを3072円でふっかけられて（標準小売価格が72円なのを知っていて）、それを見抜いて無事に別のお店で72円で買えたという満足感にかなり近い。僕の中では1バイトには1円くらいの価値があるのかもしれない。
• そう考えると、tolsetがどのくらい小さく改善したかで、僕が（心理的に）何円分相当得したかと感じているか分かるわけか。これは面白い。あとで計算してみよう。
• そう考えると、未踏ユースの200万円という金額を自分の中で正当化すると（予算は300万円だけど、税金や管理費で約100万円は消えた）、2MBくらいのダイエットに成功していれば、僕の価値基準としては合格といえる。OSASKや関連アプリや関連ツールと同等なものを一般的なプログラマが作ったら合計+2MBになるだろうか。なりそうだな。期間中に僕がやったことだけでは不足かもしれないけど、期間後にやったことも含めていいのなら、僕としては後ろめたさはない。
• tolsetのwin版→abcdw009版サイズ変化（対象11アプリ）：86419→45229：差は4.1万以上
• 約一年間で4.1万円というと社会的な仕事としてはお話にならないだろうけど、でもこの成果に4万円の価値があるといわれるとなるほど確かにそんな気が（僕には）する。

こめんと欄