有谁知道使用 NVIDIA 的CUDA 库实现标准压缩方法（如 Zip、GZip、BZip2、LZMA...）的项目？
我想知道可以利用大量并行任务（如压缩）的算法在显卡上的运行速度是否不会比双核或四核 CPU 快得多。
您如何看待这种方法的利弊？
Peter
问问题
43594 次
6 回答
53
我们已经完成了第一阶段的研究，以提高无损数据压缩算法的性能。选择 Bzip2 作为原型，我们的团队只优化了一项操作 - Burrows-Wheeler 转换，我们得到了一些结果：在良好的可压缩文件上速度提高了 2 到 4 倍。该代码在我们所有的测试中运行得更快。
我们将完成 bzip2，支持 deflate 和 LZMA 以完成一些现实生活中的任务，例如：HTTP 流量和备份压缩。
博客链接： http ://www.wave-access.com/public_en/blog/2011/april/22/breakthrough-in-cuda-data-compression.aspx
于 2011-04-22T16:46:23.143 回答
48
不知道有人这样做并将其公开。只是恕我直言，这听起来不太有希望。
正如 Martinus 所指出的，一些压缩算法是高度串行的。像 LZW 这样的块压缩算法可以通过独立编码每个块来并行化。压缩大型文件树可以在文件级别并行化。
但是，这些都不是真正的 SIMD 式并行（单指令多数据），而且它们不是大规模并行的。
GPU 基本上是矢量处理器，您可以在其中执行数百或数千条 ADD 指令，所有这些指令都在同步执行，并在很少有数据相关分支的情况下执行程序。
一般来说，压缩算法听起来更像是 SPMD（单程序多数据）或 MIMD（多指令多数据）编程模型，更适合多核 CPU。
视频压缩算法可以通过像 CUDA 这样的 GPGPU 处理来加速，只有在有大量像素块被并行进行余弦变换或卷积（用于运动检测）的情况下，IDCT 或卷积子程序可以表示为使用无分支代码。
GPU 还喜欢具有高数值强度（数学运算与内存访问的比率）的算法。具有低数值强度的算法（例如添加两个向量）可以大规模并行和 SIMD，但在 gpu 上的运行速度仍然比 cpu 慢，因为它们'被记忆束缚。
于 2009-01-20T22:41:39.713 回答
8
通常压缩算法不能利用并行任务，使算法高度可并行化并不容易。在您的示例中，TAR 不是压缩算法，唯一可能高度并行化的算法是 BZIP，因为它是块压缩算法。每个块都可以单独压缩，但这需要大量的内存。LZMA 也不能并行工作，当您看到 7zip 使用多个线程时，这是因为 7zip 将数据流分成 2 个不同的流，每个流在单独的线程中用 LZMA 压缩，因此压缩算法本身不是并行的。这种拆分仅在数据允许时才有效。
于 2009-01-19T08:04:27.987 回答
2
加密算法在这方面已经相当成功，所以你可能想研究一下。这是一篇与 CUDA 和 AES 加密相关的论文：http://www.manavski.com/downloads/PID505889.pdf
于 2009-01-19T08:32:02.330 回答
1
我们正在尝试将 bzip2 移植到 CUDA。:) 到目前为止（并且只进行了粗略的测试），我们的 Burrows-Wheeler 变换比串行算法快 30%。http://bzip2.github.com
于 2010-12-23T11:39:41.673 回答
1
30% 很好，但对于像备份这样的应用程序来说，这远远不够。
我的经验是，在这种情况下，平均数据流使用 gzip 进行 1.2-1.7:1 压缩，最终限制为 30-60Mb/s 的输出速率（这是在广泛的现代（大约 2010-2012 年）媒体- 高端 CPU。
这里的限制通常是数据输入 CPU 本身的速度。
不幸的是，为了让 LTO5 磁带机满意，它需要大约 160Mb/s 的原始（不可压缩）数据速率。如果输入可压缩数据，它需要更快的数据速率。
LTO 压缩显然要快得多，但效率有些低（相当于 gzip -1 - 对于大多数用途来说已经足够了）。LTO4 及以上驱动器通常内置 AES-256 加密引擎，该引擎也可以保持这些速度。
这对我来说意味着我需要 400% 或更好的改进才能认为它值得。
类似的考虑也适用于 LAN。在 30Mb/s 时，压缩是 Gb 级网络的障碍，问题是在网络或压缩上花费更多... :)
于 2012-03-05T15:58:49.490 回答