【gzip】圧縮対決【bzip2】
■ このスレッドは過去ログ倉庫に格納されています
zlibより圧縮率悪いけどかなり早いQuickLZ http://www.quicklz.com/ quicklzより良さげなのにクローズドソースのlzturbo http://consultant-berater.de/lzturbo/ 圧縮率かなり高いけど相当遅いPAQ http://cs.fit.edu/ ~mmahoney/compression/ 最近は細かいこと考えずにlzmaばかりだな・・・ PCの性能は十分あるんだし 自分しか使わないファイルはlzma(.tar.lzmaとか)、 誰かに渡すファイルはgzとかbz2にしてる。 Summary of the multiple file compression benchmark tests ttp://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だった。 改善しつつ広まって欲しいな。 NTFSの圧縮ファイルシステムみたいなLZOlayer_fsってのを使ってる人がいるので、 DeveloperWorks 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 >>8 中身違うと思う。LGPLなLZOはffmpegのlibavutilにあった気ガス。あと7zにもあったような。 lzmaよりbzip2のほうが早いしよく潰れるんだが・・・ ^−^;;;; (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 -9使うだろ常考 $ 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の方が小さいよ。 死ぬほど遅いけど。 >>13 -9 使いたいのはやまやまなんだが、手元のマシンがP2-400なんだw lzmaの売りが圧縮率と思うが、時間がかかりすぎるぞ・・・・。 どれだけ圧縮が遅くてもいい。 どれだけ圧縮にメモリを使ってもいい。 展開が激烈には遅くなく(たとえばgzipの数倍以内とか)で、 なおかつ、メモリ使用量がそれなり(たとえば、256MB以内とか)。 この条件でベストのものって何? 何がしたいかというと、 ディストリのインストールDVDを一枚のCDに圧縮したいわけです。 gzipなら4.7GBになるところを、無理やり700MB以内にできないか? 圧縮は、どんなに遅くてもいい。 たとえ、Quad Core で3ヶ月ぐらい掛かっても、 圧縮する価値はあると思う。 DVDなんてダウンロードできないよ!!!。 >>17 シャノンの定理は対象の情報源以外から情報を得られないから 成り立っているように見えるんだよ。 圧縮が遅いのは放っておけばいいので問題ないんだが、展開が遅い奴は嫌だな。 >>16 解凍は 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. >>16 釣りか? それなら圧縮してる時間をダウンロードにあてれば解決するだろ。 >>9 の書庫ファイルシステムについてfuse-zipとの性能比較があった。 PerformancePage - VFS performance comparison http://code.google.com/p/fuse-zip/wiki/PerformancePage 他の圧縮もlibzip使って比較してるのか分らないけど、 fuse-zipとavfs-fuseがunpackfsより軽いみたいだ。 それぞれ CompressFileSystems(圧縮ファイルシステム)は、1ファイルごとにgzなど圧縮ファイルと対応させて管理されて、 ArchveFileSystems(書庫ファイルシステム)zip書庫などをマウントポイントからディレクトリとして使える物みたい FuseCompress - compressed filesystem http://www.miio.net/fusecompress 性能測定したらこんな感じになった ■ファイルサイズ(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%) ■lzop -o file.lzo file real 0m43.200s, user 0m8.009s, sys 0m2.727s lzop 24% ttp://gihyo.jp/magazine/wdpress/archive/2008/vol42 この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、内部通信にもこういうものを使う研究もあるみたいだし、 結構わくわくしてきたぞ。 $ time rzip -9 emacs-21.4a.tar real 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 と同じ環境。 合わせて評価すると速さと圧縮率のバランスがいいかもしれない。 lzmaはシングルスレッドだし、p7zipはパイプで使えないしで、 lzmaの4.999α版コンパイルしてみたけど、マルチスレッドにならないし。 7zファイル形式がパイプで使えない原因らしいから、 p7zipがlzmaファイル形式をサポートして、パイプで使えるようになったら良いな〜 >>26 これいいな〜と思ったら標準入出力に未対応か・・・ >>30 lbzip2みたいだぞ 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がすぐに主流になるはず。 ソースコードの配布じゃ、今のところ、tar.gz か tar.bz2 がほとんど >>31 pbzip2はよさげだね >>32 tar.gzは互換性のために生き続ける。 lzmaも場合によってはメリットも大きいはずなのに普及してはきてるけど あまり表に出てこないのはなんでだろう。 ユーザが入れてなさそうな圧縮形式なら、誰だって配布に使わない。 配布に使われないんだから、ユーザもインストールする動機がない。 ...の環から、なかなか抜け出せないことが多いだろうな。 ディスクもメモリもネットワークも豪奢な当世、圧縮率に拘るのも少数派だろうし。 あ、lzmaも、ぽちぽち使われているよ。 Linuxカーネル2.6.30とか。 >>34 それは書こうかと思ったけどまだ新しすぎるよな・・って思って普及してきてるに止めた。 7zipとしてWindowsでかなり有名なんじゃないかと。 elinksか何かがgzip,deflate以外にbzip2,lzmaが使えたと思うが ネットでは対応サーバーが皆無だわな いつの間にかgnu tarがlzmaに対応してるな。 dpkgの依存にlzmaが入っていたりもするし、そろそろlzmaが入ってない環境っていうのは珍しいくらいなのかも。 dpkgでほほぅ、と思ったがtarもか。 〜1GhzのCPUでは結構しんどい仕事だから標準をどうするかは難しそう >>33 lzmaは解凍にメモリを多く使うんじゃなかたっけか それで使いにくいんじゃないかなぁ ファイルサイズとMD5メモしておけば、 そのうち元のファイルが復元できると言い張る奴がいたな ファイルで思い出したが、 file(1)では、まだlzma形式を認識できないようだ 少なくとも file-5.00 は。 >>35 こんなのがあった。 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 >>41 へぇー。 でも.exeってウィルス疑惑で忌避される傾向にある気がする。 自己解凍exeは不安なのに 解凍したzip中のexeは普通に開く不思議 lzfかなりいいね。圧縮率に目をつぶれば。 lzoイラネ。 ホントはbzip2系が画像圧縮で有利な技術だから使いたいんだけど、 展開が遅いのがねー。 gnuのソースやlinuxの起動イメージも lzmaになってきたな 復元は圧縮より速いんだっけ bzip2 は展開が遅いから、さっさと lzma 系のどれかに置き換わって欲しいな。 >>48 gzipと違って展開プログラムがアセンブラ化されてないからねぇ。 実装としては枯れてるんだからあとは移植するだけなんだが。 追記。bzip2のデコード分のソースコードを追っかけてみたら、 巨大なswitch文がある関数の中と外を膨大な回数行き来するような構造になってた。 VS2010で最大限の最適化をかけてasmを吐き出してみたけどほとんど最適化されてない。 これを逐語的にハンドアセンブルするのはかなり骨だろうなー。 xz 試してみたけどいいね 古いマシンだとcpu もメモリも辛いけど >>52 圧縮率最高だよ 圧縮はかなり遅いが展開は速い $ lzma -h lzma 9.22 Copyright (C) 2006 Ville Koskinen Based on LZMA SDK 9.22 Copyright (C) 1999-2011 Igor Pavlov Usage: lzma [flags and input files in any order] -c --stdout output to standard output -d --decompress force decompression -z --compress force compression -k --keep keep (don't delete) input files -f --force force overwrite of output file and compress links -t --test test compressed file integrity -S .suf --suffix .suf use suffix .suf on compressed files -q --quiet suppress error messages -v --verbose be verbose -h --help print this message -L --license display the license information -V --version display version numbers of LZMA SDK and lzma -1 .. -2 fast compression -3 .. -9 good to excellent compression. -7 is the default. --fast alias for -1 --best alias for -9 (usually *not* what you want) Memory usage depends a lot on the chosen compression mode -1 .. -9. See the man page lzma(1) for details. 圧縮・伸張のマルチコア対応ってどうなっているんでしょうね >>56 xzなら-Tでスレッド数を指定できるな。 >>57 マジで? version教えてくださいな。 こちらは、 xz --version xz (XZ Utils) 5.1.0alpha liblzma 5.1.0alpha 誰か教えてちょうだい。 年も明けたことだし去年のログファイルでも圧縮するかと思って、 tar.xz に圧縮してみたんだけど、tar に引数を渡すのに ディレクトリ名を渡すのと、ファイル名を渡すので 圧縮後のファイルサイズが 3倍くらい違うんだけどなんで? $ apt-show-versions tar bzip2 gzip xz-utils bzip2/squeeze uptodate 1.0.5-6+squeeze1 gzip/squeeze uptodate 1.3.12-9 tar/squeeze uptodate 1.23-3 xz-utils/squeeze uptodate 5.0.0-2 # ログファイル数 212、logディレクトリ容量 703MB $ find log |wc -l 212 $ du -m log 703 log みたいな環境で、 tar cJf logs_with_dir.tar.xz log tar cJf logs_without_dir.tar.xz log/*.log ってそれぞれ実行。 すると、これ↓くらい違っちゃうんだよね。 ls -sh1 *.tar.xz 416K logs_without_dir.tar.xz 1.3M logs_with_dir.tar.xz $ xz -l logs_*_dir.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1 414.7 KiB 702.6 MiB 0.001 CRC64 logs_without_dir.tar.xz 1 1 1,246.3 KiB 702.6 MiB 0.002 CRC64 logs_with_dir.tar.xz ------------------------------------------------------------------------------- 2 2 1,660.9 KiB 1,405.3 MiB 0.001 CRC64 2 files んで、試しに 7z で圧縮するとこれくらい。 $ 7z a logs.7z log $ ls -sh1 *.7z 428K logs.7z なんで? ちなみに tar.gz や tar.bz2 で試すとほとんど差は出なかった。 何も困ってはいないんだけど不思議なので聞いてみた。 >>59 > tar cJf logs_with_dir.tar.xz log > tar cJf logs_without_dir.tar.xz log/*.log "*.log"以外のファイルやディレクトリがあるんじゃないのか。 前者はlogディレクトリ以下の全てのファイルとディレクトリを対象とするが、 後者はlogディレクトリ以下の"*.log"のみを対象としている。 >>61 おー、やっと反応があった。 > "*.log"以外のファイルやディレクトリがあるんじゃないのか。 それが logディレクトリ配下には "*.log"しか置いてないのよ。 $ tar tvJf logs_without_dir.tar.xz | wc -l 210 $ tar tvJf logs_with_dir.tar.xz | wc -l 211 1行違うのはディレクトリ自身の分ね。 それに >>60 の "xz -l" の結果を見ても、 Uncompressed のサイズはどっちも 702.6 MiB だし。 ためしに tar cf - log/*.log|xz > logs_without_dir_pipe.tar.xz してみるとどう? >>63 両方↓やってみた。 $ tar cf - log/*.log|xz > logs_without_dir_pipe.tar.xz $ tar cf - log|xz > logs_with_dir_pipe.tar.xz $ ls -sh1 logs_with*_dir_pipe.tar.xz 1.3M logs_with_dir_pipe.tar.xz 416K logs_without_dir_pipe.tar.xz $ xz -l logs_with*_dir_pipe.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1 1,246.3 KiB 702.6 MiB 0.002 CRC64 logs_with_dir_pipe.tar.xz 1 1 414.7 KiB 702.6 MiB 0.001 CRC64 logs_without_dir_pipe.tar.xz ------------------------------------------------------------------------------- 2 2 1,660.9 KiB 1,405.3 MiB 0.001 CRC64 2 files やっぱり、当たり前と言えば当たり前だけど、結果は同じ。 あんまり関係ないと思うけど、念の為ログの説明しとくと、 hyperestraierインデックス作成時(maildir対象)のログね。 cronで回した際のログなので使用文字列の重複率非常に高し。 んで、ちょっとテストケースを作ってみた。 mkdir -p /somewhere/test/dir/log cd /somewhere/test/dir time for i in $(seq -w 1 1000) do for j in $(seq -w 1 2000) do echo "test log text line ${j}" done > log/${i}.log done $ du -m log 47 log $ ls log|wc -l 1000 $ tar cf logs_with_dir.tar log $ tar cf logs_without_dir.tar log/*.log $ tar czf logs_with_dir.tar.gz log $ tar czf logs_without_dir.tar.gz log/*.log $ tar cjf logs_with_dir.tar.bz2 log $ tar cjf logs_without_dir.tar.bz2 log/*.log $ tar cJf logs_with_dir.tar.xz log $ tar cJf logs_without_dir.tar.xz log/*.log 結果: $ xz -l logs_with*dir.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1 16.9 KiB 46.4 MiB 0.000 CRC64 logs_with_dir.tar.xz 1 1 13.8 KiB 46.4 MiB 0.000 CRC64 logs_without_dir.tar.xz ------------------------------------------------------------------------------- 2 2 30.7 KiB 92.8 MiB 0.000 CRC64 2 files $ gzip -l logs_with*dir.tar.gz compressed uncompressed ratio uncompressed_name 5114261 48650240 89.5% logs_with_dir.tar 5114237 48650240 89.5% logs_without_dir.tar 10228498 97300480 89.5% (totals) ※ bzip2 は "-l" オプションなし $ ls -al logs_with*tar* -rw-r--r-- 1 hiro hiro 48650240 2013-01-07 10:27 logs_with_dir.tar -rw-r--r-- 1 hiro hiro 549025 2013-01-07 10:28 logs_with_dir.tar.bz2 -rw-r--r-- 1 hiro hiro 5114261 2013-01-07 10:27 logs_with_dir.tar.gz -rw-r--r-- 1 hiro hiro 17336 2013-01-07 10:30 logs_with_dir.tar.xz -rw-r--r-- 1 hiro hiro 48650240 2013-01-07 10:27 logs_without_dir.tar -rw-r--r-- 1 hiro hiro 543453 2013-01-07 10:30 logs_without_dir.tar.bz2 -rw-r--r-- 1 hiro hiro 5114237 2013-01-07 10:27 logs_without_dir.tar.gz -rw-r--r-- 1 hiro hiro 14120 2013-01-07 10:31 logs_without_dir.tar.xz logs_with_dir.tar.xz の方が 1.2倍くらい大きくなる。 三倍も差があるわけじゃないけど、圧縮率の差が大きいのは やっぱり tar.xzなんだよなぁ。 *.tar 大きさ同じなのになー、やっぱ不思議。 そんなに差出なかった -rw-r--r-- 1 aaa users 5118621 1月 7 22:29 logs_with_dir.tar.gz -rw-r--r-- 1 aaa users 13828 1月 7 22:24 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 13796 1月 7 22:26 logs_without_dir.tar.xz xzのやつをxz -dで解いた後xz -9で固めたらこうなった -rw-r--r-- 1 aaa users 48650240 1月 7 22:24 logs_with_dir.tar -rw-r--r-- 1 aaa users 48650240 1月 7 22:26 logs_without_dir.tar -rw-r--r-- 1 aaa users 13692 1月 7 22:24 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 13584 1月 7 22:26 logs_without_dir.tar.xz >>67 むむ、ぬぁにぃぃぃ、こっちの環境のせいなのかぁ? こっちでも、 xz -d して xz -9 してみた。 -rw-r--r-- 1 hiro hiro 48650240 2013-01-07 23:37 logs_with_dir.tar -rw-r--r-- 1 hiro hiro 48650240 2013-01-07 23:40 logs_without_dir.tar -rw-r--r-- 1 hiro hiro 16972 2013-01-07 23:37 logs_with_dir.tar.xz -rw-r--r-- 1 hiro hiro 13668 2013-01-07 23:40 logs_without_dir.tar.xz やっぱり 1.2倍くらい違う。 えーと、こっちの環境は debian 6.0.6/squeeze で $ tar --version tar (GNU tar) 1.23 $ xz --version xz (XZ Utils) 5.0.0 liblzma 5.0.0 debian パッケージ的には、 $ apt-show-versions tar xz-utils tar/squeeze uptodate 1.23-3 xz-utils/squeeze uptodate 5.0.0-2 なんだけど、そっちの環境を教えてもらえますか? Slackware 14.0 tar (GNU tar) 1.26 xz (XZ Utils) 5.0.4 liblzma 5.0.4 だった ひょっとしてと思ってたけど、これ多分メモリの搭載量によって結果変るんだと思う さっきやったPCでまた新しくデータを作ってからlogs_with_dir.tar.xzを作って それを別の二台に送って解凍してからまた固めたらこうなった 一番上が最初のPC Mem: 1165120 696316 468804 0 10940 328680 Mem: 3915520 129536 3785984 0 9660 85404 Mem: 767544 97744 669800 0 15752 67784 -rw-r--r-- 1 aaa users 13908 1月 8 00:09 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 13828 1月 8 00:12 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 16948 1月 8 00:16 logs_with_dir.tar.xz xzとtarは全部同じバージョン 最後のPCでwithoutのほう試すの忘れて電源切っちゃったけど 多分13800前後になるんだと思う なんでか分からないけどディレクトリ付きのほうが 圧縮するときメモリ使うってことじゃないかな と適当なこと書いたけどxzやってる間そんなメモリ使ってないな >>70 おー、そういう検証はとてもありがたい。 しかし Slackwareが出てくるとは…、年季入ってそうっすね。 こっちのメモリは、↓な感じ。 Mem: 3371996 2639292 732704 0 264628 1622812 まさにwithoutの方頼もうと思ってたら、電源切っちゃいましたか… メモリの使い方については、xz の man pageの "Memory usage"に いろいろ書いてありますね。 でも、メモリ搭載量で圧縮率に変動があるとしても、元々のお題の ディレクトリを含む/含まないによって圧縮率が変わることへの 直接の回答にはなっていないような感じ… んで、今さらながら より新しいバージョンの xz-utilsの NEWSを見てみたんだけど、 http://git.tukaani.org/?p=xz.git ;a=blob;f=NEWS;hb=HEAD 5.0.3 (2011-05-21) * liblzma fixes: - lzma_stream_buffer_encode() no longer creates an empty .xz Block if encoding an empty buffer. Such an empty Block with LZMA2 data would trigger a bug in 5.0.1 and older (see the first bullet point in 5.0.2 notes). When releasing 5.0.2, I thought that no encoder creates this kind of files but I was wrong. なんかこれっぽい感じ。 今日はもう寝るけど、明日にでも sid の 新しいバージョンビルドして確認してみよう。 >>67 のときと同じのを展開した後はこれで tar cJf logs_with_dir2.tar.xz log tar cJf logs_without_dir.tar.xz log/*.log Mem: 767544 97056 670488 0 15600 67276 -rw-r--r-- 1 aaa users 13908 1月 9 22:33 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 16948 1月 9 22:36 logs_with_dir2.tar.xz -rw-r--r-- 1 aaa users 13812 1月 9 22:34 logs_without_dir.tar.xz Mem: 1165120 359552 805568 0 7776 196436 -rw-r--r-- 1 aaa users 13908 1月 8 00:47 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 13828 1月 9 22:35 logs_with_dir2.tar.xz -rw-r--r-- 1 aaa users 13812 1月 9 22:36 logs_without_dir.tar.xz 同じPCでも今回はサイズが微妙に違った 明日とか言いつつ、時間たっちゃったな。 てことで xz-utils 5.1.1alpha+20120614 で確認してみた。 なんで 5.0.4じゃないかというと、debian sid に 5.0.4 がなかったから。 試した結果だけど、若干前よりどちらも圧縮率は上がったけど、 圧縮率の差はそのまま。 >>73 の 5.0.3のliblzma fixesは関係なかったみたい。 $ ls -al logs_with*tar* -rw-r--r-- 1 hiro hiro 16920 2013-01-14 03:54 logs_with_dir.tar.xz -rw-r--r-- 1 hiro hiro 13836 2013-01-14 03:55 logs_without_dir.tar.xz $ xz -l logs_with*dir.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1 16.5 KiB 46.4 MiB 0.000 CRC64 logs_with_dir.tar.xz 1 1 13.5 KiB 46.4 MiB 0.000 CRC64 logs_without_dir.tar.xz ------------------------------------------------------------------------------- 2 2 30.0 KiB 92.8 MiB 0.000 CRC64 2 files >>67 の人が検証してくれたおかげでとりあえず確認できたのは、 どうやらメモリ環境によって圧縮率は変動するらしいってことくらいか。 確かにそれらしいことが xz の man pageの "Memory usage"に 書かれてるけど、ディレクトリありなしによって圧縮率が変動する ことの理由にはなってないよなぁ。 てことで、なんかすっきりしないけど、解明はあきらめました。 >>67 の人は協力してくれてありがとう。 誰かが xz-utilsのソース読み込んで、 この現象をすっきり説明してくれることを願う。 >>67 >>75 今更だが気になったので実験。 ファイルはGNUのtar-1.26.tar.xzを使用した。 Debian wheezy 7.0 tar 1.26 xz (XZ Utils) 5.1.0alpha liblzma 5.1.0alpha Mem: 8104148 2631116 5473032 0 21232 1628468 これをgz,bzip2,xzでそれぞれ -c をつけてリダイレクトして圧縮する。 $ tar -cf tar_with.tar tar-1.26 $ tar -cf tar_without.tar tar-1.26/* $ du -b * | sort 14899200 tar_with.tar 14899200 tar_without.tar 1763224 tar_without.tar.xz 1788988 tar_with.tar.xz 2348783 tar_without.tar.bz2 2360563 tar_with.tar.bz2 3455923 tar_without.tar.gz 3456187 tar_with.tar.gz となった。.tarを比較してみる。 $ diff tar_with*.tar バイナリファイル tar_with.tar とtar_without.tar は異なります と出力されたのでtarの方に原因があると思われ。 ディレクトリの有無によるファイルサイズの違いについては xz-utilsよりtarのソースを読んだ方がいいかもしれない。 CMIX http://www.byronknoll.com/cmix.html 圧縮率のためならメモリもCPUも使いまくるというポリシーの実装。 ベンチマークを見ると、30MBのファイルを550kBに圧縮できる代わりに、 メモリ20GBと24分という時間をかけている。 すごいけど推奨メモリ32GBはきつい… BWTのの改良方法考えたんだけど、方法書くから誰かプログラム組んでもらえない? プログラム起こす人いたら、仕様書きます。 BWTのWikipedia見て思いついたことなので、私の仕様に不備があったら、 プログラム書かなくっても教えてもらえると助かる 誰でも簡単にパソコン1台で稼げる方法など 参考までに、 ⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。 グーグル検索⇒『宮本のゴウリエセレレ』 EVBFQZKA6L 僕の知り合いの知り合いができた副業情報ドットコム 関心がある人だけ見てください。 グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 V2TCB おまいら7zとxzは親戚で圧縮率が全く同じだって知ってた? >>83 7zは lzma2 や ppmd などから符号を選べる lzma2を選択したらxzと同じになる それだけ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる