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

前端之家收集整理的这篇文章主要介绍了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.

原文链接:https://www.f2er.com/linux/394891.html

猜你在找的Linux相关文章