使用Nvidia CUDA的压缩库

qquas 发布于 2018-06-03 compression 最后更新 2018-06-03 18:47 207 浏览

有没有人知道使用NVIDIA的CUDA library实现标准压缩方法(如Zip,GZip,BZip2,LZMA等)的项目? 我想知道是否可以使用大量并行任务(如压缩)的算法在图形卡上的运行速度不会比使用双核或四核CPU时快得多。 您如何看待这种方法的优缺点?

已邀请:

met

赞同来自:

通常,压缩算法不能使用并行任务,要使算法高度可并行化并不容易。在你的例子中,TAR不是一种压缩算法,唯一可能高度并行化的算法是BZIP,因为它是一种块压缩算法。每个块可以分别压缩,但这需要大量和大量的内存。当你看到使用多线程的7zip时,LZMA并不能同时工作,这是因为7zip将数据流分成了两个不同的流,每个流在一个单独的线程中用LZMA压缩,所以压缩算法本身不是平行的。这种分裂只在数据允许的情况下才起作用。

lnon

赞同来自:

加密算法在这个领域已经相当成功,所以你可能想研究一下。以下是与CUDA和AES加密相关的论文:http://www.manavski.com/downloads/PID505889.pdf

tquod

赞同来自:

没有意识到任何人已经做到了这一点并将其公之于众。只是恕我直言,这听起来不太有希望。 正如Martinus指出的,一些压缩算法是高度串行的。像LZW这样的块压缩算法可以通过独立编码每个块来并行化。在文件级别可以并行化一个大的文件树。 但是,这些都不是真正的SIMD式并行(Single Instruction Multiple Data),并且它们不是大规模并行的。 GPU基本上是矢量处理器,您可以在锁定步骤中执行数百或数千条ADD指令,并执行只有极少数数据相关分支的程序。 一般来说,压缩算法听起来更像SPMD(单程序多数据)或MIMD(多指令多数据)编程模型,它更适合多核cpus。 视频压缩算法可以像CUDA一样通过GPGPU处理进行加速,仅限于有大量像素块并行进行余弦变换或卷积(用于运动检测),并且可以表示IDCT或卷积子程序与无分支代码。 GPU也类似于具有高数值强度(数学运算与存储器访问的比率)的算法。具有低数字强度的算法(如添加两个向量)可以是大规模并行和SIMD,但仍然在CPU上比CPU运行速度慢,因为它们'重新记忆。

nrerum

赞同来自:

我们正在尝试将bzip2移植到CUDA。 :)到目前为止(只进行了粗略的测试),我们的Burrows-Wheeler变换比串行算法快30%。 http://bzip2.github.com

desse

赞同来自:

我们已经完成了第一阶段的研究,以提高无损数据压缩算法的性能。 选择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

lvero

赞同来自:

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级网络的障碍,问题在于是否花费更多的网络或压缩功能...... :)