アカウント名:
パスワード:
ついでに圧縮率もちょっと悪くなるけど、並列処理できる分、GPUで高速化できますよって話ですよね。
大量の画像を同時並列的に処理する場合でも高速化できるのでしょうか
可逆圧縮動画コーデック UtVideo の作者の人 [twitter.com]が、
別にそんなことしなくても全体をコア数で分割して並列処理したらコア数倍速くなるという自明な高速化を昔から適用できている
GPUに投げるには処理が軽すぎるので、CPUメモリとGPUメモリの間で転送してGPUで処理するよりCPUで全部処理したほうが速い
と、GPUでハフマン展開を並列処理することそのものに否定的で一蹴してますね。
その人が否定しているのは「UtVideoで使うには」という部分だけでは
こっちはたしかにUtVideo限定のものですが、元コメの質問「大量の画像を同時並列的に処理する場合」にも該当。
こっちは一般論としてハフマン復号をGPU処理することを否定しているかと。
> 別にそんなことしなくても全体をコア数で分割して並列処理したらコア数倍速くなるという自明な高速化を昔から適用できている展開時(ハフマン符号のデコード)にコア数分割するのがそもそも普通のデータ構造だと厳しいって論文だけど、昔から適用出来てるってほんと？
# 圧縮時(ハフマン符号のエンコード)ならそら昔からやってるよね
元コメは、動画コーデックつまり独立した複数のハフマン符号列をデコードする場合の話で、その場合は符号列ごとにコアを割り当てればいい、という話でしょ。
一つの長大なハフマン符号列をデコードする場合、つまり「すごくばかでかいgzipファイルを展開する」とかいった場合には今まで並列化できなかったのが本手法で並列化できるようになるわけですし、今後の展開としてgzipへの組み込みを挙げられてますね。
そのツイートは「元コメ」(大量云々)とは無関係にコア数分割と言ってる様に見えます。レポートの内容を見れば主題は単一ソースのデコード時なのは明確です。これで、エンコード時の話や、複数ソースの同時デコードの話してるならかなり残念ですね。
これ語弊があると思うんだけど、gzipがストリームで頭から展開して中味が読めるってことは、ファイルがでかくても符号列がでかいわけじゃないんじゃないかな。実用上はどっかに仕切りを置いて切ってるんでしょ。
もちろん、大きく見た方が圧縮には有利なんだろうけど、巨大なメモリ展開まで含めて考えると実用的じゃないんでは。
個人的にはdelfate系のデータ列はハフマン符合の連続だけで出来てるわけじゃないのでギャップ配列のデータ構造が複雑化しそうだし、LZ77の圧縮方向はともかく展開方向は並列向きじゃなさそうだし、って事で労多くして功少なしな感じになりそうだけど……
上手く行ったらどんな風に解決するのか見てみたい。
スライド辞書は別の革命が要るから別物になる。
解決しても「今回の発表の手法の発展型」とはとても呼べないだろうね。出来てもハフマンの部分にこのストーリーの手法が組み込まれている、程度では。
並列処理したらコア数倍速くなるというのなら並列度が桁違いのGPUで処理したほうが圧倒的に速くなるのでは。
UtVideoで使うのは向かないでしょうが、これは肥大化するGPUのテクスチャ圧縮の分野では使えそうですね。最近のゲームは平気で数GB超えるテクスチャバッファ使いますし、GPU内で処理完結するならCPUとの転送も関係ないし。今でも圧縮は普通に使われてますが、圧縮展開の速度が上がれば使える範囲が増えて嬉しそう。
性能を追求したファイル圧縮方式は複数のファイルを一個にまとめたうえで圧縮するからファイルの数は問題にならないと思う。
「アルゴリズム単体で見ればちょっと遅くなるけど」というものではないでしょう。ギャップ配列という、本来デコードに必要ない（なくてもデコード可能な）ヒント情報を付け加えることによってデコードを高速化する、というものではないかと。
ただ、「圧縮も高速化される」という点が分からないですね。（提示されているリリース文からは読み取れない）
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
アルゴリズム単体で見ればちょっと遅くなるけど (スコア:2)
ついでに圧縮率もちょっと悪くなるけど、
並列処理できる分、GPUで高速化できますよって話ですよね。
大量の画像を同時並列的に処理する場合でも高速化できるのでしょうか
Re:アルゴリズム単体で見ればちょっと遅くなるけど (スコア:1)
可逆圧縮動画コーデック UtVideo の作者の人 [twitter.com]が、
と、GPUでハフマン展開を並列処理することそのものに否定的で一蹴してますね。
Re: (スコア:0)
その人が否定しているのは「UtVideoで使うには」という部分だけでは
Re:アルゴリズム単体で見ればちょっと遅くなるけど (スコア:1)
こっちはたしかにUtVideo限定のものですが、元コメの質問「大量の画像を同時並列的に処理する場合」にも該当。
こっちは一般論としてハフマン復号をGPU処理することを否定しているかと。
Re: (スコア:0)
> 別にそんなことしなくても全体をコア数で分割して並列処理したらコア数倍速くなるという自明な高速化を昔から適用できている
展開時(ハフマン符号のデコード)にコア数分割するのがそもそも普通のデータ構造だと厳しいって論文だけど、昔から適用出来てるってほんと？
# 圧縮時(ハフマン符号のエンコード)ならそら昔からやってるよね
Re:アルゴリズム単体で見ればちょっと遅くなるけど (スコア:2)
元コメは、動画コーデックつまり独立した複数のハフマン符号列をデコードする場合の話で、
その場合は符号列ごとにコアを割り当てればいい、という話でしょ。
一つの長大なハフマン符号列をデコードする場合、つまり「すごくばかでかいgzipファイルを展開する」とかいった場合には
今まで並列化できなかったのが本手法で並列化できるようになるわけですし、
今後の展開としてgzipへの組み込みを挙げられてますね。
Re: (スコア:0)
そのツイートは「元コメ」(大量云々)とは無関係にコア数分割と言ってる様に見えます。
レポートの内容を見れば主題は単一ソースのデコード時なのは明確です。
これで、エンコード時の話や、複数ソースの同時デコードの話してるならかなり残念ですね。
Re: (スコア:0)
これ語弊があると思うんだけど、gzipがストリームで頭から展開して中味が読めるってことは、ファイルがでかくても符号列がでかいわけじゃないんじゃないかな。実用上はどっかに仕切りを置いて切ってるんでしょ。
もちろん、大きく見た方が圧縮には有利なんだろうけど、巨大なメモリ展開まで含めて考えると実用的じゃないんでは。
Re: (スコア:0)
個人的にはdelfate系のデータ列はハフマン符合の連続だけで出来てるわけじゃないのでギャップ配列のデータ構造が複雑化しそうだし、LZ77の圧縮方向はともかく展開方向は並列向きじゃなさそうだし、って事で労多くして功少なしな感じになりそうだけど……
上手く行ったらどんな風に解決するのか見てみたい。
Re: (スコア:0)
まさにそれが従来なかった点。
従来の問題は必ず頭から読まなきゃいけなかったけど、
今回のは途中から読めるようにしたので展開処理を並列化できるようになったと言う話。
予めデータ分割してから圧縮しておけば従来方式でも並列化可能と考えるとイマイチ萌えないけど、
何も考えなくてもgunzipが早く終わりますと言われれば悪くはない。
Re: (スコア:0)
スライド辞書は別の革命が要るから別物になる。
解決しても「今回の発表の手法の発展型」とはとても呼べないだろうね。
出来てもハフマンの部分にこのストーリーの手法が組み込まれている、程度では。
Re: (スコア:0)
並列処理したらコア数倍速くなるというのなら並列度が桁違いのGPUで処理したほうが圧倒的に速くなるのでは。
Re: (スコア:0)
UtVideoで使うのは向かないでしょうが、これは肥大化するGPUのテクスチャ圧縮の分野では使えそうですね。
最近のゲームは平気で数GB超えるテクスチャバッファ使いますし、GPU内で処理完結するならCPUとの転送も関係ないし。
今でも圧縮は普通に使われてますが、圧縮展開の速度が上がれば使える範囲が増えて嬉しそう。
Re: (スコア:0)
性能を追求したファイル圧縮方式は複数のファイルを一個にまとめたうえで圧縮するからファイルの数は問題にならないと思う。
Re: (スコア:0)
「アルゴリズム単体で見ればちょっと遅くなるけど」というものではないでしょう。
ギャップ配列という、本来デコードに必要ない（なくてもデコード可能な）ヒント情報を付け加えることによってデコードを高速化する、というものではないかと。
ただ、「圧縮も高速化される」という点が分からないですね。
（提示されているリリース文からは読み取れない）