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 此数据的最佳memLevel为4,压缩数据比默认memLevel为8小12 MB(9%).对于memLevel 8,deflate块大小为16383个符号,而对于memLevel 4,放气块大小为1023个符号.一个符号是文字字节或匹配. 改进来自输入的极其规则的性质,导致规则的匹配和文字命令序列.块大小越小,出现的这些不同命令就越少,然后它们需要更少的位来对每个命令进行编码.对于memLevel 3来说,这仍然是正确的,但到那时,每个deflate块开头的代码描述的开销取消了较少的不同代码的改进.
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |