GUIGUI01​/memo06

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

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

(17) OSASK計画の長期計画（つづき）

• （以下の文章は6月上旬までには「川合のぼやき」に公開予定。つまりここは下書き。）
  
  
  
  
• 3.考察
  • まず2.のあちこちに印をつけておいたので、そこから話を始めようと思う。
  • *1の部分のOSの正当な競争は、これこそOSASK計画の基本的な目的の一つであって、だから「ぐいぐい01」はOSASK計画にとって大きな前進をもたらしたといえる。
  • しかし*2で指摘したように、アプリ開発者が「ぐいぐい01」用のアプリを作ることにメリットを感じすぎてしまうと、各OSのネイティブのAPIを使う人が減り、APIの改良という競争を妨げてしまうかもしれない。なんといってもAPIはOSの機能の一部であって、しかもかなり大きな要素である。その部分の競争を阻害してしまうかもしれないだから、これは危惧しなければいけない。
  • しかし考えようによっては、「ぐいぐい01」はAPIセットとしての最低ラインを担保しているともいえる。つまりどのOSででも、機能的・性能的に最低でもこれくらいは予備知識なしで利用できるように整備したともいえるのだ。これを超えるAPIでなければ使われなくて当然なのだ。これを超えるAPIがあるのなら、是非そのOS専用のアプリとして世に出し、うちのOS専用アプリにすればこんなすごいことができる、と示せばいいだろう。それはそのOSのアピールとして十分だろう。
  • そうはいっても、結局のところ既存のかなり多くのアプリが機能を損なうことなく「ぐいぐい01」用に移植できてしまうだろう。これはつまり、多くのアプリがその程度のAPIで十分に書けるということを意味している。そしてさらに嘆かわしいことに「ぐいぐい01」化することでサイズや速度が改善してしまうだろう。つまり既存のOSのAPIは「ぐいぐい01」以下であって、そんなバカらしいレベルで似たような機能を互いに非互換にし合って優劣の比較を阻害し、API改良競争を妨げてきたのだ。こういう低レベルな争いはもうやめよう、というのが「ぐいぐい01」がもたらす提案である。つまりはOSASK計画からの提案でもある。
  • *3の万能性の否定は、基本的にはOSASK計画の目的には合致しない考え方である。OSASK計画ではハードウェアのすべての機能を最も高い効率で利用できるようにすることを目的としている。その観点で見れば「ぐいぐい01」はわざわざ手かせ・足かせを作っているようなものだ。最大公約数的なAPIセットにとどまる以上、この方法で最高の機能や最高の性能は絶対に出せないと分かっているのだから。
  • これについてはこう考えてほしい。「ぐいぐい01」は100点満点を目指すのをあきらめた代わりに、まずは90点を確実に出そうというものである。というのも現状は50点や60点のレベルでの争いに終始してしまっていて、まずはこれを何とかしないとどうしようもない気がするからだ。また僕自身のプログラムレベルや設計センスも100点のAPIを作るにはまだまだ足りない。なにしろ満点というのは「もう究極でこれ以上改良の余地が全くない」ということであって、それは現時点ではとても自信を持って示せるものではないのだ。
  • こんな状態のくせに最高を目指そうと思ってしまったために今まで開発が遅れてしまった。・・・えせでいいやと妥協してやっと少しずつできたものの、徐々にそのえせに我慢ができなくなって今度こそもう作り直さなくてもいいような完璧なものを作ろうと思うと、またアイデアをまとめることができずに前に進めなくなる。こういうことを何度か繰り返して僕はようやく分かった。いきなり最高を目指してはいけないんだ、と。僕には経験が少なすぎる（そんな僕にも劣るような他のOS開発者は論外だとしても）。最高を目指すには少なすぎる。そんな状態からいきなり最高を目指せば、それはかえって時間がかかってしまうだろう。・・・かわのたて、こんぼう、でやっとスライムと戦えるようになった僕が、次はお金を貯めて最高のロトのつるぎを買おうと思うようなものだ。これは進歩が遅すぎる。武器や防具を少しずつ良いものに変えていって、戦う相手も徐々にステップアップしていくほうが、結局は早くロトのつるぎを買えるのだ。なんだか途中の武器や防具を買うためのコストが無駄になる分だけ損に思えるけど、そうではないのだ。いそがば回れとはこういうことを言うのだろう。
  • そもそも「最高まであともう少し」ということろまで世の中のソフトウェア技術が成熟していると僕は誤解していたようにも思う。だから僕はそれに追いついてさらにもう少しがんばれば最高になれるんじゃないかと思っていた。だからこそ次はロトのつるぎだと思ってしまったのだ。しかしここまでいろいろやってきて思ったのは、全然そうではないということだ。ロトのつるぎはまだまだ先だ。・・・そうであるならば、僕がロトのつるぎを得るまで何もリリースできずに悶々としていたら、そしてそのまま僕が引退して開発者として使い物にならなくなったら、その後に残された後世の人たちはどうすればいいだろう。そう、また僕と同じスタート地点からになってしまう。それじゃあダメなのだ。僕は登頂者だ。生涯で頂上までいける確率が非常に高いとはいえない以上、二合目、三合目、四合目と、要点で成果を分かりやすく示してチェックポイントを残していくべきだったのだ。つまりここは絶対に頂上ではないと分かっていても、あえて示すべきものがあるのだ。それが結果的にはOSASK計画の目的の達成を早めることにつながるのだ。だから「ぐいぐい01」は一見OSASK計画の目的からの後退に見えるけれども、実はより現実に即した中間解で、必要なものなのである。
  • そして世のOSのレベルが上がってくれば、最大公約数もまた大きくとれるようになるだろう。そうすれば機能的なカバー範囲も性能も向上した「ぐいぐい02」（？）を設計することができるようになるだろう。そしてその繰り返しも限界が近づいてきてやがて終わりが見えてきたときに、ついに初めて究極でOSASK固有のAPIを設計して、既存のアプリをこのAPI向けに書き直して性能を上げ、他のOSのアプリをエミュレータによって受け入れるべきなのだ。おそらくこれは気の長い話だが、しかしそれでもこれこそが最短である。
  • OSASK計画で僕が当初示した、まず互換性問題をエミュレーションで解決した後に性能競争・固有機能競争を始めるのは、手間が多いわりに前進が遅い。OSASKの高性能アプリを使って慣れてしまうと、そもそもエミュレーションしてまで利用したいと思えるようなアプリが少ないことに気づく（サイズが大きい、遅い＝性能が悪い）。それなら利用したいと思うものだけを移植するほうが現状では手っ取り早くも思えるし性能も上がる。OSASK計画が目指すところの最終的なゴールに早く到達するには、既存のすべてのソフトウェアを利用できるようにするための努力は後回しにすべきで、とりあえず過渡期の処置として「ぐいぐい01」みたいなことをしていけばよかったのだ。こういう共有基盤があればとりあえずそこへ移植することで当面は満足できるからだ。・・・僕は幸いにエミュレータ周りを後回しに開発することでこのことに気づくことができた。
  • こうしてみると、OSASK計画の初期の頃、エミュレータを作っていくなんて現実的ではないといっていた人たちは、論法は正しくなかったかもしれないけど、結論は正しかったことになる。まあ今だって最終的に作ることに変わりはないのだけれども、でもとにかく優先順位的にはもっと後ろであるべきだったことに違いはなく、だからエミュレータに批判的だった人はその意味で正しかったともいえると思う。・・・一方でエミュレータこそ早く作れと言ってきた人たちもいたけど、その人たちの意見をとりあえず保留にして優先順位を下げてきたいままでの方針は（僕の目的にとっては）正しかったように思う。僕は究極の高性能OSがほしいのであって、ろくでもないアプリが全部使えるようになったところでうれしくもなんともないのだ。究極のOSを得るために互換性問題をエミュレータで解決して競争を激しくしようと思っていたのであって、つまりエミュレータは手段であった（だって仮にOSASK専用アプリのほうがすべての面において既存アプリを上回っていたとしたら、わざわざエミュレーションさせてまでそれらを使いたいなんて思うだろうか？）。
  • 僕は確か工夫すればエミュレータは遅くはないとはいったし、もしかしたら最適化で本家よりも早くなるかもしれないとも言ったが、改善できるかもしれないのは実行速度だけであり、サイズについてはエミュレータはほぼ無力である（それに実行速度にしたって、OSASK用に移植されたものを超えることは絶対にできない・・・追いつくことなら万に一つくらいならありえるのかもしれないが）。しかしサイズが小さくなればHDDやFDやメモリカードなどの容量を節約することができる。バックアップもしやすくなるだろう。またメインメモリも減らすことができ、キャッシュヒットも増えて、ひいては省電力化に寄与できるのだ。そうであれば、エミュレータを作ることよりも、エミュレーションしてまで残したいアプリをいくつか選んで「ぐいぐい01」仕様にしておくことのほうがより生産的で効果があるだろう。それでもそれでカバーできないものはもちろん残ってしまうだろうから、それらについてはやむなくエミュレーターでカバーしよう。とこういうことである。
  • 以上はx86の32bit上での（つまりIA-32上での）OS改良競争とAPI仕様改良競争に関しての話である。ここからは、CPUの改良競争と命令セットの改良競争について考えを書く。
  • OSASK計画での出発点はIA-32限定だったが、かなり早期にIA-32に限定するつもりはなくなって、対象が「すべてのコンピュータ」になっている。こういう大きいことを言えたのは結局エミュレータを前提にしたからである。エミュレータさえあれば、CPUや命令セットの違いも原理的には乗り換えられる。これによりOSASKはOSや同CPUのハードウェア競争（AT vs TOWNS vs 98など）だけではなく、CPUが異なる環境間でも機能・性能競争が起きることを望んでいた。それにより将来、最高のハードウェアと最高のソフトウェアを得たいと思っていたわけだ。
  • それにもかかわらず、「ぐいぐい01」のアプローチでは結局IA-32用の汎用アプリができるだけで、他のCPU上でこれらのアプリを実行しようと思えば、結局エミュレータが必要になる。だからIA-32が究極のCPUでないかぎり、「ぐいぐい01」がやろうとしていることは本当に一時凌ぎで、なんら本質的な解決にはなっていないし、むしろそのように誤解されるかもしれない分だけマイナスとも言える。
  • この問題を解決するのは結局、javaや.netのようなアプローチを取るしかない。これらは結局どの実在のCPUの命令セットでもないのでどのCPU上で実行してもオーバーヘッドがあるが、しかしその代わりどのCPU上で実行してもそれなりの効率では動かせる（普通のCPUエミュレータの効率に比べればマシ）。・・・僕はjavaにも.netにも性能で満足できなくて、khabaというサブプロジェクトを起こしていろいろ考えてきた。これが「ぐいぐい01」よりもよい解決策であることは間違いない。
  • しかし残念なことにkhabaの設計は今の僕には荷が重すぎて（つまり経験不足で）、いつまで経っても最初のバージョンがリリースできない。最初から多くを求めてしまう悪い癖のせいかと思って、とりあえずたくさんの点で妥協してみても、やっぱりうまくいかない（すべてに妥協してしまうと、本当に将来javaを越えられるのか不安になるようなものしかできない）。
  • それで分かったことは、つまり僕にとっての最初のバージョンのkhabaは、五合目くらいの課題なのだ。一合目はやっぱり「ぐいぐい01」なのであって、まずはこれをやって経験を積むしかないのだろう。OSの壁を越えるのとCPUの壁を越えるのとを同時にやろうとするから苦しくなっていたわけだ。実際「ぐいぐい01」の設計作業は今の自分の能力の限界に結構迫っている気がするから、やっぱりまずはこれしかないのだろう。もどかしいし回り道なのは分かっているのだが、能力が無いので仕方ない。
  • だから今後どんなにx86-CPUが世間を席巻し、また「ぐいぐい01」がどんなに成功を収めたとしても、やっぱり汎用アプリとしてはkhaba仕様こそOSASK計画での本命である。むろんそれよりもさらに本命は、その後に出てくるであろう理想のCPUと理想のOSを使った環境下でのネイティブアプリである（そういう環境が確定すれば、わざわざkhabaだの汎用アプリ仕様を使うだので効率を下げる必要がない。惜しみなく最高性能を出すべきだ。そしてそのアプリを他の環境で使うときこそエミュレータで「遅くはなるけどとりあえず動く」であるべきだ・・・どんなに最適化能力があるエミュレータでも最高のCPUと最高のOSの組み合わせように最適化されたアプリを本家以上に高速にはできない）。
  • ここからはまた別の話である。些末なことだといってもいい。
  • efg01がそこそこ使えるようになれば、実はOSとしてのOSASKを使う機会が減るだろうと思う（特に開発のためにqemu上でOSASKを使うことは減るだろう）。これはつまり「ぐいぐい01」仕様のOSASKアプリが増えてもOSASKユーザが増えないかもしれないことを意味するし、むしろ他のOS上で動かせばいいやということになれば、ユーザは減るかもしれない。しかしこれはOSASK計画にとっては問題ではない。アプリが他のOSで動くというだけでOSASKの魅力がなくなったのだとすれば、それは結局その程度のOSだったということである。そうであればそういうOSはたとえOSASKであっても淘汰されるべきだから、これはこれでいいのである。それにユーザが減ってもOSASKとしては何も失わない。ユーザは減っても使えるアプリは増えていくわけだから、いったい何を嘆くことだあるだろう。まあ強いて言えば、OSを使う人が減るので人柱が減る程度だろうか。でもそれくらいは自分でやればいいだけの話だ。アプリが労せずして自然に増えることに比べれば、気にするようなことではない。
  • もしかすると既存のOS開発者も「ぐいぐい01」のようなアプローチを考えたことはあったのかもしれない。しかしそのたびに、そのせいでユーザの囲い込みの輪にほころびができてしまうのを恐れたのかもしれない。そこで僕はあえて言いたい、そういう考え方の時代は早々に終わるだろうと。結局ユーザが流出する可能性があるとは言っても、このアプローチによってユーザの選択肢が広がり、またアプリ開発者も移植のために苦労しないで済むということは間違いないのだ。ユーザの利益よりもOS開発者のせこい考えを優先するような時代は終わる。OSを選ぶのはユーザであってOS開発者ではない。だからユーザのためにOSはあるのであって、OS開発者のためにあるわけではないのだ。
  • そもそも移植作業なんてソフトウェア開発の中でもつまらないほうから数えて1位や2位にランクされるようなことだ。こんなくだらないことから解放されて、その時間を新アプリ開発やバージョンアップやリファクタリングに活用できるとしたらどんなにかいいだろう。
  • もう一つ細かい話を。
  • 「ぐいぐい01」仕様ではなくても、たとえばLinuxのelfやwin32のCOFF/PEでも、エミュレータなしで他のOS上で実行できるよという人がいるかもしれない。確かにAPI呼び出しをDLLでラッピングしてあればそうかもしれない。そうだとすれば、「ぐいぐい01」仕様は世界初でもなんでもなく、単にいち早くefg01を揃えて見せただけなのかもしれない。しかし仮にそうだとしても「ぐいぐい01」仕様には優位性がある。それはアプリが小さいことである。
  • Linuxにせよwin32にせよ、あの大きなアプリがどこでも動くようにできるのが精いっぱいであって、27バイトでhelloが書けるわけではない。もちろん今のOSASK-HBやefg01はサポートしているAPIがあまりに少ないからほとんど何もできないので比較する気にならないが、しかしLinuxアプリやwin32アプリに関して言えばefg01に相当するものすら出ていない（もしかしてWineはwin32に対するefg01のLinux版といえるのかも？・・・ただWineの開発の苦労から言って「ぐいぐい01」よりも多くのOSに対応版を出すのは容易ではないだろう）。だから汎用実行環境としての完成度を言うのであれば現状では五十歩百歩である。

こめんと欄