ページへ戻る

− Links

 印刷 

room​/000 のバックアップ差分(No.11) :: OSASK計画

osaskwiki:room/000 のバックアップ差分(No.11)

« Prev[4]  Next »[5]
10: 2004-06-16 (水) 22:15:29 ソース[6] 11: 2004-06-22 (火) 22:10:16 ソース[7]
Line 60: Line 60:
-http://students.fhs-hagenberg.ac.at/se/se00001/Projects_LZMA_.htmlなにこれ -- [[名無しさん]] SIZE(10){2004-06-10 (木) 16:34:53} -http://students.fhs-hagenberg.ac.at/se/se00001/Projects_LZMA_.htmlなにこれ -- [[名無しさん]] SIZE(10){2004-06-10 (木) 16:34:53}
-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}
 +-たくさんの論点がありますが、まずは簡単なものだけを。圧縮してもろくに小さくならないものについては、僕も圧縮するべきではないと思います(というか小さくならない時点で、既に圧縮ではなくなって、ただのエンコードになっている)。ファイルサイズではなくて消費クラスタの観点をということについては、OSASKのファイルシステムでカバーする予定(複数の小さいファイルを1つのクラスタにまとめる)ですので、圧縮の是非の問題からとりあえず切り離します。大きいファイルを開くときに前からアクセスしなければいけないという点については、それは他の圧縮形式言えることであって、ランダムアクセス対策を施しているtek1~tek3には無縁です(内部がマルチブロック化されており、先頭にブロック先頭位置を高速に割り出すための階層構造のインデックスまでついています)。このおかげでランダムアクセス性能も問題ないでしょう。残りの論点はあとで。 -- [[K]] SIZE(10){2004-06-22 (火) 22:10:16}
#comment #comment
« Prev[4]  Next »[5]