アカウント名:
パスワード:
ついでに圧縮率もちょっと悪くなるけど、並列処理できる分、GPUで高速化できますよって話ですよね。
大量の画像を同時並列的に処理する場合でも高速化できるのでしょうか
可逆圧縮動画コーデック UtVideo の作者の人 [twitter.com]が、
別にそんなことしなくても全体をコア数で分割して並列処理したらコア数倍速くなるという自明な高速化を昔から適用できている
GPUに投げるには処理が軽すぎるので、CPUメモリとGPUメモリの間で転送してGPUで処理するよりCPUで全部処理したほうが速い
と、GPUでハフマン展開を並列処理することそのものに否定的で一蹴してますね。
その人が否定しているのは「UtVideoで使うには」という部分だけでは
こっちはたしかにUtVideo限定のものですが、元コメの質問「大量の画像を同時並列的に処理する場合」にも該当。
こっちは一般論としてハフマン復号をGPU処理することを否定しているかと。
> 別にそんなことしなくても全体をコア数で分割して並列処理したらコア数倍速くなるという自明な高速化を昔から適用できている展開時(ハフマン符号のデコード)にコア数分割するのがそもそも普通のデータ構造だと厳しいって論文だけど、昔から適用出来てるってほんと？
# 圧縮時(ハフマン符号のエンコード)ならそら昔からやってるよね
元コメは、動画コーデックつまり独立した複数のハフマン符号列をデコードする場合の話で、その場合は符号列ごとにコアを割り当てればいい、という話でしょ。
一つの長大なハフマン符号列をデコードする場合、つまり「すごくばかでかいgzipファイルを展開する」とかいった場合には今まで並列化できなかったのが本手法で並列化できるようになるわけですし、今後の展開としてgzipへの組み込みを挙げられてますね。
そのツイートは「元コメ」(大量云々)とは無関係にコア数分割と言ってる様に見えます。レポートの内容を見れば主題は単一ソースのデコード時なのは明確です。これで、エンコード時の話や、複数ソースの同時デコードの話してるならかなり残念ですね。
より多くのコメントがこの議論にあるかもしれませんが、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)
そのツイートは「元コメ」(大量云々)とは無関係にコア数分割と言ってる様に見えます。
レポートの内容を見れば主題は単一ソースのデコード時なのは明確です。
これで、エンコード時の話や、複数ソースの同時デコードの話してるならかなり残念ですね。