使用 Nvidia 的 CUDA 的压缩库 [关闭]答案

【问题标题】：Compression library using Nvidia's CUDA [closed]使用 Nvidia 的 CUDA 的压缩库 [关闭]
【发布时间】：2010-10-02 04:37:16
【问题描述】：

有谁知道使用 NVIDIA 的 CUDA library 实现标准压缩方法（如 Zip、GZip、BZip2、LZMA...）的项目？

我想知道可以利用大量并行任务（如压缩）的算法在显卡上的运行速度是否不会比双核或四核 CPU 快得多。

您如何看待这种方法的利弊？

【问题讨论】：

什么是 CUDAS 内存限制？ IE。 4K 到 32K 块对于并行处理数据来说太大了，gzip 可以通过不保存块之间的字典来并行压缩，这会使文件大小增加约 5%。看。以 Dictzip 为例。
本次演示侧重于 Gzip 并获得 10 倍的加速 on-demand.gputechconf.com/gtc/2014/presentations/…
github.com/adnanozsoy/CUDA_Compression 支持基于 lszz gpu 的算法，我用大文件进行了测试。与 bzip2 相比，压缩比约为 x2，经过的时间约为 bzip2 的 25%

标签： cuda compression gpgpu

【解决方案1】：

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

【讨论】：

另外一个用于在发布一年后跟进此问题。另外，您的工作看起来很有趣，谢谢
4 年过去了...我（我们所有人）想更多地了解您的项目。结果是什么？如果可以的话，我们在哪里可以找到资源？等待您的反馈
亚历山大，有什么消息吗？代码在某处可用吗？
我发现这个libbsc.com 仅供参考，我没有研究它，但它已经死了大约 7 年（它的 2019 年！）

【解决方案2】：

不知道有人这样做并将其公开。恕我直言，这听起来不太有希望。

正如 Martinus 所指出的，一些压缩算法是高度串行的。像 LZW 这样的块压缩算法可以通过独立编码每个块来并行化。压缩大型文件树可以在文件级别并行化。

但是，这些都不是真正的 SIMD 式并行（单指令多数据），而且它们不是大规模并行的。

GPU 基本上是矢量处理器，您可以在其中执行成百上千的 ADD 指令，所有这些指令都在锁步中，并在很少有数据相关分支的情况下执行程序。

一般来说，压缩算法听起来更像是 SPMD（单程序多数据）或 MIMD（多指令多数据）编程模型，更适合多核 CPU。

视频压缩算法可以通过像 CUDA 这样的 GPGPU 处理来加速，但前提是有大量的像素块正在并行进行余弦变换或卷积（用于运动检测），以及 IDCT 或卷积子例程可以用无分支代码表示。

GPU 还喜欢具有高数值强度（数学运算与内存访问的比率）的算法。具有低数值强度的算法（例如添加两个向量）可以大规模并行和 SIMD，但在 gpu 上的运行速度仍然比cpu，因为它们受内存限制。

【讨论】：

我首先想到的并行化是那些具有“大文件树”的那些，但是你提到的其他原因让我信服了，谢谢。
您能否参考测量结果，这些测量结果表明内存绑定算法（例如添加两个向量）在 GPU 上的运行速度比在 CPU 上慢？
@bene 我的措辞不正确。内存绑定算法可以在 gpu 上以同样快或更快的速度运行——大多数 gpu 具有非常高的内存带宽。具有最高有效内存带宽的处理器将更快地执行这些算法但是，如果您在 cpu 上获取数据，将其传输到 gpu（通常通过 PCIE 总线），然后进行加法，然后将数据传输回cpu，那总是会慢很多，为此构建基准非常容易。

【解决方案3】：

通常压缩算法不能利用并行任务，使算法高度可并行化并不容易。在您的示例中，TAR 不是压缩算法，唯一可能高度并行化的算法是 BZIP，因为它是块压缩算法。每个块都可以单独压缩，但这需要大量的内存。 LZMA 也不能并行工作，当您看到 7zip 使用多个线程时，这是因为 7zip 将数据流分成 2 个不同的流，每个流在单独的线程中用 LZMA 压缩，因此压缩算法本身不是并行的。这种拆分只有在数据允许的情况下才有效。

【讨论】：

【解决方案4】：

加密算法在这方面已经相当成功，所以您可能想研究一下。这里有一篇关于CUDA和AES加密的论文：http://www.manavski.com/downloads/PID505889.pdf

【讨论】：

快速浏览一下，这似乎加速了每个块的加密。需要链接块密码以避免某些类型的攻击无济于事。 en.wikipedia.org/wiki/Block_cipher_modes_of_operation
诚然，论文并没有涵盖它，但一位同事在 GPU gems 中写了一篇关于使用 shafer 代码而不是 Cuda 进行 AES 解密的论文，它涵盖了链接。不幸的是，这篇文章不在网络上。无论如何链接都可以由 GPU 处理

【解决方案5】：

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

【讨论】：

据我所知，bzip2 使用多个 CPU 内核，但不是 CUDA。链接已损坏。当前链接似乎是bzip.org

【解决方案6】：

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 级网络的障碍，问题是是在网络上花费更多还是在压缩上花费更多...... :)

【讨论】：