GUIGUI01​/memo09 :: OSASK計画

ぐいぐい01に関するメモ-09

• (by K, 2008.11.22)
• メモのうち重要な部分をそのうちまとめてまともなページを作る

• （註）[OSASK 00113](abcdw0004)の結果があまりに劇的だったので相当気が大きくなっています（笑）。そのあたりの事情を察して割り引いて読んでください。
  • ちなみにobj2bim4eを「ぐいぐい01」に移植してみたところ、12,800→7,212とほぼ半減となっています。やっぱりすごい。
  • ちなみにgas2naskを「ぐいぐい01」に移植してみたところ、11,155→5,114と半減以上となっています。やっぱりすごい。

(20) 「ぐいぐい01」こそ理想のAPI

• まずは移植性というところから書こう。世間ではプログラムをきれいに書けとか、できるだけ標準関数だけを使って書けとか、ソースはオープンなほうがいいとか、まあそういうことがちょくちょく言われる。これは改良したい場合（他人に改良させたい？）と、移植したい場合の二つの理由からなると思われる。この改良したいという点に関しては、まあ基本的にごもっともなので僕から言うことはない。しかしこと移植性の確保のためということであれば、僕は言いたいことがある。
• まず最初に言っておきたいのは、「究極の移植性とは、移植をしないで済むことである」ということだ。つまり100%のソース互換が達成されるのであれば、プログラムがどんな内容だろうと、移植性を理由に文句を言われる筋合いはない。また更に進んでバイナリ互換まで達成されているのであれば、使っているコンパイラがやたらと古い版で入手困難だったり、物凄く高いコンパイラを買ってこないとmakeできないようなものであったとしても、さらにはそもそもソースが非公開であったとしても、そんなことは全く問題にならない。
• つまり「ぐいぐい01」がやってみせたことは、移植性を改善するためのある種の究極的な回答である。そしてそのような高度な移植性を実現するにあたり、一体どれほどのコードが必要なのかを示したのだ。それがefg01であって、それはwin32版で現状10KB程度である。こんなのはOSの大きさからすれば誤差みたいな大きさであるといってもよい（OSASKにとっては10KBの差は全く無視できないけれど）。しかも「ぐいぐい01」は高い移植性を提供しただけにとどまらず、各アプリのサイズに対して驚異的なアドバンテージまで付与しており、なぜ何メガもの（OSによってはギガにせまる）コードを書いておきながらこの10KBを書かなかったのだろうと思われてならない。それすらしてこなかった人（思いつけなかった人）に移植性について何か言う資格があるだろうか（註：もちろんある。過去の自分に落ち度があっても正しい事は当然言っていい。しかし恥を知るべきだ）。
• もちろん「ぐいぐい01」の方法はCPUの命令セットの壁は越えられない。それについては今まで言われてきた移植性確保の方法を実践する必要がある。しかし今まではwin32とx86用のLinuxのように、CPUが同じで命令セットに差がないのにソースレベルの互換性までしか保てなかったのだ（＝標準関数を使えということ。ちなみに標準関数だけを使っていてもint幅などが異なればソース互換は保てない可能性が少なくないので、標準関数の使用は「ぐいぐい01」以上の移植性があるのかというとそんなことはない）。たった10KBでできることをしてこなかった正当な理由はない。
• もちろん「思いつけなかった」と言うことはできる。しかしこれがそれほど難しいことだろうか。むしろ僕にはこの問題をこの角度で解決する気がなかったとしか思えない。それで人とは違った書き方をする人（まあ多分僕もその一人だ）を、ただ非難しただけである。プログラムの書き方や言語だっていろいろな可能性が追求されて悪いことなんて一つもないはずなのに、そのせいで移植性がなくなるからやめろという。本当はただ自分が無能で、その人のプログラムについていけないだけなのに。そしてそれを認めたくないあまりに、問題があるのは自分ではなく変わったプログラムを書く人のほうだという。そしてそのために「移植性」という呪文を唱えているに過ぎず、この問題を解決しようと本気で思ったことがないのだ。本気で考えたことがあるのなら、たった10KBのプログラムが思いつけないなんて、結局ちっとも優秀じゃない。
• また言われたほうも言われたほうである（これは過去の自分が該当）。けなげにも言われたとおりだと思ってしまう人がいる。それでせっかく自分にあった可能性をつぶし、どこにでもいる（＝「かけがえのない」の反対）プログラマになってしまう。そうではなくて、なんだとーまけるもんかとefg01のようなものを作ってしまえばよかったのだ。そうすれば言われない非難はもうなくなる。
• みんなが英語を使っているんだからお前も使え、ということはできる。しかし自動翻訳機さえ作れれば、そんなことを強要されるいわれはないのだ。そして自動翻訳機はみんなが漠然と思っているほどむずかしくはなかったのだ。エスペラント語に相当する「ぐいぐい01」さえ使えば、自動翻訳機で任意の言語に容易に翻訳できると、efg01は実証しているのだ。しかもそんな通訳しやすい、言い換えればそれぞれのOSの特徴に特化できていないというハンデがあるはずなのに、結局はそれぞれのOSのネイティブAPIで書くよりも小さくなってしまうのだ。しかもこの差は「ちょっと」などと形容してごまかせるレベルをはるかに超えている。既存のOSのAPI設計者は（残念ながらこれには旧OSASKも含まれる）は一体何をやっていたのか。わざわざ非互換なAPI仕様（＝efg01的なものを作りにくいAPI仕様）を量産してきて、それでどんなメリットがあったというのか。そしてそれをアプリプログラマに偉そうに強要してきた。しかし、今やどっちが強要に値する仕様かは明確である（といっても僕は何も強要しないが）。

