我理解LZ77和LZ78算法。 我读到了LZ4 here和here并找到了code for it。
这些链接描述了LZ4块格式。但如果有人可以解释(或指导我解释某些资源),那就太棒了:
答案 0 :(得分:66)
LZ4用于快速压缩,每个核心数百MB / s。它适用于您希望压缩非常便宜的应用程序:例如,您尝试使网络或磁盘格式更紧凑但无法支付费用一堆CPU压缩时间。它来自一个家庭,例如snappy和LZO。
自然比较点是zlib' DEFLATE algorithm,它使用LZ77和Huffman coding并用于gzip,.ZIP和.PNG格式,还有太多其他值得一去的地方。
这些快速压缩机的不同之处在于:
相比之下,DEFLATE获得更好的压缩效果,但压缩和解压缩速度较慢,而LZMA,bzip2,LZHAM或brotli等高压缩算法往往会采用更多时间(尽管Brotli at its faster settings can compete with zlib)。高压缩算法之间存在很多差异,但从广义上讲,它们倾向于捕获较长距离的冗余,更多地利用上下文来确定可能的字节,并使用更紧凑但更慢的方式来表达其结果在位。
LZ4HC是一种高压缩"我认为,LZ4的变体改变了上面的第1点 - 压缩器在当前数据和过去数据之间找到多个匹配,并寻找最佳匹配以确保输出很小。与LZ4相比,这可以提高压缩比率但降低压缩速度。然而,减压速度并不会受到影响,所以如果你压缩一次并且多次减压并且大部分都想要非常便宜的减压,那么LZ4HC就有意义了。
请注意,即使是快速压缩器也可能不允许一个核心饱和大量带宽,例如SSD或快速数据中心链接提供的带宽。甚至更快的压缩机具有较低的比率,有时用于temporarily pack data in RAM。 WKdm和Density是两个这样的压缩器;他们共享的一个特征是一次作用于输入的4字节机器字,而不是单个字节。有时,专用硬件可以实现非常快速的压缩,例如Samsung's Exynos chips或Intel's QuickAssist technology。
如果您对压缩超过LZ4感兴趣但CPU时间少于缩短时间,LZ4(Yann Collet)的作者写了一个名为Zstd的库;在其稳定版本Facebook posted about how they use it。它使用finite state machines而不是霍夫曼码进行熵编码;我不是这方面的专家,但至少the algorithm is described in detail in an RFC。 fastest modes of zstd现在正在以比率和速度接近LZ4。 Apple用类似的原则写了lzfse。几年前,谷歌发布了一个名为gipfeli的图书馆,尽管它似乎并没有引起太多关注。还有一些项目旨在以Zlib格式加快压缩速度,例如SLZ和patches to zlib by CloudFlare and Intel。
与最快的压缩机相比,那些" medium"打包器添加一种熵编码形式,也就是说它们利用了某些字节比其他字节更常见的方式,并且(实际上)在输出中为更常见的字节值放置了更少的位。
如果延迟而不是总CPU时间是您主要关注的问题,并且您正在压缩一个长流,则可以使用并行执行压缩的工具,例如pigz和-T
线程选项zstd命令行工具。 (那里也有various实验packers,但是它们更多地存在于速度或密度上的界限,而不是今天使用。)
因此,一般来说,您可以为不同的应用程序提供相当多的替代压缩器:LZ4(甚至更弱的内存压缩器)用于实时压缩,DEFLATE作为平衡压缩的旧标准,Zstd作为积极开发的新替代品,和brotli和其他人的高压缩。当您从LZ4转移到DEFLATE到brotli时,您需要花费更多精力来预测和编码数据,并以某种速度为代价获得更多压缩。
顺便说一句,像brotli和zstd这样的算法通常可以胜过gzip - 在给定的速度下更好地压缩,或者更快地获得相同的压缩 - 但实际上这并不是因为zlib做了任何错误的< / em>的。相反,zlib于1995年发布,并为当时的硬件做出了很好的选择:例如,当RAM cost超过现在的3,000倍时,它的32KB历史窗口才有意义。今天的CPU还可以扭转平衡,其中操作便宜/昂贵,例如难以预测的分支今天是一个更大的交易,做大量的算术相对便宜。