4: 2004-10-20 (水) 02:16:49  |
5: 2004-10-21 (木) 15:35:21 |
| | -もともとsarやtekというフォーマットを作ることになったのは、[[K]]がOSASKやKHBIOSで標準的にサポートする圧縮形式を決めるにあたって、既存のアーカイブ形式に強い不満を感じたからです。これらは圧縮率が良くなかったり、どんなにプログラムで工夫しても展開を速くできないようになっていたりしました（これは根底の圧縮アルゴリズムに原因があるのでどうしようもない）。 | | -もともとsarやtekというフォーマットを作ることになったのは、[[K]]がOSASKやKHBIOSで標準的にサポートする圧縮形式を決めるにあたって、既存のアーカイブ形式に強い不満を感じたからです。これらは圧縮率が良くなかったり、どんなにプログラムで工夫しても展開を速くできないようになっていたりしました（これは根底の圧縮アルゴリズムに原因があるのでどうしようもない）。 |
| | -常識的な議論として、圧縮率が高い形式は展開時間が長くかかります。逆に展開時間が短いものは、圧縮率があまりよくありません。それは圧縮率を上げるために高度なアルゴリズムを使っているからなので、傾向としては当然のことです。 | | -常識的な議論として、圧縮率が高い形式は展開時間が長くかかります。逆に展開時間が短いものは、圧縮率があまりよくありません。それは圧縮率を上げるために高度なアルゴリズムを使っているからなので、傾向としては当然のことです。 |
| - | -しかし同じくらいの圧縮率なのに展開が他のものよりも速い形式というのがあります。そういう形式こそ、真に価値ある形式だと[[K]]は考えます。もちろん展開速度というものは展開プログラムをうまく作るかどうかで大きく左右されるものですが、どんなにうまく作っても圧縮形式（圧縮アルゴリズム）による限界があるのです。圧縮率が同程度なら、その限界速度が速い形式こそ、圧縮形式としては良い形式ではないでしょうか。 | + | -しかし同じくらいの圧縮率なのに展開が他のものよりも速い形式というのがあります。もしくは同じくらいの展開速度なのに圧縮率が他よりも良い形式です。そういう形式こそ、真に価値ある形式だと[[K]]は考えます。もちろん展開速度というものは展開プログラムをうまく作るかどうかで大きく左右されるものですが、どんなにうまく作っても圧縮形式（圧縮アルゴリズム）による限界があるのです。圧縮率が同程度なら、その限界速度が速い形式こそ、圧縮形式としては良い形式ではないでしょうか。 |
| | + | -他の観点もあります。それは展開作業のためにたくさんのメモリを要しないことです。実用的な展開速度のためには大量の作業用メモリが必要、という形式がありますが、そういうものはメモリが少ない環境での展開が絶望的になります（メモリが少ない環境というのは、たいてい利用可能なCPUの処理能力もそれほど大きくはない）。自分だけが使う場合は問題がないのですが、不特定多数の人にファイルを渡す場合や、将来携帯用端末で使うときなどにはこれが問題になり、結果的に負の資産になる可能性もあります。 |
| | -もちろん、多少のエラーを自動的に修復できることや、暗号化機能を持ったもの、アーカイブファイル分割機能の有無、OSでの標準サポート、それよりなにより使いやすいツール群が揃っていることなどこそ、使いやすいアーカイブ形式に求められる条件だという観点もあります。それはそのとおりです。エラー修復や暗号化や分割機能は、sar形式でも当初より対応を検討していて、かつそのための拡張に速やかに対応できるように準備をしてあります。OSでのサポートやツールの充実は、ユーザが増えれば自然に充実していくことでしょう。 | | -もちろん、多少のエラーを自動的に修復できることや、暗号化機能を持ったもの、アーカイブファイル分割機能の有無、OSでの標準サポート、それよりなにより使いやすいツール群が揃っていることなどこそ、使いやすいアーカイブ形式に求められる条件だという観点もあります。それはそのとおりです。エラー修復や暗号化や分割機能は、sar形式でも当初より対応を検討していて、かつそのための拡張に速やかに対応できるように準備をしてあります。OSでのサポートやツールの充実は、ユーザが増えれば自然に充実していくことでしょう。 |
| | -現在では実に多くのアーカイブ形式が開発されています。しかし圧縮率の割には展開速度が遅いような、そんな形式でCD-RやDVDにバックアップとして残していくべきでしょうか。今までのぶんはしょうがないと思いますが、これからはもっと積極的にどの形式が良いかを考えて、もし使いにくいという問題があれば、使いやすくなるようにツールを充実させていくべきだと[[K]]は思います。その意思の反映として、sar形式での配布を行っているというわけです。 | | -現在では実に多くのアーカイブ形式が開発されています。しかし圧縮率の割には展開速度が遅いような、そんな形式でCD-RやDVDにバックアップとして残していくべきでしょうか。今までのぶんはしょうがないと思いますが、これからはもっと積極的にどの形式が良いかを考えて、もし使いにくいという問題があれば、使いやすくなるようにツールを充実させていくべきだと[[K]]は思います。その意思の反映として、sar形式での配布を行っているというわけです。 |
| | |sartol0g|142.3|140.8|134.7|131.7|127.0|121.5|''118.9''|100.0| | | |sartol0g|142.3|140.8|134.7|131.7|127.0|121.5|''118.9''|100.0| |
| | |make46|261.0|246.1|236.9|179.9|148.0|143.7|''141.6''|100.0| | | |make46|261.0|246.1|236.9|179.9|148.0|143.7|''141.6''|100.0| |
| | + | |展開作業域|8KB未満|8KB未満|8KB未満|2.3MB|不明|28KB|''32KB''|120MB| |
| | --sar形式ではtek5圧縮を使っています。 | | --sar形式ではtek5圧縮を使っています。 |
| | --lzhはlh7形式です。 | | --lzhはlh7形式です。 |
| | --7zはデフォルトのLZMA形式をそのまま使っています。 | | --7zはデフォルトのLZMA形式をそのまま使っています。 |
| | --paqはPAQAR v1.3でオプション-5を使っています（今はもっとバージョンが進んでいるようです）。 | | --paqはPAQAR v1.3でオプション-5を使っています（今はもっとバージョンが進んでいるようです）。 |
| - | --PAQAR以外は展開が速すぎて時間を測れませんでした。 | + | //--PAQAR以外は展開が速すぎて時間を測れませんでした。 |
| | //--ブロックソート系（bz2やdgc）は圧縮対象によって得手不得手がかなりあるのですが、どうやらこれらの圧縮対象は不得手のようです。 | | //--ブロックソート系（bz2やdgc）は圧縮対象によって得手不得手がかなりあるのですが、どうやらこれらの圧縮対象は不得手のようです。 |
| | + | --展開作業域にはLZのスライド辞書用のための領域は、展開結果と兼ねられるのでカウントしていません（出力バッファを上回る遠方の辞書参照をディスクアクセスなどで参照しても、極端な速度低下がないと思われるため）。 |
| | + | --lzh, zip, gzの展開作業域は8KB未満としていますが、詳細はよく分かりません（静的ハフマンのためにどのくらいが必要なのか詳細不明）。たぶんもっと小さいです。 |
| | + | //--bz2のブロックサイズから作業域の大きさを割り出す方法がわかりません。900KBを4倍すればいいのかな？...分かりました：100KB + (ブロックサイズ x 2.5) |
| | + | --dgcの展開作業域は不明ですが、おそらくブロックソート系なので、bz2と同程度はありそうな気がします。 |
| | | | |
| | * こめんと欄 | | * こめんと欄 |
| | #comment | | #comment |
