【gzip】圧縮対決【bzip2】
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
2008/06/28(土) 12:02:14ID:yqbrlAKF0002login:Penguin
2008/06/28(土) 12:21:18ID:8VBYMaXo0003login:Penguin
2008/06/28(土) 13:28:22ID:eSYX5VPrhttp://www.quicklz.com/
quicklzより良さげなのにクローズドソースのlzturbo
http://consultant-berater.de/lzturbo/
圧縮率かなり高いけど相当遅いPAQ
http://cs.fit.edu/~mmahoney/compression/
0004login:Penguin
2008/06/28(土) 13:37:22ID:eSYX5VPrhttp://www.haskell.org/bz/
0005login:Penguin
2008/06/28(土) 23:47:30ID:3oAVFN3K0006login:Penguin
2008/06/29(日) 01:55:30ID:jKsDLLyzPCの性能は十分あるんだし
0007login:Penguin
2008/06/29(日) 04:36:43ID:LnGyI9MO誰かに渡すファイルはgzとかbz2にしてる。
0008login:Penguin
2008/06/29(日) 21:45:30ID:yYDpk6Otttp://www.maximumcompression.com/data/summary_mf3.php
OpenVPNで使ってるLZOしか知らなかったけど、THOR, QuickLZ, LZTurbo, LZO って同じような中身なのかな?
GPL: QuickLZ、LZO クローズ: LZTurboなのか?
LGPLか修正BSDが欲しいと思ってたら、http://www.quicklz.com/ ここで比較してる lzf (LibLZF)ってのが修正BSDだった。
改善しつつ広まって欲しいな。
0009login:Penguin
2008/06/29(日) 21:58:29ID:yYDpk6OtDeveloperWorks Japan > Linux > FUSEによる独自ファイルシステムの開発
ttp://www.ibm.com/developerworks/jp/linux/library/l-fuse/index.html
ここから辿ってファイルシステム一覧を見てたら、圧縮ファイルシステム一覧があった。
読み書きできて、安定してるやつは他にあるのかな。
ttp://fuse.sourceforge.net/wiki/index.php/FileSystems
・CompressedFileSystems - accessing files in a compressed image (gz, zlib, LiveCDs, etc.)
- compFUSEd
- FuseCompress
- LZOlayer_fs - Transparent compression filesystem
・ArchiveFileSystems - accessing files inside archives (tar, cpio, zip, etc.)
- unpackfs
- avfs - mount archive and compressed files, and access remote files
0010login:Penguin
2008/06/29(日) 22:11:03ID:W919QOx7中身違うと思う。LGPLなLZOはffmpegのlibavutilにあった気ガス。あと7zにもあったような。
0011login:Penguin
2008/06/30(月) 08:41:57ID:KlvCVv7N0012login:Penguin
2008/06/30(月) 12:47:59ID:t5z30P/R(12:33:25)hoge~/$ time tar cf - emacs-21.4 | gzip -1 > emacs-21.4.tar.gz
real 0m35.635s
user 0m32.900s
sys 0m4.500s
(12:34:44)hoge~/$ time tar cf - emacs-21.4 | bzip2 -z -1 > emacs-21.4.tar.bz2
real 2m19.127s
user 2m17.470s
sys 0m3.970s
(12:37:28)hoge~/$ time tar cf - emacs-21.4 | lzma -z -1 > emacs-21.4.tar.lzma
real 2m22.816s
user 2m20.920s
sys 0m5.320s
(12:40:18)hoge~/$ ls -l emacs-21.4.tar.*
-rw-r--r-- 1 *** users 21538172 6月 30 12:37 emacs-21.4.tar.bz2
-rw-r--r-- 1 *** users 28265569 6月 30 12:34 emacs-21.4.tar.gz
-rw-r--r-- 1 *** users 22247714 6月 30 12:40 emacs-21.4.tar.lzma
0013login:Penguin
2008/06/30(月) 15:20:23ID:Pt7FfeQa$ time gzip -9 emacs-21.4a.tar
real 0m23.369s
user 0m18.659s
sys 0m2.363s
$ time bzip2 -9 emacs-21.4a.tar
real 1m9.675s
user 1m3.954s
sys 0m1.605s
$ time lzma -9 emacs-21.4a.tar
real 7m20.250s
user 6m41.498s
sys 0m3.793s
$ ls -lSr emacs-21.4a.tar*
-rw-rw-r-- 1 xxxx xxxx 12644142 Jun 30 15:00 emacs-21.4a.tar.lzma
-rw-rw-r-- 1 xxxx xxxx 16031034 Jun 30 14:59 emacs-21.4a.tar.bz2
-rw-rw-r-- 1 xxxx xxxx 20403499 Jun 30 14:58 emacs-21.4a.tar.gz
$
lzma -9の方が小さいよ。
死ぬほど遅いけど。
0014login:Penguin
2008/06/30(月) 15:51:13ID:MmUObtGR001512
2008/06/30(月) 16:24:20ID:t5z30P/R-9 使いたいのはやまやまなんだが、手元のマシンがP2-400なんだw
lzmaの売りが圧縮率と思うが、時間がかかりすぎるぞ・・・・。
0016login:Penguin
2008/07/01(火) 14:49:11ID:gSA6bD4uどれだけ圧縮が遅くてもいい。
どれだけ圧縮にメモリを使ってもいい。
展開が激烈には遅くなく(たとえばgzipの数倍以内とか)で、
なおかつ、メモリ使用量がそれなり(たとえば、256MB以内とか)。
この条件でベストのものって何?
何がしたいかというと、
ディストリのインストールDVDを一枚のCDに圧縮したいわけです。
gzipなら4.7GBになるところを、無理やり700MB以内にできないか?
圧縮は、どんなに遅くてもいい。
たとえ、Quad Core で3ヶ月ぐらい掛かっても、
圧縮する価値はあると思う。
DVDなんてダウンロードできないよ!!!。
0017login:Penguin
2008/07/01(火) 15:12:55ID:SCsR7P7sヒント: シャノンの理論
0018login:Penguin
2008/07/01(火) 16:02:48ID:sogkEXkCシャノンの定理は対象の情報源以外から情報を得られないから
成り立っているように見えるんだよ。
0019login:Penguin
2008/07/01(火) 20:24:40ID:/jkPTzMU0020login:Penguin
2008/07/01(火) 21:06:14ID:sCmwJD84解凍は bzip2 より lzma のほうが速いよ。
圧縮時間も bzip2 並でよければ変わらんし。
・ Average compression ratio of LZMA is about 30% better than that of gzip, and 15% better than that of bzip2.
・ Decompression speed is only little slower than that of gzip, being two to five times faster than bzip2.
・ In fast mode, compresses faster than bzip2 with a comparable compression ratio.
0021login:Penguin
2008/07/01(火) 23:25:16ID:21AKert0釣りか?
それなら圧縮してる時間をダウンロードにあてれば解決するだろ。
0022login:Penguin
2008/07/01(火) 23:44:12ID:5YakOucXPerformancePage - VFS performance comparison
http://code.google.com/p/fuse-zip/wiki/PerformancePage
他の圧縮もlibzip使って比較してるのか分らないけど、 fuse-zipとavfs-fuseがunpackfsより軽いみたいだ。
それぞれ
CompressFileSystems(圧縮ファイルシステム)は、1ファイルごとにgzなど圧縮ファイルと対応させて管理されて、
ArchveFileSystems(書庫ファイルシステム)zip書庫などをマウントポイントからディレクトリとして使える物みたい
0023login:Penguin
2008/07/02(水) 00:13:11ID:8emwfkfD性能測定したらこんな感じになった
■ファイルサイズ(MyISAMのデータファイル)
file 1,127,594,052
(lzo) /tmp/lzo/file 294,154,987 (26.1%)
(gz) /tmp/gz/file 183,510,660 (16.3%)
(bz2) /tmp/bz2/file 未測定
■同一HDD: cp file file2
real 1m5.670s, user 0m0.187s, sys 0m6.112s
動作時のcpu利用率 10% (cp 10%)
■同一HDD(lzo): cp file /mnt/lzo/file
real 0m44.970s, user 0m0.310s, sys 0m4.768s
動作時のcpu利用率 50% (cp 10%, fusecompress 40%)
■同一HDD(gzip): cp file /mnt/gz/file
real 2m8.807s, user 0m0.331s, sys 0m4.469s
動作時のcpu利用率 100% (cp 4%, fusecompress 95%)
■同一HDD(bz2): cp file /mnt/bz2/file
動作時のcpu利用率 100% (cp 2%, fusecompress 98%)
■ヌル出力: cat file > /dev/null
real 0m21.486s, user 0m0.121s, sys 0m1.477s
cat 6%
■ヌル出力(lzo): cat /mnt/lzo/file > /dev/null
real 0m11.340s, user 0m0.211s, sys 0m1.406s
動作時のcpu利用率 60% (cat 10%, fusecompress 50%)
■ヌル出力(gzip): cat /mnt/gz/file > /dev/null
real 0m19.671s, user 0m0.152s, sys 0m1.153s
動作時のcpu利用率 100% (cat 6%, fusecompress 94%)
■ヌル出力(bz2): cat /mnt/bz2/file > /dev/null
動作時のcpu利用率 100% (cat 1%, fusecompress 99%)
0024login:Penguin
2008/07/02(水) 00:14:31ID:8emwfkfDreal 0m43.200s, user 0m8.009s, sys 0m2.727s
lzop 24%
0025login:Penguin
2008/07/04(金) 00:14:59ID:0OG1epWXこのDB+WEBの簡潔データ構造の記事みて、いろいろ読んでたら
なんか世の中変わってた。
圧縮データ構造とその最新動向
ttp://www-or.amp.i.kyoto-u.ac.jp/ramp2006/program.html
透過的データ圧縮
ttp://keisan-genkai.lab2.kuis.kyoto-u.ac.jp/reports/2005/zentai_2/
ttp://tcslab.csce.kyushu-u.ac.jp/~sada/lectures/algoeng2006.html
WAN/LANやDB、ファイルシステム、RAM、Cache、内部通信にもこういうものを使う研究もあるみたいだし、
結構わくわくしてきたぞ。
0026login:Penguin
2008/07/07(月) 13:53:12ID:DoQMtzeMreal 0m31.523s
user 0m28.823s
sys 0m1.306s
$ ls -l emacs-21.4a.tar*
-rw-rw-r-- 1 xxxx xxxx 14472688 Jul 7 13:49 emacs-21.4a.tar.rz
$
>>13と同じ環境。
合わせて評価すると速さと圧縮率のバランスがいいかもしれない。
0027login:Penguin
2008/07/17(木) 03:07:45ID:A+BRuM6Xlzmaの4.999α版コンパイルしてみたけど、マルチスレッドにならないし。
7zファイル形式がパイプで使えない原因らしいから、
p7zipがlzmaファイル形式をサポートして、パイプで使えるようになったら良いな〜
0028login:Penguin
2008/07/19(土) 00:41:00ID:ai76BlOhこれいいな〜と思ったら標準入出力に未対応か・・・
0029login:Penguin
2008/08/16(土) 00:02:13ID:GvqWjEmChttp://zlibc.linux.lu/
0030login:Penguin
2009/06/07(日) 19:25:33ID:eb8s04gy0031login:Penguin
2009/06/12(金) 18:42:18ID:WAZGDfixlbzip2みたいだぞ
A multi-threaded bzip2/bunzip2 filter
http://phptest11.atw.hu/
Parallel BZIP2 (PBZIP2)
http://compression.ca/pbzip2/
マルチコアCPUを活用したファイル圧縮
http://sourceforge.jp/magazine/08/02/15/0115238
pbzip2 vs bzip2
http://shrine-bell.seesaa.net/article/107520046.html
どっちも並列bzip2の実装。
最近bzip2との互換性が確保されたようなのでpbzip2を試してみた。
カーネルソースを圧縮展開してみたがこれはかなりいい。
LZMAも好きだが圧縮率を求める時代の流れはそろそろ打ち止めだろう。
バランスの面ではpbzip2の方がかなりいい印象。Linuxではpbzip2がすぐに主流になるはず。
0032login:Penguin
2009/06/13(土) 03:03:18ID:ejf5oGI/0033login:Penguin
2009/06/13(土) 08:01:41ID:0tnCgkV1pbzip2はよさげだね
>>32
tar.gzは互換性のために生き続ける。
lzmaも場合によってはメリットも大きいはずなのに普及してはきてるけど
あまり表に出てこないのはなんでだろう。
0034login:Penguin
2009/06/13(土) 09:53:04ID:vy3ykwBi配布に使われないんだから、ユーザもインストールする動機がない。
...の環から、なかなか抜け出せないことが多いだろうな。
ディスクもメモリもネットワークも豪奢な当世、圧縮率に拘るのも少数派だろうし。
あ、lzmaも、ぽちぽち使われているよ。
Linuxカーネル2.6.30とか。
0035login:Penguin
2009/06/13(土) 10:03:53ID:0tnCgkV1それは書こうかと思ったけどまだ新しすぎるよな・・って思って普及してきてるに止めた。
7zipとしてWindowsでかなり有名なんじゃないかと。
elinksか何かがgzip,deflate以外にbzip2,lzmaが使えたと思うが
ネットでは対応サーバーが皆無だわな
0036login:Penguin
2009/06/13(土) 14:34:22ID:QBNkjNcgdpkgの依存にlzmaが入っていたりもするし、そろそろlzmaが入ってない環境っていうのは珍しいくらいなのかも。
0037login:Penguin
2009/06/13(土) 14:54:01ID:pu4qsGER〜1GhzのCPUでは結構しんどい仕事だから標準をどうするかは難しそう
0038login:Penguin
2009/06/13(土) 17:07:22ID:anrCvK7ulzmaは解凍にメモリを多く使うんじゃなかたっけか
それで使いにくいんじゃないかなぁ
0039login:Penguin
2009/06/13(土) 22:56:07ID:5NJGz6mZそのうち元のファイルが復元できると言い張る奴がいたな
0040login:Penguin
2009/06/14(日) 00:35:26ID:d8gKzCk8少なくとも file-5.00 は。
0041login:Penguin
2009/06/14(日) 20:53:33ID:Mb+BA8Wbこんなのがあった。
p7zipでWindows用の自己解凍アーカイブを作成
ttp://www.commandlinefu.com/commands/view/1402/create-a-self-extracting-archive-for-win32-using-7-zip
cat /path/to/7z.sfx /path/to/archive > archive.exe
0042login:Penguin
2009/06/22(月) 15:09:23ID:nPX8bYX00043login:Penguin
2009/10/16(金) 21:16:27ID:zxtkfFrHへぇー。
でも.exeってウィルス疑惑で忌避される傾向にある気がする。
0044login:Penguin
2009/11/01(日) 16:47:53ID:jDaGKrnO解凍したzip中のexeは普通に開く不思議
0045login:Penguin
2010/05/22(土) 18:22:29ID:RMv2w9HGlzoイラネ。
ホントはbzip2系が画像圧縮で有利な技術だから使いたいんだけど、
展開が遅いのがねー。
0046login:Penguin
2010/05/23(日) 10:18:27ID:JQh/i7Pujava中心でもいろいろ議論あって面白いなあ
0047login:Penguin
2010/05/26(水) 11:51:58ID:zj479Z71lzmaになってきたな
復元は圧縮より速いんだっけ
0048login:Penguin
2010/05/27(木) 02:45:52ID:BLNLE82C0049login:Penguin
2010/05/27(木) 11:08:09ID:tOxkqDtJgzipと違って展開プログラムがアセンブラ化されてないからねぇ。
実装としては枯れてるんだからあとは移植するだけなんだが。
0050login:Penguin
2010/06/05(土) 23:40:55ID:W7vixxeb巨大なswitch文がある関数の中と外を膨大な回数行き来するような構造になってた。
VS2010で最大限の最適化をかけてasmを吐き出してみたけどほとんど最適化されてない。
これを逐語的にハンドアセンブルするのはかなり骨だろうなー。
0051login:Penguin
2010/07/23(金) 08:23:17ID:+OeBNNzx0052login:Penguin
2011/10/27(木) 19:56:40.98ID:TsQJCJm5古いマシンだとcpu もメモリも辛いけど
■ このスレッドは過去ログ倉庫に格納されています