我了解LZ77和LZ78算法。我读到了关于LZ4 here和here的文章,找到了code for it。
这些链接描述了LZ4块格式。但如果有人能解释一下(或者给我一些资源解释),那就太好了:
发布于 2015-02-21 02:35:44
它非常适合您想要非常便宜的压缩的应用程序:例如,您试图使网络或磁盘上的格式更紧凑,但不能在压缩上花费大量的CPU时间。
比较的自然点是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--压缩器在当前和过去的数据之间找到多个匹配,并寻找最佳匹配,以确保输出很小。但是,解压速度不会受到影响,所以如果你只压缩一次,解压缩很多次,并且主要想要非常便宜的解压,那么LZ4HC将是有意义的。
请注意,即使是快速压缩器也可能不允许一个核心占用大量带宽,就像SSD或快速数据中心内链路所提供的那样。甚至还有速度更快、比率更低的压缩器,有时用于temporarily pack data in RAM。WKdm和Density就是两个这样的压缩器;它们的一个共同特点是一次处理输入的4字节机器字,而不是单个字节。有时,专门的硬件可以实现非常快速的压缩,比如在Samsung's Exynos chips或Intel's QuickAssist technology中。
如果您对压缩比LZ4更多的内容感兴趣,但是使用的CPU时间比deflate更少,LZ4 (Yann Collet)的作者写了一个名为Zstd的库--这是一个blog post from Facebook at its stable release,finite state machines的背景,用于对重复信息进行紧凑编码,以及一个detailed description in an RFC。它的fast modes可以在一些类似lz4的用例中工作。(此外,苹果基于类似的原则开发了lzfse,谷歌开发的gipfeli也是一个“中等”包装器。在外部世界中,这两个似乎都没有太多用处。)此外,还有两个项目旨在提供更快/更轻的放气:SLZ和patches to zlib by CloudFlare and Intel。
与最快的压缩器相比,这些“中等”打包程序添加了一种形式的熵编码,也就是说,它们利用某些字节比其他字节更常见的优势,(实际上)在输出中为更常见的字节值放置更少的位。
如果您正在压缩一个较长的流,并且使用更多内核来提高压缩速度可能会有所帮助,那么可以通过命令行工具的-T
选项(在库中)通过pigz对gzip和zstd进行并行压缩。(也有various实验性packers,但它们的存在更多的是为了突破速度或密度的界限,而不是为了今天的使用。)
因此,一般来说,你有一个非常好的不同应用程序的替代压缩器的频谱:
用于非常快速压缩的Zstd
当您从LZ4到DEFLATE再到brotli时,您需要付出更多的努力来预测和编码数据,并以一定的速度为代价获得更多的压缩。
顺便说一句,像brotli和zstd这样的算法通常比gzip性能更好--在给定的速度下压缩得更好,或者更快地获得相同的压缩效果--但这实际上并不是因为zlib做错了什么。主要的秘密可能是较新的算法可以使用更多的内存: zlib可以追溯到1995年(并缩减到1993)。当时的内存cost是现在的3,000倍,所以保留32KB的历史记录是有意义的。CPU随时间的变化也可能是一个因素:大量的算术运算(如在有限状态机中使用的)比过去相对便宜,而不可预测的if
(分支)相对更昂贵。
https://stackoverflow.com/questions/28635496
复制相似问题