壓縮庫使用Nvidia的CUDA

有誰知道採用了NVIDIA的CUDA library它實現標準的壓縮方法（如郵編，GZIP，也可選擇bzip2，LZMA，...）的一個項目？壓縮庫使用Nvidia的CUDA

我在想，如果算法，它可以利用大量的並行任務（如壓縮），會不會更快的圖形卡上比雙核或四核CPU上運行。

您如何看待這種方法的優點和缺點？

2009-01-19 Xn0vv3r

什麼是CUDAS內存限制？即對於並行處理數據來說是4K到32K塊，gzip可以通過不在塊之間保存字典來並行壓縮，這會使文件大小增加〜5％。看到。以Dictzip爲例。 – 2009-03-19 12:13:58

此演示文稿重點介紹Gzip並獲得10個數量級的加速http://on-demand.gputechconf.com/gtc/2014/presentations/S4459-parallel-lossless-compression-using-gpus.pdf – 2016-08-06 15:37:51

不知道任何人已經完成並公開發布。只是恕我直言，這聽起來不太有希望。

正如Martinus指出的，一些壓縮算法是高度串行的。像LZW這樣的塊壓縮算法可以通過獨立編碼每個塊來並行化。在文件級別可以並行化一個大的文件樹。

然而，這些都不是真正的SIMD式並行（單指令多數據），而他們不是大規模並行。

GPU的基本向量處理器，在那裏你可以做的加法指令，數百或數千所有步調一致，並執行其中很少有數據相關的分支程序。

壓縮算法一般聲音更像一個SPMD（單程序多數據）或MIMD（多指令多數據）編程模型，其更適合於多核CPU。

視頻壓縮算法可以通過GPGPU處理（如CUDA）進行加速，僅限於存在大量並行進行餘弦變換或卷積（用於運動檢測）的像素塊，並且IDCT或卷積子程序可以用無分支代碼表示。

GPU也類似於具有高數值強度（數學運算與存儲器訪問的比率）的算法。具有低數值強度的算法（如添加兩個向量）可以是大規模並行和SIMD，但仍然在GPU上運行得比因爲它們是內存綁定的CPU。

來源

2009-01-20 22:41:39

我的第一個想法是使用「大型文件樹」，但你提到的其他原因讓我相信，thx。 – Xn0vv3r 2009-01-21 07:17:20

通常壓縮算法不能使用並行任務，要使算法高度並行化是不容易的。在你的例子中，TAR不是一種壓縮算法，唯一可能高度並行化的算法是BZIP，因爲它是一種塊壓縮算法。每個塊可以分別壓縮，但這需要大量和大量的內存。當你看到使用多線程的7zip時，LZMA並不能同時工作，這是因爲7zip將數據流分成了兩個不同的流，每個流在一個單獨的線程中用LZMA壓縮，所以壓縮算法本身不是平行的。這種分裂只在數據允許時才起作用。

來源

2009-01-19 08:04:27 martinus

加密算法在這個領域已經相當成功，所以你可能想看看。以下是與CUDA和AES加密有關的論文：http://www.manavski.com/downloads/PID505889.pdf

來源

2009-01-19 08:32:02

使用快速看起來，這似乎加快了每個塊的加密。無法幫助阻止密碼鏈接，以避免某些類型的攻擊。 http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation – Calyth 2009-01-20 22:58:11

誠然，論文並沒有涉及它，但在GPU寶石中有一篇論文，一名合作者寫了關於使用shafer代碼的AES描述，而不是Cuda，它涵蓋了鏈接。不幸的是，該文章不在網上。反正鏈接可以由GPU來處理 – 2009-01-21 01:02:50

我們正在嘗試將bzip2移植到CUDA。 :)到目前爲止（只進行了粗略的測試），我們的Burrows-Wheeler變換比串行算法快30％。研究http://bzip2.github.com

來源

2010-12-23 11:39:41 tarantinofan

我們已經完成了第一階段，以增加無損數據壓縮算法的性能。 Bzip2被選爲原型，我們的團隊只優化了一個操作 - Burrows-Wheeler轉換，並且我們得到了一些結果：2x-4x加速了良好的可壓縮文件。代碼在我們所有的測試中運行得更快。

我們將完成bzip2，支持deflate和LZMA，用於一些真實的生活任務，如：HTTP流量和備份壓縮。

博客鏈接： http://www.wave-access.com/public_en/blog/2011/april/22/breakthrough-in-cuda-data-compression.aspx

來源

2011-04-22 16:46:23

30％是好的，但對於像備份應用中，由一個長鏡頭還不夠。

我的經驗是，在這種情況下，平均數據流使用gzip獲得1.2-1.7：1壓縮，並且最終限制在30-60Mb/s的輸出速率（這是跨越現代的廣泛範圍（大約2010年-2012）中的高端的CPU。

的限制在這裏通常是在其中數據可被饋送到CPU本身的速度。

不幸的是，爲了保持一個LTO5磁帶驅動器快樂，就需要一個原始（不可壓縮）數據速率約160Mb/s。如果饋送可壓縮數據，它需要更快的數據速率。

LTO壓縮顯然要快得多，但效率有點低（相當於gzip -1 - 對於大多數目的來說它已經夠用了）。 LTO4硬盤和硬盤通常內置AES-256加密引擎，可以保持這些速度。

這對我的情況意味着我需要400％或更好的隱患才能認爲它是值得的。

類似的考慮因素適用於局域網。在30Mb/s時，壓縮是Gb級網絡的障礙，問題是要在網絡上還是在壓縮上花費更多...... :)

來源

2012-03-05 15:58:49

壓縮庫使用Nvidia的CUDA

回答

相關問題