room​/000e のバックアップソース(No.2) :: OSASK計画

• 差分^[1] を表示
• 現在との差分^[2] を表示
• room/000e^[3] へ行く。

* 特別会議室
-(by [[K]], 2004.06.03)
-詳しくは[[room]]参照
--この会議室内のトップページ：[[room/000]]

*** 圧縮しないのは非常識か？
-[[room/000d]]からの続き

-配布時にはアーカイブ+圧縮、保存時にはOSがサポートする圧縮ファイルシステムを使うというのが現在では一般的でしょう。川合さんの考えと比較すると川合さん側のメリットは、ファイルを取得してから展開する必要がない、ファイルをリムーバブルメディアで持ち運ぶ際に再圧縮とアーカイブを必要としない、KHBIOSのようにブート時に圧縮ファイルが扱える。デメリットは他のOSがサポートするかどうかは未知数(プロプライエタリなOSではかなり低い)であること、現在の主要なアーカイバに対して圧縮の速度は(改良したとしても)遅いため使いづらい。これが私の現時点での所感です。ユーザが圧縮されていることを意識させないという点では、伸張をファイルシステムが行っても、圧縮されたファイルフォーマットをロードした後に伸張しても実質は変わらないと考えます。 -- [[小柳]] SIZE(10){2004-05-31 (月) 13:31:21}
-tek1の圧縮速度は測っていないので分かりませんが、(圧縮速度が遅い)bzip2に比べてもさらに2倍以上かかるとしたら、デメリットの2番目はかなりマイナス点になる気がします。 -- [[小柳]] SIZE(10){2004-05-31 (月) 13:35:11}
-ええと、他のOSが自動展開や展開用APIなどを用意するかどうかは、あまり重要ではありません。OSの支援がなくてもアプリがやればそれでいいことです（edimg/obj2bim方式）。ユーザの使い勝手的には同じでしょう。アプリを作るのが楽になるかどうかでしかありませんから。 -- [[K]] SIZE(10){2004-05-31 (月) 15:08:40}
-配布時にアーカイブにするのは今までどおりでいいと思います。つまりlzhやzipなどで。もちろん、itk（edimgとtekを使ったアーカイブ形式）でもいいですが（これだと圧縮・展開にtek用のルーチンを流用できるということだけがメリット）。 -- [[K]] SIZE(10){2004-05-31 (月) 15:12:23}
-tek1/tek2の圧縮速度は測るに値しないほど遅いです。これはtek1/tek2のフォーマットに起因する問題ではなく、純粋にbim2binの手抜きです。今、その手抜きのせいでデバックすら困難になっているので、圧縮速度を上げようとちょっと改良中です。tek圧縮の主眼はJPEGやmp3のように「圧縮したまま使えるような」圧縮形式であることです。mp3を聴く時にわざわざWAVファイルに展開してから聴く人はいないわけで、そんな感じの汎用可逆圧縮形式を目指しています。これの重要なポイントは展開速度であって圧縮速度ではないです。mp3をエンコードする回数よりもデコードする回数が圧倒的に多いのと同じ感じです。・・・そのせいでずっと手抜きしてきただけです。 -- [[K]] SIZE(10){2004-05-31 (月) 15:19:33}
-ファイルシステム上のでの圧縮に関してですが、僕はこれには否定的です。これが（ファイルの）tek圧縮の出発点でもあったので一応見解を書いておきます。ファイルシステム内で圧縮する場合、必然的にそのファイルシステムから出て行くと圧縮は解かれます。たとえばcpなどでコピーした場合、おそらくシェルはファイルを読んで、それを書き込むのでしょう。ファイルシステムはわざわざ一度解凍して、また書き込み先で圧縮するわけです。これはいかにも効率が悪いと思いました。また、ftpする場合はどうかというと、これもサーバのファイルシステムから出て行くときに圧縮を解かれて、ネットワークでは無圧縮のままか、もしくはまた別の形式でわざわざ圧縮され（その場合はクライアント側で戻される）、最後にクライアント側でまたファイルシステムが圧縮するわけです。どう考えても負荷は高くなります。これはいやだと思いました。それで今のOSASKのような形式でファイル圧縮をサポートしたいと考えるようになりました。 -- [[K]] SIZE(10){2004-05-31 (月) 15:25:40}
-またファイルシステムで圧縮する場合、空き容量が実にあいまいで分かりにくくなります。あるファイルがあって、これが容量的にそのドライブに書き込めるのか書き込めないのか。それは結局書いてみないと判断できないわけです。そういうのもなんかいやなファイルシステムだなーと思いました。 -- [[K]] SIZE(10){2004-05-31 (月) 15:29:08}
-ところで、「圧縮の速度は(改良したとしても)遅い」というのはどういう根拠でしょうか？ひょっとして改良というのは、bim2bin4gまでのパラメータ最適化ルーチンのことですか？それとも今やっている最長一致検索ルーチンの改良のことですか？最長一致検索ルーチンを改良しないと一般的なアーカイバの圧縮速度にはなりません。今やっている改良は、まさにその最長一致検索部分です。bzip2とは圧縮の根本的なアルゴリズムが違うのでわかりませんが、圧縮速度をたとえばLHAと同等の速さにはできます。改良を続ければ。だから将来的な見通しとしては、圧縮速度に関する懸念はあたらないと思います（圧縮の処理オーダが今はO(n^2)ですが、これをO(nlog(n))にしているところなのです）。 -- [[K]] SIZE(10){2004-05-31 (月) 15:35:08}
-新たに圧縮速度の話等が出てる中で申し訳ないのですが、一連の中に「革新的な試み」について否定する話ってありましたか？むしろ今までのOSASKでは出来ない、多量データ等を（無）圧縮で扱う「革新的な試み」について「非常識」と言われる事に異議があると言ってきたと思うんですが？つまりその論理では、これを否定しFDユーザにこだわる方が例外で保守的になってしまいかねませんよ。独自技術を他に広めようが、無圧縮という名の汎用圧縮法で扱おうがメディアが充分速くて容量に余裕がありさえすればその試み自体に大差はないのに、一方は非常識扱いというのが納得できなかったわけです（強いて言えば準備等がいらない代わりに最善だとまではいえないだけ。しかしそれを言ったらそもそもSFとか採用できなくなってしまう）。そして他方(非圧縮)を広めたい為にもう一方について否定的な見方をしたなんて覚えもないです。あればご指摘ください。ただ「革新的な試み」のベース(KHBIOS)を早く披露してほしいなとは思いました。圧縮はそれ自体で未踏のテーマになる程キリがない訳なので、解凍速度が重要だと言った人の為に改良続けているのだとしたら今の段階ではそもそも必須ではない（我慢出来る）ということを説明しようとしただけです。というわけで、それが保守的かはともかくとして、「常識的だと思うならそれはそれで結構ですよ」というのは「非常識というのは撤回」して頂けたという意味に受け取って宜しいですか？私が話の中で気になったのはそういう（古典的だといって）初めから論外（あるいは例外的な場合）として選択肢を狭めるような所だけだったので、ちょっとそれだけ確認しておきたいです。 -- [[名無しさん]] SIZE(10){2004-05-31 (月) 21:44:20}
-開発優先順位について：展開速度のためにフォーマットを直すのはきわめて重要です。もしtek0のままほうっておいたら、「圧縮展開は遅いもの」という間違った印象が広まる上に、速く展開できない形式ばかりが（負の）資産として増えます。これは非常によくありません。僕は何よりも先に優先すべきものと考えております。・・・しかし今は開発優先順位の話題ではないので（それをやると論点がぼやけるだけなので）、この話はこれくらいにしておきます。 -- [[K]] SIZE(10){2004-05-31 (月) 21:58:37}
-非圧縮が革新的とのことですが、つまりこう解釈していいでしょうか。たとえば今、誰かに自分がバンド演奏したサウンドデータを配布するとしたら、mp3とかその他の音声圧縮形式を使うのが常識的で、生のwavで渡すというのは（これをもとにエフェクトを掛けるとかCD-DAとして書き込むなどの加工用ではない限り）非常識だと言っていいと僕は思います。・・・もちろん過去にmp3などの形式がなかった時代があり、まあそれでもADPCMくらいはありましたが、とにかくそういう時代なら非圧縮でもそれはやむをえなかったでしょう。しかし今、あえてwavで配布することこそ革新的だといって理解できる人がいるでしょうか（wavでも配布可能であることはもちろんいいことです）。少なくとも僕にはさっぱり分かりません。しかも僕に理解できる、非圧縮のほうがいい理由（特殊ではないもの）は一つもありませんでした。''何かなるほどと思える理由があればいいのです。''むしろ、音楽データはどんなに短くてもwavではなくmp3にしよう、1秒だって0.5秒だって圧縮しておくべきなんだ、というほうがよほど説得力があるように、僕には思えます。 -- [[K]] SIZE(10){2004-05-31 (月) 22:05:19}
-僕が結構だと言ったのは、もはやまともな議論はできないと失望したからです。僕は自分の意見を撤回していませんし、非常識という見解に何の問題もないと今も認識しています。 -- [[K]] SIZE(10){2004-05-31 (月) 22:06:33}
-（SF16のことを持ち出すのは一向に構いませんが、16の部分を省略しないでください。大事なフォーマット名の一部ですし、何を書いているのか気が付くのに苦労しています。） -- [[K]] SIZE(10){2004-05-31 (月) 22:12:17}
-念を押しておきますが、僕は配布形式にしか言及していません。無圧縮でデータを「扱う」なんていうのは（たとえば作業用ファイルとか）、むちゃくちゃにあたりまえのことです。勝手に話を広げて論点をぼかさないようにお願いします。僕が否定的な見解だと指摘したのは、圧縮がよくない理由として、そのデコーダの普及を理由にしたからです。そんなことをいったら新しい汎用的なフォーマットは一切提案できません。一番おろかな理由だと思います。僕がちゃんと他のOSでもデコーダが利用できるように配慮する（＝デコーダを移植するなど）と明言したあとでも、これを一般的な論拠にできる（移行期に際する特例ではなく）と考えていることが信じられないのです。 -- [[K]] SIZE(10){2004-05-31 (月) 22:37:28}
-FDユーザに配慮することが保守的とのことですが、まあそれは一理あるかもしれません。で、お聞きしたいのですが、今のようにFDユーザにも最大限配慮しつづけることでどういう損があるのか具体的に教えてください。せいぜい名無しさんのような人に嫌われるだけじゃないんですか？一方で、FDユーザなんて場合によっては無視していいんだという態度（しかも圧縮してもどうにもならないという正当な理由ではなく、ただ圧縮すればいいだけのことなのにそれをしないというふざけた態度）をかばうことで何が得られるんですか？・・・それは結局HDDが100GBないと満足には使えないような、そしてAT互換機の特定の機種でしか動かないような、そんな結果しかないように思えますが。僕はFDユーザに配慮しつづけることや、TOWNS版などのリリースを続ける事で得られるものを明確かつ具体的に指摘できますが、名無しさんにそれはできますか？ -- [[K]] SIZE(10){2004-05-31 (月) 23:00:21}

-[[room/000f]]へ続く

• room/000e のバックアップ一覧^[6]
• room/000e のバックアップソース(No. All)
  • 1: 2004-06-03 (木) 05:07:34^[7]
  • 2: 2009-11-17 (火) 12:07:23
  • 現: 2024-01-08 (月) 12:59:02^[8] k-tan^[9]