diary/Kojima/2010-01-25
の編集
http://plamo.linet.gr.jp/?diary/Kojima/2010-01-25
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
-- 雛形とするページ --
diary/Template
[[diary/Kojima]] ・圧縮ツール 最近、GNUのFTPサイトとかでも tar.xz 形式のファイルを目にするようになってきたので、XZ Utils をパッケージ化。 ついでに tar 1.22 が対応している LZO 形式用の lzo と lzop もパッケージ化してみた。 [[XZ Utils:http://tukaani.org/xz/]]は、もともと Windows用に開発された高圧縮率を誇る 7-zip 形式の圧縮ツールのエンジン部分である LZMA SDK を元に、 Unix用に使いやすいように改造したツール。 一方、lzoは[[OberhumerさんがLZ(Lempel-Ziff)方式の圧縮に自分のアイデアを盛り込んで考案した圧縮形式:http://www.oberhumer.com/opensource/lzo/]] で、圧縮速度に優れているらしい。 オープンソースな LZMA SDKを元にした lzma utils は以前から入れていたので、これで tar の圧縮形式として gzip, bzip2, lzma に加えて、lzo と xz が使えるようになった。 そうなると、ベンチマークをしてみたくなるのが性で、linux-2.6.32 のソースコードをそれぞれの形式で固めるのかかった時間と圧縮後のサイズをグラフにしてみた #ref(compression.jpg) ちょっとわかりにくいけど、縦軸はブルー(ファイルサイズ)の場合は MB 単位、レッド(処理速度)の場合はかかった秒数で、具体的な数字はこんな感じ。 非圧縮(tar cf ) 5 秒 365MB LZO(tar c --lzo) 6秒 124MB gzip(tar czf) 27秒 79MB bzip2(tar cjf) 134秒 62MB lzma( tar c --lzma) 446秒 53MB xz(tar cJf) 443秒 53MB キャッシュが効くように事前に一度 tar cf で linux-2.6.32 のソースコードをざっと読み込んでから順番に流したので、 多分上記の結果は CPU 処理の時間で、ディスクI/Oはそれほど影響していないはず。 逆に言うと、初めてやる時はディスク読み込みの時間がかなり余計にかかるので、処理時間はもっと長くなるはず。 まぁ見事に時間と圧縮率がトレードオフになっているというか、圧縮率の高いものは時間がかかるし、高速なものは圧縮率が低いという結果になっている。 それでも、今までは gzip と bzip2 くらいしかオプションが無かったから、選択肢の幅はより増えた、という感じかな。 個人的には、圧縮率は低いものの、ほとんど素の tar と変らない程度の速度で圧縮できる lzo 形式が結構興味深いところ。 どこが律速になるかはシステムごとに要調査だろうけど、この速度は大規模なファイルシステムの定期バックアップみたいな用途には結構魅力的な気がする。 その一方、5年後、10年後でもちゃんと読めるか、ということを考えると、gzip とか bzip2 に手が伸びるところだなぁ(苦笑 -これだけ見ると、lzma/xz は時間がかかりすぎのように見えるけど、これらの形式は展開速度は速くなるように工夫されているので、展開時はbzip2やgzipと比べてもそれほど遜色ないはず。その意味で、(アップロード時に)圧縮する回数よりも(ダウンロードして)展開する回数の方が圧倒的に多いソースコードの配布のような使い方では、xz 形式というのは十分説得力のある形式という気はする。 -- [[kojima]] &new{2010-01-25 (月) 13:50:09}; -linux-2.6.33でLZO形式サポートされるようなのでlinux-2.6.33-rc4-git3でLZO圧縮なカーネルコンパイルしてみたことがありましたがlzma形式の2倍くらいのサイズになったのでLZO形式はもう忘れました。 -- [[名倉]] &new{2010-01-25 (月) 14:32:33}; #comment
タイムスタンプを変更しない
[[diary/Kojima]] ・圧縮ツール 最近、GNUのFTPサイトとかでも tar.xz 形式のファイルを目にするようになってきたので、XZ Utils をパッケージ化。 ついでに tar 1.22 が対応している LZO 形式用の lzo と lzop もパッケージ化してみた。 [[XZ Utils:http://tukaani.org/xz/]]は、もともと Windows用に開発された高圧縮率を誇る 7-zip 形式の圧縮ツールのエンジン部分である LZMA SDK を元に、 Unix用に使いやすいように改造したツール。 一方、lzoは[[OberhumerさんがLZ(Lempel-Ziff)方式の圧縮に自分のアイデアを盛り込んで考案した圧縮形式:http://www.oberhumer.com/opensource/lzo/]] で、圧縮速度に優れているらしい。 オープンソースな LZMA SDKを元にした lzma utils は以前から入れていたので、これで tar の圧縮形式として gzip, bzip2, lzma に加えて、lzo と xz が使えるようになった。 そうなると、ベンチマークをしてみたくなるのが性で、linux-2.6.32 のソースコードをそれぞれの形式で固めるのかかった時間と圧縮後のサイズをグラフにしてみた #ref(compression.jpg) ちょっとわかりにくいけど、縦軸はブルー(ファイルサイズ)の場合は MB 単位、レッド(処理速度)の場合はかかった秒数で、具体的な数字はこんな感じ。 非圧縮(tar cf ) 5 秒 365MB LZO(tar c --lzo) 6秒 124MB gzip(tar czf) 27秒 79MB bzip2(tar cjf) 134秒 62MB lzma( tar c --lzma) 446秒 53MB xz(tar cJf) 443秒 53MB キャッシュが効くように事前に一度 tar cf で linux-2.6.32 のソースコードをざっと読み込んでから順番に流したので、 多分上記の結果は CPU 処理の時間で、ディスクI/Oはそれほど影響していないはず。 逆に言うと、初めてやる時はディスク読み込みの時間がかなり余計にかかるので、処理時間はもっと長くなるはず。 まぁ見事に時間と圧縮率がトレードオフになっているというか、圧縮率の高いものは時間がかかるし、高速なものは圧縮率が低いという結果になっている。 それでも、今までは gzip と bzip2 くらいしかオプションが無かったから、選択肢の幅はより増えた、という感じかな。 個人的には、圧縮率は低いものの、ほとんど素の tar と変らない程度の速度で圧縮できる lzo 形式が結構興味深いところ。 どこが律速になるかはシステムごとに要調査だろうけど、この速度は大規模なファイルシステムの定期バックアップみたいな用途には結構魅力的な気がする。 その一方、5年後、10年後でもちゃんと読めるか、ということを考えると、gzip とか bzip2 に手が伸びるところだなぁ(苦笑 -これだけ見ると、lzma/xz は時間がかかりすぎのように見えるけど、これらの形式は展開速度は速くなるように工夫されているので、展開時はbzip2やgzipと比べてもそれほど遜色ないはず。その意味で、(アップロード時に)圧縮する回数よりも(ダウンロードして)展開する回数の方が圧倒的に多いソースコードの配布のような使い方では、xz 形式というのは十分説得力のある形式という気はする。 -- [[kojima]] &new{2010-01-25 (月) 13:50:09}; -linux-2.6.33でLZO形式サポートされるようなのでlinux-2.6.33-rc4-git3でLZO圧縮なカーネルコンパイルしてみたことがありましたがlzma形式の2倍くらいのサイズになったのでLZO形式はもう忘れました。 -- [[名倉]] &new{2010-01-25 (月) 14:32:33}; #comment
テキスト整形のルールを表示する
添付ファイル:
compression.jpg
492件
[
詳細
]