新たなデータ圧縮アルゴリズム「LZHAM」 75
ストーリー by hylom
モバイル向けにもよいかも 部門より
モバイル向けにもよいかも 部門より
insiderman 曰く、
ValveでOpenGLデバッガ「VOGL」などの開発に携わっていたRich Geldreich氏が、新たなデータ圧縮アルゴリズム「LZHAM」をリリースした（Phoronix、GitHub上のリポジトリ）。
LZHAMはLZMAをベースにしているが、より高速に圧縮されたデータを展開できるという点が特徴だそうで、ゲームや組み込み向けデバイスなどでの利用を想定しているという。圧縮率はzlibよりも高く、LZMAと同程度、展開速度はLZMAよりも高速だがzlibよりは遅い、という状況らしい。
GZIPの展開速度は尋常でないレベル (スコア:2)
相当高速なCPUで少しでもデータ(ゲームの場合は画像データが圧倒的に多いが)を圧縮したい場合に有効かもしれないけど、
GZIPの展開速度は尋常でないレベルにチューニングされてるから、トータルで考えるとGZIPを使っておいて間違いは無い。
しかも画像(テクスチャ)データは既にDXTとかPVRで圧縮されてるから、あまり差が出ない。
Re:GZIPの展開速度は尋常でないレベル (スコア:3)
ちなみにGZIPの展開アルゴリズムはINFLATEと言うけど、割と単純なアルゴリズムだから誰が実装しても
大して差がないと思うけど、凡人がC++で実装した時は3倍遅かった…
単純なソースなんでそれ以上チューニングのしようがなく断念したけど、ネイティブコード同士で3倍も差がつくとはかなりビビった…
GZIPのソースも見てみたけど、可動性無視でdefineを多用したソースだったんで、滅茶苦茶チューニングされている事だけは分かった。
Re:GZIPの展開速度は尋常でないレベル (スコア:2)
打ち間違えた…可読性でした。
(某氏のような誤字脱字だけはやるまいと思ってたけどやってしまった…気を付けよう)
Re: (スコア:0)
>しかも画像(テクスチャ)データは既にDXTとかPVRで圧縮されてるから、あまり差が出ない。
いや、DXTは圧縮効果ありますよ。
もしかしてDXTが何やってるか知らないんですか？
試しに手元のDDSファイルをZIPに固めればすぐに分かりますよ。
Re:GZIPの展開速度は尋常でないレベル (スコア:2)
もちろんDDSを圧縮すればさらに圧縮されるのは分かるけど、LZHAMで圧縮しても再圧縮する事になるから
最終的には同じぐらいのサイズにしかならないよと言うことだよ。
自分が比べたのはLZMAだけど差が1割有るか無いかだった。
状況によってはそれでも重要な差になるかもしれないけどね。
Re:GZIPの展開速度は尋常でないレベル (スコア:2)
LZHAMはLZMAより速い事が特徴で圧縮率はLZMAより若干悪いレベルだよね。
要するに
DDS(20MB)→GZIP→11MB
DDS(20MB)→LZMA or LZHAM→10MB
っていう事が言いたかったんだけど。(もちろん個人で試した平均的な結果だけど)
DDS(DXT)になっても所詮画像なだけに冗長な部分はかなり残ってるから、
そういうのはGZIPでも圧縮が効くから差がつき難いと思われる。
Re:GZIPの展開速度は尋常でないレベル (スコア:2)
随分前のコメントだけど…一応返答する。
> もともと可逆圧縮ってよほど簡易的な物や速度重視でない限りそう極端な差は出ません。
> DXTだろうがBMPだろうがTXTだろうが同じことです。
それは違う。
例えば、ソースのtarボール(tar+gzip)をLZMA(の類)で圧縮するとGZIPに比べて4分の1とかになるよ。圧倒的に違う。
画像データは冗長性が高いからGZIPでもかなり圧縮が効くから、そもそも差がつき難い。
それをDXTとかPVRで中途半端に不可逆圧縮されてるせいで(多分)、さらに差がつき難くなってるって話。
> DXTに対する圧縮それ自体の圧縮率が低いという意味にしか読めないんですよ。
DXTの圧縮率は低いと言える。
どんなデータであろうが4分の1にするだけだから。
Re: (スコア:0)
圧縮効果がないと言ってるわけじゃ無くて、GZIPとLZHAMの差が出にくいと言ってるだけだと思うが。
ジジイ多いと思ったのに (スコア:2)
ここまでTHcomp [thcomp.org]ネタは無しか
#またここに自分用のメモを書いてしまった。。。
Re:ジジイ多いと思ったのに (スコア:2)
若い人々に遠慮しました。
タレコまれフラグ [srad.jp]というユーザ日記とその最初のコメントには大笑いしたんだけど、感性は人それぞれなので。
自己解凍型を真剣に考えてほしい (スコア:0)
自己解凍型アプリケーションとして最小さいずにできるならうれしいけど、それに特化した解凍形式はあらわれませんか?
Re: (スコア:0)
X68kではお世話になりました。lzxだったかな。
PC-98にもなんかあった気がするけど思い出せない。
Re: (スコア:0)
lzexeがあって、lzxが出来たんだと思う。
Re: (スコア:0)
DrTeddy's Let's Diet!
なら知ってる。
Re:自己解凍型を真剣に考えてほしい (スコア:2)
Re: (スコア:0)
展開プログラムが異様に小さい圧縮アルゴリズムといえば BPE (Byte Pair Encoding) だと思う。
Re: (スコア:0)
今、自己解凍ってそんなに使いますかね?
zipならexplorerでもnoutilusでもfinderでも組み込みで展開してくれるから、手間を掛けたくないならzipで済ます事が多いですが。
Re:自己解凍型を真剣に考えてほしい (スコア:1, 興味深い)
自己解凍形式なんて怖くて実行できませんね
メールに添付するとブロックされることもありますので使わないです。
Re: (スコア:0)
某ファイル暗号化ソフトは、解凍プログラムをデータファイルとまとめたいのか、平気でexeの添付ファイルを送ってきます。送った側は暗号化でセキュリティを確保したつもりかもしれませんが、送られた側はとにかく俺を信用しろ、何も言わずexeを実行しろと迫られるのでたまったものではありません。こういう設計ができるセキュリティのプロの頭の中を見てみたいです。まだ暗号化ZIPの方がましです。
Re:自己解凍型を真剣に考えてほしい (スコア:1)
実行してくれれば信用してくれなくてもいいんだからねっ。
まあ、他にやりようがないんだろうけど。
Re:自己解凍型を真剣に考えてほしい (スコア:1)
受け取り手の方に専用アプリケーションインストール
こいつじゃ都合が悪いと判断されているシーン向けなので、そもそも話が合わんな。
Re:自己解凍型を真剣に考えてほしい (スコア:2)
(#2751196)が言及しているsharがそのひとつの生きたサンプルでしょうね。
制約の強い実行環境向けに機能拡張するということはあるかもしれません。
とはいえ多くの場合は別手段が求められるというのが実情?
Re: (スコア:0)
この時代に自己解凍ってことは、OSのブートイメージあたりを想定してるんですかね?
Re: (スコア:0)
自己解凍に見せかけた実行ファイルによく泣かされた思い出
Re: (スコア:0)
スマホ「これどうやって開くの?」
Re: (スコア:0)
圧縮したあと、シェルアーカイブ（shar）でだめ？
不毛 (スコア:0)
どーせ普及しないんだからもうzip以外の圧縮方式禁止しようぜ
新しくするのは圧縮率100倍とかの超画期的な方式が生まれてからでいいよ
Re:不毛 (スコア:2)
Zipは 日本語ファイル名が化けたりするのがな…。
Re:不毛 (スコア:1)
ZIP ファイルの UTF-8 オプションに関して [xlsoft.com]
ツールが UTF-8 オプションに対応してくれればいいんですけどね。
従来のファイル名と別に UTF-8 ファイル名のフィールドを用意せず、
フラグで切替にしてしまったのがかなりの敗因な気がする。
Re: (スコア:0)
なんか.Net FrameworkのZIP機能では日本語をUTF8で保存するけど、それをエクスプローラで扱えないとか同じ会社の物でもチグハグな対応になっているようです。
Re:不毛 (スコア:2)
7zみたいにマルチアーカイブな方が圧縮率は高いんですけど。
ソースファイルとか重複しているデータが多いと雲泥の差になる
Re:不毛 (スコア:1)
> zip以外の圧縮方式禁止しようぜ
勘弁してくれよ。
7z(LZMA)とzipじゃ、おれの経験上、最大30倍の開きがあったぜ。
MMDのモデルで、結構似たモデルが複数梱包されてるやつとか。
zipをDLしたら必ず7zに再梱包しとる。平均でも2倍くらい違う。
Re:不毛 (スコア:1)
ソースコードのパッケージなどでも zip は成績よくないですよね。
圧縮単位がファイル単位で，似たファイルが複数あっても畳めないんでしょうね。
Re:不毛 (スコア:1)
圧縮効率よりアーカイブとしての使い勝手を優先するなら、ファイル追加や削除のたびに全体を再圧縮する方が非効率です。
この手の話題は「圧縮」と「アーカイブ」という本来別々の機能がひとつにまとまってるので、気をつけないと話がかみ合わなくなりやすいですね。
うじゃうじゃ
Re:不毛 (スコア:1)
そうですね。私自身は圧縮ファイルから一部のファイルを取り出すとか，更新するとかの使い方は
ほとんどしないので，圧縮率と全体を圧縮・展開するときに遅すぎなければいい，という観点になります。
Re: (スコア:0)
一般ユーザがエクスプローラ上で使うもの、ということであればそれで充分かもしれませんね。
ネット経由でリアルタイムに圧縮データをやりとりする必要がある場合、例えば
スマホアプリで、実行速度としては問題ないけどCPU負荷が高すぎて電池の消耗や加熱が激しい、というケースは
たとえ数%の改善度であっても高速かつ負担の低い圧縮・展開方式が欲しい、みたいなことがあったりするかもしれなかったりしちゃったりするかも。
Re: (スコア:0)
圧縮方式が固定化することによりハードウエアでの最適化がしやすくなるので、数％しか改善されないのなら、新たな圧縮方式を採用しないという判断もできると思います。
Re: (スコア:0)
動画、音声、画像どうすんのよ。
H.264/265 とか FLAC とか PNG とか使えなかったらいろいろ即死ですわ。
Re: (スコア:0)
Android以上にバージョンと独自拡張が混在してるファイルフォーマットなんか勘弁してくれ
唖然とした (スコア:0)
このアルゴリズムってゲームプログラムなどへの組み込みを想定してるんでしょ？
どこにもアーカイブとかコンテナなんて書いてないのにZIPでおkとか…
これはアルゴリズムだよ？
LHAェ… (スコア:0)
普及しててもウイルス検知ソフトの不作為で殺されたようなもんだが
Re: (スコア:0)
Server:"Apache/1.3.42 (Debian) mod_gzip/1.3.26.1a mod_perl/1.31"
Re: (スコア:0)
本家のsourceforgeとか見ると、bzip2もそこそこ普及していると思うんだ。
デコーダーが後方互換なら (スコア:0)
デコーダーがzipとかに後方互換があって圧縮率高くなるなら普及するだろうけどそんなに都合のいいものはないか。
Re: (スコア:0)
Deflate 互換の zopfli での再圧縮が限界ではないかと
エルザム？ (スコア:0)
今が駆け抜ける時！
展開より圧縮の方なんとかして (スコア:0)
LZMA系はメモリを大量に使うし、時間がかかって大変。ｘｚ5.2でやっとスレッド処理できるようになったんだけど、その分メモリを何倍も食うようになって、ウンGBが当たり前になってしまった…どうにかなりませんか？
Re: (スコア:0)
一体何を圧縮しようとしてんの？
1メガ×100ファイルをCore2Duo・メモリ3Gのマッシーンで7z-LZMA圧縮するのでも数分程度しかかかんないのに。
それよりデカいもの？
俺のティンコか？
Re:展開より圧縮の方なんとかして (スコア:1)
今時「1メガ×100ファイル」なんて、小さすぎて、話になりませんよ。
HDDの容量をテラバイト単位で表現する時代に、たかだか0.0001テラバイトのデータを議論するなんて
君にティンコがあるのか無いのかを議論するぐらい不毛です。
Re: (スコア:0)
圧縮レベル落としても、ほとんどの場合ZIPより圧縮率がいいので
大きなファイルは圧縮レベル落としてやってます。