• 次はOSの互換性について書こう。たとえばWindowsのAPIがある。これは互換性を維持するのがとても大変らしい。バージョンアップのたびに似たようなAPIが追加され、それでコードがどんどん膨らむ。最初から完全なAPIが設計できればそれが最高で最善だが、まあ人間は最初からすべてを想定することが得意ではないので、やはり後になってあれこれ手直ししたくなってしまうのは責められないところだ。
• そしてそのときに旧APIを捨てて新APIに置き換えることがもしできれば、コードの肥大化は十分に防げる。というか、正直僕はWindowsの肥大化の理由が互換性の維持だけで説明できる量をはるかに凌駕している気がしてならないんだけど、でもまあ世間ではそういうことになっているので、ここではそれを受け入れることにする。
• さてもし最初のバージョンのWindowsのAPIが、「ぐいぐい01」のような仕様だったらどうだろう。もしそうなら、たとえWindowsがLinuxやMonaOSくらいに激変するようなAPI仕様の大転換があったとしても、別にたいした問題にはならない。10KB程度のefg01に相当するものを入れればいいだけなのだから。・・・想像してみてほしい、もしこうであったら、Windowsの開発者はどれほど自由に次バージョンのOSを設計できるだろう。互換性の維持のためにコードが増えてメンテに戦力を取られ、バグが取れませんでした、なんてことはなくなるのだ（少なくともそういう言い訳はできない）。
• 僕がWindowsの開発者だったら、efg01を見て、きっと「ああなんてことだ、こうしておけばよかったのか」と地団太を踏むと思う。今のWindows開発者がそのように思うかどうか分からないけど、思わなかったらまだまだなんだろうなと思う（正解を見せられて理解できる人は多いけど、正解を見せられてもまだ理解できない人も世の中にはいるから）。

(21) 1bitの本当の価値

• 多くの人は1bitの本当の価値を忘れていると思う。特に最近はたとえば2GBのmicroSDが299円とかになっていて、1MBの値段は0.15円くらいだと思っているのだろう。これはある意味では正しい。もしそのプログラムやデータがずっとそのフラッシュメモリの中だけにあるのなら。
• でもよいプログラムであれば、公開後に多くの人がインストールすることになるだろう。そうすると、もし100人がインストールするのであれば、人類全体の総コストは100倍になる。1MBあたりの単価は実に15円にまで上昇してしまう。1万人ならさらにその100倍だ。
• これはただインストールしただけの話であって、実際に使うことは考えていない。実際に使うとなると、（一時的に）メインメモリにロードされ、さらには（刹那的に）CPUのキャッシュに取り込まれることになる。CPUのL1キャッシュは、今でも64KBとか128KBくらいしかない。だからすぐあふれて追い出される。そして必要になるとまた取り込まれる。こうして動作時間の結構な割合が実際の命令の実行そのものではなく、キャッシュへの出し入れだけに使われている（キャッシュミスヒットによるストール）。ヒット率そのものはかなり高いのだが、ミスヒット時のペナルティはかなり大きいので、結果的に動作時間に占めるキャッシュの出し入れしかできていない時間は結構な割合になってしまうのである（プログラムの書き方によっては50%を超えることもある）。
• これは結局、消費電力の増大と時間の浪費という形で現れる（今は電気代はそんなに高くないので、この時間が最も効く）。その点で行くと、1MBの一人当たりの値段は断じて0.15円などではない。30分で終わるはずの処理に1時間かかってもいいのか。時給600円だとしても、一人の、しかもたった一回の計算で300円の損失である。これが1万人だったらどうだろう。これが週に何度も実行する処理だったらどうだろう。残念ながら僕は1bitの容量が平均でどのくらいCPUのミスヒット率を上げるのかはわからない。だから具体的な金額で示すことができない。
• まあ現代では30分や1時間も大計算をさせる人はまずいないので、この例は適当ではない。でも実行ファイルをダブルクリックしてからウィンドウが開くまでの時間になんかイライラすることはないだろうか。あのわずかな時間はせいぜい1秒とか3秒くらいだろうと思うが、そしてそれは時給600円換算では0.17円とか0.50円程度でしかないのだが、しかしそれで仕事の腰を折られたデメリットはそんな金額で見合うものでは断じてなく、そしてこういう時間は主にストレージからメモリへの読み込み、メモリからキャッシュへの取り込み時間がほぼすべてなので、プログラムサイズが半分になれば時間は半分になる。しかもみんな小さければディスクキャッシュが効いてストレージにアクセスしないで済むこともあるだろうから、時間は半分どころではない。
• でもまあ非公開で結局自分しか使わないプログラムなら、被害は1倍にしかならないのでたいしたことはない。まして、一度やればもうめったにやる必要のないような処理であれば、別に10MBでも構わない。

こめんと欄