压缩库使用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

回答

相关问题