linux – 为什么gnu parallel chunking会改善gzip的压缩大小？

档案下：“意外效率部门”

前9000万个数字约占761MB,输出为：

seq 90000000

根据man parallel,它可以通过切断输入并使用不同的cpu压缩块来加速gzip的归档大文件.所以即使gzip是单线程的,这种技术也使它成为多线程的：

seq 90000000  | parallel --pipe --recend '' -k gzip -9 >bigfile.gz

在Intel Core i3-2330M(4)@ 2.2GHz上花了46秒.

管道到普通的旧gzip：

seq 90000000  | gzip -9 > bigfile2.gz

在相同的cpu上花了80秒.现在惊喜：

ls -log bigfile*.gz

输出：

-rw-rw-r-- 1 200016306 Jul  3 17:27 bigfile.gz
-rw-rw-r-- 1 200381681 Jul  3 17:30 bigfile2.gz

300K更大？这看起来不对.首先,我检查了zdiff文件是否具有相同的内容 – 是的,相同.我认为任何压缩器在连续数据流方面都会比分块数据流做得更好.为什么bigfile2.gz不比bigfile.gz小？

解决方法

原因在于,对于这种特殊的,相当不寻常的输入,较小的放气块优于较大的放气块.默认情况下,gzip使用较大的deflate块,因为这对正常输入数据最有效.并行命令通过每1 MB分解输入来强制几个较小的放气块,从而产生小的增益.虽然大多数街区的大小仍然相同.

通过在deflateInit2()中使用zlib的memLevel参数,可以为每个块设置更小的块大小,从而做得更好.在这里,我每次使用7到2的memLevel值在单个线程中压缩相同的输出,其中较小的memLevel是较小的deflate块大小(请注意,zlib在默认级别上比gzip稍微好一点)：

> 9 – 199688429
> 8 – 198554111(默认)
> 7 – 191582070
> 6 – 184880482
> 5 – 181295029
> 4 – 180137425(此输入的最佳值)
> 3 – 181176610
> 2 – 185759115

此数据的最佳memLevel为4,压缩数据比默认memLevel为8小12 MB(9％).对于memLevel 8,deflate块大小为16383个符号,而对于memLevel 4,放气块大小为1023个符号.一个符号是文字字节或匹配.

改进来自输入的极其规则的性质,导致规则的匹配和文字命令序列.块大小越小,出现的这些不同命令就越少,然后它们需要更少的位来对每个命令进行编码.对于memLevel 3来说,这仍然是正确的,但到那时,每个deflate块开头的代码描述的开销取消了较少的不同代码的改进.

zopfli是一个deflate压缩器,它优化了块大小和所选命令,并设法将其压缩为100,656,812字节.虽然花了三个半小时！使用压缩级别11使用pigz调用zopfli.