2: 2009-01-04 (日) 00:34:36  |
3: 2009-01-04 (日) 10:26:49 |
| | -僕はとにかく効率のよい状態がほしい。そして効率を究極的にまで高めるためには、結局全ての部分を高効率なものに置き換えなければいけない。ファイルシステムだけ作り変えればいいわけじゃない。とりあえずここまででAPIとアプリについては解決できたとしよう。それでもドライバやカーネルやシェルやファイルシステムやウィンドウシステムや・・・それこそいくらでもある。.mjtさんの提案のように、適当に既存のものを流用できるのならしたいくらいだけど、そういう流用は結局は「とりあえず動いただけ」になってしまうことが多く、とても高効率とはいえない。動くだけでいいのならそもそもOSなんか作る必要がないのだ、僕の場合は。OSを作ることそのものは目的じゃないから、そんな効率の低いもので我慢できるのならわざわざOSを作るまでもなく、Windows上やLinux上でefg01していれば用は済む。 | | -僕はとにかく効率のよい状態がほしい。そして効率を究極的にまで高めるためには、結局全ての部分を高効率なものに置き換えなければいけない。ファイルシステムだけ作り変えればいいわけじゃない。とりあえずここまででAPIとアプリについては解決できたとしよう。それでもドライバやカーネルやシェルやファイルシステムやウィンドウシステムや・・・それこそいくらでもある。.mjtさんの提案のように、適当に既存のものを流用できるのならしたいくらいだけど、そういう流用は結局は「とりあえず動いただけ」になってしまうことが多く、とても高効率とはいえない。動くだけでいいのならそもそもOSなんか作る必要がないのだ、僕の場合は。OSを作ることそのものは目的じゃないから、そんな効率の低いもので我慢できるのならわざわざOSを作るまでもなく、Windows上やLinux上でefg01していれば用は済む。 |
| | -そう考えると、なかなか道は長くて遠くて険しい。でも他にやりようがないから仕方ない。ほしいものはほしい。いくら大変そうでも、それを理由に自分にとって必要のない別の何かを作る気にはならない（大変だからあきらめるということはありえるかもしれないけど）。 | | -そう考えると、なかなか道は長くて遠くて険しい。でも他にやりようがないから仕方ない。ほしいものはほしい。いくら大変そうでも、それを理由に自分にとって必要のない別の何かを作る気にはならない（大変だからあきらめるということはありえるかもしれないけど）。 |
| | + | *** (3) |
| | + | -なんと.mjtさんが早くもお返事を書いてくれた（忙しいのにどうもありがとうございます）。 |
| | + | --http://d.hatena.ne.jp/mjt/20090104/p1 |
| | + | --http://d.hatena.ne.jp/mjt/20090104/p2 |
| | + | -いい話題だと思うので論点を整理してお返事しようと思う。まず順序を逆にしてp2のほうからいこうと思う。例によってまた引用から。 |
| | + | 要するに、 |
| | + | |
| | + | あのリストは、「今後近代的なPCで動作するOSを製作するために必ず通る道」を挙げたもので、 |
| | + | デバイスドライバを作るとか、Windowsystemを作るとかはこれらの『後』に来ることを想定している。 |
| | + | |
| | + | もちろん、あのリストを誰かが代表して埋めて、フレームワークとして共通化するのも |
| | + | 方向性としては想像できる。 |
| | + | |
| | + | コンパイラがself-hostingにならなければならない理由は、Linuxのカーネル以外に依存する |
| | + | デザインにするとHypervisorとLinuxユーザランドの両方に依存してしまうため。 |
| | + | また既存のソフトウェアの流用を非常に難しくする。 |
| | + | -要するに.mjtさんとしては(1)のリストは自分の想定しているOSの開発だけに適用されるものではなく、OS開発一般に適用されるものだとしている（＝僕の解釈は違うと指摘している）。この主張の前にp1のほうにも意見があるので、本当はそっちを先に解説するべきかもしれない。でも僕はあえてこの順序でお返事したい。でも僕はp1の内容に触れるような反論は書かないし、読み手にもp1を読んでからここを読むことを期待している。 |
| | + | -何から作るべきかということに関して言えば、僕としては別に何から作ってもいいじゃないかと思う。IPLから作りたい人はいるし、でも最初はGRUBでもつかっておけばいいじゃんという人もいる。それをあえてこの順序で作るべきだとしなければいけないのがよく分からない。・・・僕の経験から言えば、自分が作りたいところから作るのが一番うまく行く気がする。.mjtさんはもちろんファイルシステムの改良がOS開発の主たる動機だから、最初にファイルシステム関係を作りたいと思うのはとてもよく分かるし、僕もそうするべきだと思う。でもだからといって、他のOS開発者が何を重要に思うべきかとか、何から作るべきだとまで言及してしまうのは、やっぱり勇み足なんじゃないかと思う。・・・でもこれは自分のOS設計に強い確信をもっている証拠でもあるから、まあ勇み足しちゃうくらいがちょうどいいといえばちょうどいいんだけど（笑）。そういうことを考えると、僕がここでこんなツッコミをするのはいかにもジジくさい。黙って心の中で「若いのう」と微笑むべきだったかもしれない。 |
| | + | -あとコンパイラの話も、結局は「既存のソフトウェアの流用」のためであって、既存のソフトウェアの流用にあまり興味がなければ（たとえばOSASKのように作り直す気満々なら・・・笑）結局必然でもなんでもない。結局.mjtさんの論は、「○○ではないのは現実的ではない」という隠れた前提がたくさん積み重なっていて、それを全て満たしたOSのみにしか当てはまらないと思う。僕としてはそういう一方的な想定を置くことは良くないと思っている。当たり前そうに思えることを疑ってみる人が少しは必要だから。 |
| | + | -さて次はp1のほうを。まずはやっぱり引用。 |
| | + | API or Language(なぜAPIでなくてファイルシステムなのか) |
| | + | |
| | + | 個人的には、究極に効率的なシステムのためにも、APIを決めることよりも「記述環境」を |
| | + | 作ることに意義が有ると考えている。 |
| | + | |
| | + | システムとして出荷されたときのバイナリサイズよりも、実行時に占めるメモリサイズのほうが |
| | + | 多分重要で、そのためには必要な部分だけをロードするといった対策が必要になる。 |
| | + | 出荷されたときのバイナリサイズにしても、部品の共通化を進めるのは良い影響を与える。 |
| | + | |
| | + | (少なくとも、僕の知識ではAPIコールの効率性とシステムの効率性を関連付けられない) |
| | + | |
| | + | そもそも、現代的なシステムではプログラムよりもデータの方が圧倒的に大きな存在感を占めている。 |
| | + | メモリからキャッシュへのコピー、データの配列、そのほかのI/Oがシステムの速度を決定付けている。 |
| | + | |
| | + | (もし必要なら、)良くデザインされたファイルシステムはこの側面にアプローチできる。 |
| | + | |
| | + | ただ僕の主張としてより重要なのは、APIはプログラマにしか触れないけれどファイルシステムは |
| | + | ユーザ全員が触るという点で、より端的に表現すれば「多くのプログラミングは |
| | + | 本来プログラムの外部で行われる必要が有る」。 |
| | + | |
| | + | 一つ一つのプログラムを小さくすることよりも、プログラムの数そのものを減らした方が |
| | + | 効率的に思える。 |
| | + | -最初の段落（個人的には～）と、最後から2番目の段落（ただ僕の主張として～）については、僕もおおむね同感だ。つまりたとえばプログラマでない人でも（従来のOSではプログラミングしなければできなかったような）高度な操作が簡単にできるようなOS（というかシステム？）こそ希求されるべきだというのは、.mjtさんからの以前からの主張だし、それはその通りだと思う。そしてその実現のためにファイルシステムを作り変えたほうがいいのではないかという主張も（ファイルシステムからオブジェクト管理システムにアップグレードする感じ？）僕の大いに支持するところだ。 |
| | + | -しかしそういうシステムをたとえばFATファイルシステム上に絶対に構築できないかというと、そんなことはないと思う。カーネルだって実はLinuxやITRONとかを使っても別にできないことはない。どちらも効率は決してよくはないだろう。しかしできるできないの話で言えばできる。つまり.mjtさんが論じているのは究極的には人間とコンピュータのプロトコル（つまりUIだ）であって、それを実現するためのAPIやファイルシステムやカーネルはどうにでもできるのだ。つまりこれは独立した問題であって、いっしょに論じるべきではないと思う。 |
| | + | -もうすこし踏み込んで言えば、.mjtさんは「コンピュータに努力をさせて」人間に近づかせるべきだと考えている。そのほうが生産性が上がると考えている。そしてそれを効率的に実現できるように全ての下位のシステムは再設計されるべきだと信じている。たしかにそれは一つの見識だし僕もそういう設計方針のOSが絶対にあるべきだと思う。 |
| | + | -でも、OSASKはそういう方針じゃない。むしろ正反対だ。僕は（ある程度は）「人間に努力をさせて」コンピュータに近づかせるべきだと思う。たとえば僕は本気で人類は10進数を捨てて16進数に切り替えるべきだと信じている。.mjtさんの考えではこれはありえないと思う。人間が10進数に慣れているのだから、コンピュータが歩み寄って10進数を使えばいい、となるだろう。 |
| | + | -僕は(1)で効率のよい状態がほしいと書いたけれど、そのためにOSだけを、ソフトウェアだけを作り直せばそれで終わりだとは思っていない。先の進数の例のように、人間性などに影響のないことであれば、それらはすべてコンピュータ寄りの常識に自分自身を再プログラミングしたいとまで思っている。だから（合理性とは程遠い）現在の人間の感性を中心にOSを設計するつもりはない。まずコンピュータにとって何が一番容易であるのかを突き止めて、その上で人間にどうしても受け入れがたいところと人間にも容易に受け入れられる部分の2つに分類し、コンピュータに妥協を迫った場合のオーバーヘッドを見積もり、その上でどうするかを考えたい。 |
| | + | -結局.mjtさんが追い求めているのは現在の人間にとって最適なOSであり、僕が追い求めているのはニュータイプにとって最適なOSである。そして僕はオールドタイプの人間の癖にニュータイプ用OSを使い続けることで、いつか準ニュータイプに・・・（笑）。 |
| | + | -つぎにアプリのサイズについて。「システムとして出荷されたときのバイナリサイズよりも、実行時に占めるメモリサイズのほうが多分重要」というのは僕も基本的には賛成だ。だから「ぐいぐい01」は無圧縮の場合でも他のOS用アプリよりも小さい。でも、ファイルキャッシュやディスクスペースの節約を考えたら、圧縮して小さくなるのなら圧縮しておくほうが有利なので、さらに圧縮を適用しているに過ぎない。 |
| | + | -データのサイズのほうがサイズとしては（ストレージ使用量もメモリ使用量も）影響が大きい、むしろ圧倒的だ、という点についても基本的には同感だ。でもじゃあ、データファイルをこれ以上小さくできるのか？僕にはアイデアがない。tekで出し尽くした。個々のファイルフォーマットまで再検討すれば改善の余地はあるだろうが、それをやるとして、まず最初に目を付けたのが実行ファイルフォーマットだったというだけのことだ。これはデータじゃないけれど、でも削る余地がたくさんありそうだったのもまた事実だったので。 |
| | + | -そして最後の段落の「一つ一つのプログラムを～」というのがあるが、僕はむしろプログラムは部品化して組み合わせて使用していくという方向性を追求したい。これでも「必要な部分だけをロードする」は結果的に実現できる。これをやるには、ある複数の機能をもつアプリケーションを複数に分割したとして、個々に巨大なヘッダが含まれるのならロード時間の無駄だし、合計サイズもやたらと増える。これでは分割に及び腰になる。しかし「ぐいぐい01」のようなものならそういうことはない。・・・これはあくまでも内部実装の話であって、ユーザがいつもパイプなどでこれらの部品をつないでいかなければいけないということではない。makeやシェルスクリプトなどで隠蔽されていていいのである。 |
| | + | -それにプログラムの数を減らすことと個々のプログラムを小さくすることはトレードオフじゃないので、どちらがより効率的かを論じるべきではないと思う。つまりプログラミング不要なケースを増やしてプログラムの数を減らすことはできるし、その一方でAPIやファイルフォーマットを追及して、個々のプログラムをより小さくすることもできる。どちらを先に着手するかという話はありうるけど、ここは開発の優先順位の話題じゃない。 |
| | + | -最後に「APIコールの効率性とシステムの効率性を関連付けられない」について。これは結局は簡単な話だ。たとえばある出力を得るために、100ステップの工程が必要なシステムと10ステップの工程だけでできるシステムがあれば、どちらが効率的だろうか。これを論じるには、それぞれのステップの処理時間をつぶさに比較しなければ正確なことは言えない。しかし第一近似として、10ステップのほうが効率はよさそうだということはできる。そして僕が言っているのも結局はその程度だ。それ以上の精度を出すにはベンチマークなどをやるしかない。・・・近似を否定して関連性は全くないとして片付けてしまうことはもちろんできるが、そこから何か得られるだろうか。僕はそれよりも近似は近似として受け入れて、役に立ちそうな場面では利用し、むしろそれが不十分であればその近似精度を上げる方法を考えたい。 |
| | | | |
| | * こめんと欄 | | * こめんと欄 |
| | #comment | | #comment |
