13: 2004-06-25 (金) 21:51:57  |
14: 2004-06-27 (日) 22:58:11 |
| | -GCAのページ見たら展開速度が速いみたいなことが強調してあったので、ほうブロックソートでも速いやつがあるのか、とさっそくosaskgoで実験してみました。・・・なんだー、bzip2よりもさらにおそいじゃん・・・。 -- [[K]] SIZE(10){2004-06-16 (水) 20:40:55} | | -GCAのページ見たら展開速度が速いみたいなことが強調してあったので、ほうブロックソートでも速いやつがあるのか、とさっそくosaskgoで実験してみました。・・・なんだー、bzip2よりもさらにおそいじゃん・・・。 -- [[K]] SIZE(10){2004-06-16 (水) 20:40:55} |
| | -すみません。改めてこちらに書きます。せんえつながら意見とか少し思った事です。・極々小さなファイルは逆に大きくなる。既にエントロピーの高いデータ(jpeg等)に圧縮を行うのは無駄⇒無圧縮形式もあるべき。・ファイルサイズだけでなくクラスタギャップも重要視すると完璧(FAT等も考慮)⇒小さいファイルはアーカイブも行う・大きなファイルの途中を開く時先頭セクタから順次見る必要が出る⇒大きなデータは複数チャンクに分けファイル先頭に索引つける・キャッシュファイルも圧縮？・ランダムアクセスは辛くないかな？・DMA転送のみで終わる無圧縮に比べ複数バスやCPUを使うので優しくない？⇔CPU、メモリとHDD容量のトレードオフ -- ''Chihaya'' SIZE(10){2004-06-22 (火) 21:12:30} | | -すみません。改めてこちらに書きます。せんえつながら意見とか少し思った事です。・極々小さなファイルは逆に大きくなる。既にエントロピーの高いデータ(jpeg等)に圧縮を行うのは無駄⇒無圧縮形式もあるべき。・ファイルサイズだけでなくクラスタギャップも重要視すると完璧(FAT等も考慮)⇒小さいファイルはアーカイブも行う・大きなファイルの途中を開く時先頭セクタから順次見る必要が出る⇒大きなデータは複数チャンクに分けファイル先頭に索引つける・キャッシュファイルも圧縮？・ランダムアクセスは辛くないかな？・DMA転送のみで終わる無圧縮に比べ複数バスやCPUを使うので優しくない？⇔CPU、メモリとHDD容量のトレードオフ -- ''Chihaya'' SIZE(10){2004-06-22 (火) 21:12:30} |
| - | -たくさんの論点がありますが、まずは簡単なものだけを。圧縮してもろくに小さくならないものについては、僕も圧縮するべきではないと思います（というか小さくならない時点で、既に圧縮ではなくなって、ただのエンコードになっている）。ファイルサイズではなくて消費クラスタの観点をということについては、OSASKのファイルシステムでカバーする予定（複数の小さいファイルを1つのクラスタにまとめる）ですので、圧縮の是非の問題からとりあえず切り離します。大きいファイルを開くときに前からアクセスしなければいけないという点については、それは他の圧縮形式言えることであって、ランダムアクセス対策を施しているtek1～tek3には無縁です（内部がマルチブロック化されており、先頭にブロック先頭位置を高速に割り出すための階層構造のインデックスまでついています）。このおかげでランダムアクセス性能も問題ないでしょう。残りの論点はあとで。 -- [[K]] SIZE(10){2004-06-22 (火) 22:10:16} | + | -たくさんの論点がありますが、まずは簡単なものだけを。圧縮してもろくに小さくならないものについては、僕も圧縮するべきではないと思います（というか小さくならない時点で、既に圧縮ではなくなって、ただのエンコードになっている）。ファイルサイズではなくて消費クラスタの観点をということについては、OSASKのファイルシステムでカバーする予定（複数の小さいファイルを1つのクラスタにまとめる）ですので、圧縮の是非の問題からとりあえず切り離します。大きいファイルを開くときに前からアクセスしなければいけないという点については、それは他の圧縮形式に言えることであって、ランダムアクセス対策を施しているtek1～tek3には無縁です（内部がマルチブロック化されており、先頭にブロック先頭位置を高速に割り出すための階層構造のインデックスまでついています）。このおかげでランダムアクセス性能も問題ないでしょう。残りの論点はあとで。 -- [[K]] SIZE(10){2004-06-22 (火) 22:10:16} |
| | -クラスタギャップに関してはファイルシステムでの対応は知ってますし圧縮の是非とは多少離れてるのも分かってます。ですがFAT等にも適用出来れば鬼に金棒かなと。そしてOSASKの遅延書き込み機構を考えると実際のライトバック頻度はかなり軽減されると思うので管理領域変更やセクタ移動、フラグメンテーション等のペナルティも少ない気がするのでカーネルレベルでのアーカイブ機構も検討してないのならご一考と思った次第です。本来ならデータ圧縮はHDDのコントローラでやるのが常識。わたしも圧縮するのは至極当然だと思いますよ。 -- ''Chihaya'' SIZE(10){2004-06-23 (水) 16:36:26} | | -クラスタギャップに関してはファイルシステムでの対応は知ってますし圧縮の是非とは多少離れてるのも分かってます。ですがFAT等にも適用出来れば鬼に金棒かなと。そしてOSASKの遅延書き込み機構を考えると実際のライトバック頻度はかなり軽減されると思うので管理領域変更やセクタ移動、フラグメンテーション等のペナルティも少ない気がするのでカーネルレベルでのアーカイブ機構も検討してないのならご一考と思った次第です。本来ならデータ圧縮はHDDのコントローラでやるのが常識。わたしも圧縮するのは至極当然だと思いますよ。 -- ''Chihaya'' SIZE(10){2004-06-23 (水) 16:36:26} |
| | -lzopはソースコード公開してますよ。 http://www.lzop.org/download/lzop-1.01.tar.gz -- ''laira'' SIZE(10){2004-06-25 (金) 21:51:57} | | -lzopはソースコード公開してますよ。 http://www.lzop.org/download/lzop-1.01.tar.gz -- ''laira'' SIZE(10){2004-06-25 (金) 21:51:57} |
| | + | -画像形式は別に圧縮率が一番の売りでは無いと思います。例えばPNGにはαチャンネルやγ補正といった特徴がありますし、プログレッシブにも対応しなきゃいけないし、アニメーションへの応用(MNG)も当初から考えられていたので展開が早くないといけないし。 -- ''laira'' SIZE(10){2004-06-27 (日) 21:59:16} |
| | + | -おお、気がつけばたくさんの書き込みが。lzopのソースは既にダウンロードしています。ざっと見た範囲では、tek2を超えるような技術はなさそうでしたので、とりあえずそのままほったらかしています。 -- [[K]] SIZE(10){2004-06-27 (日) 22:20:00} |
| | + | -画像形式についてですが、僕の考えはこうなのです。画像専用形式だとするからには、画像特有の性質を利用して圧縮形式を決めることができ、それが展開速度や圧縮率で有利になることにつなげられると思うのですが、実際はPIを除けばそのような効果は期待できないようなのです。結局pngも内部に汎用圧縮形式を採用しただけで、イマイチの感が否めません。・・・で、結局そういう画像圧縮形式がそういうものであるならば、無圧縮形式にtekを適用したほうが圧縮率がよくなったり展開速度が上がったりするかもしれないわけです。・・・もう一つの論点であるアルファチャンネルやガンマ補正などはもちろん重要なことですが、それはここで話題になっている圧縮とは特に関係なく、むしろ無圧縮でそのような情報をもっている形式を最初に考えてそれを適当な汎用形式で圧縮すればいいだけのことです。僕が言っているのは、PNGの全てがダメだということではなく、PNGの圧縮周りがダメだということだけです。 -- [[K]] SIZE(10){2004-06-27 (日) 22:38:13} |
| | + | -Chihayaさんへのレス：まず前に残していた問題の、展開時にCPUに多少の負荷がかかるという点ですが、それはそのとおりでしょう。それがよろしくない場合も当然ありますが、一般的に期待されるケースとしてはとりあえず公開するようなものについては圧縮しておくという基本方針で問題なかろうと思います。実際の使用時に無圧縮にしておくかどうかはユーザの自由ということで。 -- [[K]] SIZE(10){2004-06-27 (日) 22:44:11} |
| | + | -で、順序を入れ替えて「本来なら圧縮はHDDのコントローラでやるべき」という点についてです。僕は、これは条件付で賛成です。どういう条件かというと、圧縮・展開を伴わない読み書きもサポートされるなら、ということです。・・・ああでも、やっぱりHDDのコントローラじゃなくて、チップセットのオマケ機能とかのほうがありがたいですねえ。これならHDD以外のデバイスにも使えるわけですし。・・・もしChihayaさんの想像している「HDDのコントローラによる圧縮展開」が、OSから感知されないような内部で勝手にごにょごにょ形式であるなら、僕は賛成ではありません。それは結局ファイルシステムが圧縮展開をサポートする状況をハードウェアレベルでやったようなものであり、同じ欠点を持つからです。 -- [[K]] SIZE(10){2004-06-27 (日) 22:50:57} |
| | + | -クラスタギャップの問題については、僕はこう考えます。まず、Chihayaさんも結局根本的な解決はファイルシステムを改善することであって、アーカイブ形式によるフォローは次善の策でしかない、という点で納得していただいていると僕が思い込んでいるので、そこが違ったら指摘してください。・・・で、OSASKやKHBIOS的な発想では、たとえばFATファイルシステム内のディスクイメージファイルをパーティションの一つとして解釈するので（註：FAT以外のファイルシステムであってももちろんかまわない）、FATの中の一部にOSASKのファイルシステムをいれてしまうことはできます。つまり、新規にアーカイブ形式を考えるまでもなく、ディスクイメージがそのままアーカイブ形式なのです。これであれこれとフォーマットを乱発しないで済みます。OSASKではないOSではこのディスクイメージファイルをOSASKの規定するフォーマットで解釈してやれば、それでChihayaさんの目的は達せられるのではないでしょうか？ -- [[K]] SIZE(10){2004-06-27 (日) 22:58:11} |
| | | | |
| | #comment | | #comment |
