パスワードを忘れた? アカウント作成
11887184 story
ソフトウェア

新たなデータ圧縮アルゴリズム「LZHAM」 75

ストーリー by hylom
モバイル向けにもよいかも 部門より
insiderman 曰く、

ValveでOpenGLデバッガ「VOGL」などの開発に携わっていたRich Geldreich氏が、新たなデータ圧縮アルゴリズム「LZHAM」をリリースした(PhoronixGitHub上のリポジトリ)。

LZHAMはLZMAをベースにしているが、より高速に圧縮されたデータを展開できるという点が特徴だそうで、ゲームや組み込み向けデバイスなどでの利用を想定しているという。圧縮率はzlibよりも高く、LZMAと同程度、展開速度はLZMAよりも高速だがzlibよりは遅い、という状況らしい。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 相当高速なCPUで少しでもデータ(ゲームの場合は画像データが圧倒的に多いが)を圧縮したい場合に有効かもしれないけど、
    GZIPの展開速度は尋常でないレベルにチューニングされてるから、トータルで考えるとGZIPを使っておいて間違いは無い。

    しかも画像(テクスチャ)データは既にDXTとかPVRで圧縮されてるから、あまり差が出ない。

    • ちなみにGZIPの展開アルゴリズムはINFLATEと言うけど、割と単純なアルゴリズムだから誰が実装しても
      大して差がないと思うけど、凡人がC++で実装した時は3倍遅かった…

      単純なソースなんでそれ以上チューニングのしようがなく断念したけど、ネイティブコード同士で3倍も差がつくとはかなりビビった…
      GZIPのソースも見てみたけど、可動性無視でdefineを多用したソースだったんで、滅茶苦茶チューニングされている事だけは分かった。

      親コメント
    • by Anonymous Coward

      >しかも画像(テクスチャ)データは既にDXTとかPVRで圧縮されてるから、あまり差が出ない。
      いや、DXTは圧縮効果ありますよ。
      もしかしてDXTが何やってるか知らないんですか?

      試しに手元のDDSファイルをZIPに固めればすぐに分かりますよ。

      • もちろんDDSを圧縮すればさらに圧縮されるのは分かるけど、LZHAMで圧縮しても再圧縮する事になるから
        最終的には同じぐらいのサイズにしかならないよと言うことだよ。

        自分が比べたのはLZMAだけど差が1割有るか無いかだった。
        状況によってはそれでも重要な差になるかもしれないけどね。

        親コメント
      • by Anonymous Coward

        圧縮効果がないと言ってるわけじゃ無くて、GZIPとLZHAMの差が出にくいと言ってるだけだと思うが。

  • ここまでTHcomp [thcomp.org]ネタは無しか

    --

    #またここに自分用のメモを書いてしまった。。。
  • by Anonymous Coward on 2015年01月27日 17時42分 (#2750938)

    自己解凍型アプリケーションとして最小さいずにできるならうれしいけど、それに特化した解凍形式はあらわれませんか?

    • by Anonymous Coward

      X68kではお世話になりました。lzxだったかな。
      PC-98にもなんかあった気がするけど思い出せない。

    • by Anonymous Coward

      展開プログラムが異様に小さい圧縮アルゴリズムといえば BPE (Byte Pair Encoding) だと思う。

    • by Anonymous Coward

      今、自己解凍ってそんなに使いますかね?
      zipならexplorerでもnoutilusでもfinderでも組み込みで展開してくれるから、手間を掛けたくないならzipで済ます事が多いですが。

    • by Anonymous Coward

      自己解凍に見せかけた実行ファイルによく泣かされた思い出

    • by Anonymous Coward

      スマホ「これどうやって開くの?」

      • by Anonymous Coward

        圧縮したあと、シェルアーカイブ(shar)でだめ?

  • by Anonymous Coward on 2015年01月27日 18時45分 (#2750976)

    どーせ普及しないんだからもうzip以外の圧縮方式禁止しようぜ
    新しくするのは圧縮率100倍とかの超画期的な方式が生まれてからでいいよ

    • by gyokuto (45996) on 2015年01月27日 19時10分 (#2750996)

      Zipは 日本語ファイル名が化けたりするのがな…。

      親コメント
      • by Anonymous Coward on 2015年01月27日 20時30分 (#2751085)

        ZIP ファイルの UTF-8 オプションに関して [xlsoft.com]

        ツールが UTF-8 オプションに対応してくれればいいんですけどね。

        従来のファイル名と別に UTF-8 ファイル名のフィールドを用意せず、
        フラグで切替にしてしまったのがかなりの敗因な気がする。

        親コメント
        • by Anonymous Coward

          なんか.Net FrameworkのZIP機能では日本語をUTF8で保存するけど、それをエクスプローラで扱えないとか同じ会社の物でもチグハグな対応になっているようです。

    • by suezo (2881) on 2015年01月28日 1時30分 (#2751270) ホームページ 日記

      7zみたいにマルチアーカイブな方が圧縮率は高いんですけど。
      ソースファイルとか重複しているデータが多いと雲泥の差になる

      親コメント
    • by Anonymous Coward on 2015年01月27日 22時01分 (#2751147)

      > zip以外の圧縮方式禁止しようぜ

      勘弁してくれよ。
      7z(LZMA)とzipじゃ、おれの経験上、最大30倍の開きがあったぜ。
      MMDのモデルで、結構似たモデルが複数梱包されてるやつとか。
      zipをDLしたら必ず7zに再梱包しとる。平均でも2倍くらい違う。

      親コメント
      • by hanhan4 (43237) on 2015年01月28日 0時16分 (#2751240) 日記

        ソースコードのパッケージなどでも zip は成績よくないですよね。
        圧縮単位がファイル単位で,似たファイルが複数あっても畳めないんでしょうね。

        親コメント
        • by albireo (7374) on 2015年01月28日 2時06分 (#2751284) ホームページ 日記

          圧縮効率よりアーカイブとしての使い勝手を優先するなら、ファイル追加や削除のたびに全体を再圧縮する方が非効率です。

          この手の話題は「圧縮」と「アーカイブ」という本来別々の機能がひとつにまとまってるので、気をつけないと話がかみ合わなくなりやすいですね。

          --
          うじゃうじゃ
          親コメント
          • by hanhan4 (43237) on 2015年01月28日 7時37分 (#2751315) 日記

            そうですね。私自身は圧縮ファイルから一部のファイルを取り出すとか,更新するとかの使い方は
            ほとんどしないので,圧縮率と全体を圧縮・展開するときに遅すぎなければいい,という観点になります。

            親コメント
    • by Anonymous Coward

      一般ユーザがエクスプローラ上で使うもの、ということであればそれで充分かもしれませんね。

      ネット経由でリアルタイムに圧縮データをやりとりする必要がある場合、例えば
      スマホアプリで、実行速度としては問題ないけどCPU負荷が高すぎて電池の消耗や加熱が激しい、というケースは
      たとえ数%の改善度であっても高速かつ負担の低い圧縮・展開方式が欲しい、みたいなことがあったりするかもしれなかったりしちゃったりするかも。

      • by Anonymous Coward

        圧縮方式が固定化することによりハードウエアでの最適化がしやすくなるので、数%しか改善されないのなら、新たな圧縮方式を採用しないという判断もできると思います。

    • 動画、音声、画像どうすんのよ。

      H.264/265 とか FLAC とか PNG とか使えなかったらいろいろ即死ですわ。

    • by Anonymous Coward

      Android以上にバージョンと独自拡張が混在してるファイルフォーマットなんか勘弁してくれ

    • by Anonymous Coward

      このアルゴリズムってゲームプログラムなどへの組み込みを想定してるんでしょ?
      どこにもアーカイブとかコンテナなんて書いてないのにZIPでおkとか…
      これはアルゴリズムだよ?

    • by Anonymous Coward

      普及しててもウイルス検知ソフトの不作為で殺されたようなもんだが

    • by Anonymous Coward

      Server:"Apache/1.3.42 (Debian) mod_gzip/1.3.26.1a mod_perl/1.31"

    • by Anonymous Coward

      本家のsourceforgeとか見ると、bzip2もそこそこ普及していると思うんだ。

  • by Anonymous Coward on 2015年01月27日 19時15分 (#2751006)

    デコーダーがzipとかに後方互換があって圧縮率高くなるなら普及するだろうけどそんなに都合のいいものはないか。

    • by Anonymous Coward

      Deflate 互換の zopfli での再圧縮が限界ではないかと

  • by Anonymous Coward on 2015年01月27日 21時01分 (#2751107)

    今が駆け抜ける時!

  • by Anonymous Coward on 2015年01月27日 21時49分 (#2751140)

    LZMA系はメモリを大量に使うし、時間がかかって大変。xz5.2でやっとスレッド処理できるようになったんだけど、その分メモリを何倍も食うようになって、ウンGBが当たり前になってしまった…どうにかなりませんか?

    • by Anonymous Coward

      一体何を圧縮しようとしてんの?
      1メガ×100ファイルをCore2Duo・メモリ3Gのマッシーンで7z-LZMA圧縮するのでも数分程度しかかかんないのに。
      それよりデカいもの?
      俺のティンコか?

      • by Anonymous Coward on 2015年01月28日 1時57分 (#2751282)

        今時「1メガ×100ファイル」なんて、小さすぎて、話になりませんよ。

        HDDの容量をテラバイト単位で表現する時代に、たかだか0.0001テラバイトのデータを議論するなんて
        君にティンコがあるのか無いのかを議論するぐらい不毛です。

        親コメント
    • by Anonymous Coward

      圧縮レベル落としても、ほとんどの場合ZIPより圧縮率がいいので
      大きなファイルは圧縮レベル落としてやってます。

typodupeerror

Stay hungry, Stay foolish. -- Steven Paul Jobs

読み込み中...