 |
|
|
|
[合著] 网友交流：关于ComZip压缩技术介绍
[ 2009-03-14 00:44:55 ]
引言/提要：琐碎的部分体现的是程序设计的功力，如果有10年以上的编程经验（当然不是那种简单的业务程序），软件表现方面体现出差距也就不足为奇，细节决定成败嘛。但是这个部分就真的只能够依靠自己不断的技术积累，跟武林高手需要长年累月的练功没什么两样，实在说不出什么窍门来。
关键词：压缩软件，奥林匹克，算法优化，核心技术，核心竞争力，压缩技术
网友 Storm_dragon（2009-2-13）：
ComZip不错。压缩效果不错，就是耗内存实在太大，压缩二十多张1440*900的桌面截图（108M）把1G内存都耗光了，页面文件也耗了1G多，而且进度有问题，经常最后几个百分比要无限等待下去。 另外用马尔可夫链会不会有更好的效果。
还有一个bug，如果源文件没有后缀名，那么会出现多余的压缩，比如我要压缩 tar3， 他会把同目录下的 tar3.xxx 一起压缩进去。
这软件内核不错，就是界面太粗糙，不知道面向的是什么样的用户群，如果更人性的使用界面会更好。
另外，我也是一名计算机程序爱好者，能不能透漏一下更多的技术细节（LZ77、算术编码，大概的介绍过了），或者是当初开发这个软件的资料来源，貌似中国很少有这方面的资料。
龙之梦工作室（2009-2-13）：
谢谢您对ComZip超级压缩机软件的支持！确实，只要自己实际测试一下，就会知道压缩效果的真假，但是现在仍然有很多人先入为主，一看是“国产软件”，想都不想就断言这是吹牛骗人的。
对于占用内存的情况，其实物理内存的真实占用量并不象看到的那么多。默认设置的8MB数据字典，用512MB内存的电脑就可以流畅运行。除非动用了128MB数据字典（“更强”模式），才真正用满这1GB多的内存。在帮助文档里面有这个问题的解释，链接地址：
http://www.28x28.com/index.php?id=soft_000000011#a50
至于为什么会看见ComZip占用了那么多内存，那是由于ComZip软件不是采用动态内存分配，而是直接开辟了1GB以上的静态大数组。虽然看上去很大，其实没有用到的部分是不会占据物理内存的。用静态大数组当然是为了省去动态分配内存的时间开销，可以理解为ComZip在自己的进程空间范围内，接管了Windows系统的内存分配功能，从而提高效率。这也许可以算一个技术细节吧。
更多的技术细节就不知该从何说起。为了改善ComZip的表现，我们采用了各种各样的优化方法，有点儿纷繁复杂。幸好我们之前有一些相关的技术文章发布在网站上，后面解释的时候，可以直接给出链接。
显示进度百分比方面，我们确实是根据已经压缩的部分与总长度的比值来显示的。到最后几个点等待的时间比较长，我们猜测是由于到最后需要从缓冲区写入硬盘，而写硬盘比较慢而造成的。另一个可能是电脑的内存太小了，导致拼命调用虚拟内存，频繁页面交换。我们建议目前采用2GB内存的电脑，可以流畅运行ComZip。
马尔可夫链是不是指N阶的动态预测模型，用来配合算术编码压缩的？如果是的话，ComZip已经是在用1阶马尔可夫链了。其实7-zip用到的LZMA算法，全称就是Lempel-Ziv马尔可夫链算法，而ComZip也是用算术编码压缩，跟7-zip可算是师出同门。只不过ComZip在10年前就已经进行开发，那时候7-zip还不知道在哪里，也不知道哪个软件开发得更早。或许对7-zip来说，ComZip也象是突然从地下冒出来的一样。
我们承认ComZip的人机界面是够原始的，原因是ComZip向来针对那些数以GB计的海量商业数据压缩，而不是面向个人市场。ComZip多数是跟商业机器打交道，而电脑本身对图形界面不感冒，反而是命令行自动操作脚本、XML数据接口之类的界面更适合电脑之间的通信。《关于ComZip压缩软件市场份额》一文有解释，链接地址：
http://www.28x28.com/index.php?id=tech_000000088
另一方面，我们的精力集中于压缩率、压缩速度等硬指标的提升上，而把改善界面的事情留给有兴趣的网友去完成。根据我们的授权方式，可以有第三方外挂软件做ComZip的界面，并且自己开发出来自己用是完全没有问题的，如果要分发则需要授权。具体可以看帮助文档，链接地址：
http://www.28x28.com/index.php?id=soft_000000011#a200
您提到的BUG，可能就是我们的图形界面不完善的表现。谢谢您的反映，我们具体检查一下，有BUG的话会修改掉。其实您也可以自己开发界面程序，生成XML文件让ComZip的文本内核程序去处理。只要XML文件格式没错，ComZip就会正常压缩。
正如网站上的ComZip软件介绍所说，ComZip基于3种压缩算法：BWT、LZSS、算术编码。这些基础算法，在其它压缩软件中也是大同小异。因为基础算法要想有革命性的创新相当困难，假如真有那么重大的改进，我们工作室就会和Lempel-Ziv等前辈们齐名了，呵呵。
网上有人看见我们说ComZip是基于10年前就有的压缩算法，马上就觉得ComZip的技术过时了，显然是误解。基础的东西可不象潮流的技术概念那样容易过时，Windows 7还是基于二进制的呢，二进制够古老了吧？难道Windows 7已经过时了吗？
ComZip现在才露脸，并不等于是现在才开始开发，而是一直都有技术更新。我们知道算术编码压缩算法以前是IBM的专利，而现在算术编码的关键部分专利已经过期失效。另外BWT、LZ算法本身没有做专利保护。这样，ComZip就不存在专利侵权的问题。
事实上我们也没有特殊的资料来源，开发ComZip所用到的资料，跟现在互联网上搜索得到的，关于上述3种压缩算法的中文网页没有什么两样。可以说，各种不同的压缩软件，开发时候的起跑线是基本一样的（这里是指通用数据压缩，如果针对特定数据就会不一样，例如我们就没有找到压缩exe文件所用的BCJ过滤器的资料）。而不同软件之间的差异，说白了就是各种程序优化技巧的综合运用。哪个软件优化得更好，谁就表现更出色。
例如，ComZip用到了128MB的数据字典，比WinRAR的4MB数据字典大得多。但是大字典仅仅是提高了字符串匹配的机会，并不等于提高了压缩率。因为大字典意味着索引编码的长度也会增加，4MB需要22位索引，128MB就要27位了。如果索引本身太长，即使算术编码压缩也不能改善到理想的情况。
ComZip就采用了分级的索引，不同级别的索引有不同的长度。这就类似于CPU的L1、L2、L3 Cache，不同级别的Cache有不同的速度。我们的另一个软件“雅典娜”网页密码锁，也采用了分级索引的压缩。只不过“雅典娜”是分2级，而ComZip是分4级，最高能够支持4GB的数据字典（目前实际的数据字典容量仅达到128MB）。文章《关于数据压缩算法》介绍了分级索引的设计思想，链接地址：
http://www.28x28.com/index.php?id=tech_000000073
另一个问题就是数据字典增大了之后，怎样保持压缩速度。ComZip的数据字典128MB，是WinRAR数据字典4MB的32倍。如果ComZip还用WinRAR一模一样的压缩程序，那么压缩时间就将是WinRAR的32倍。别人1分钟可以压缩完的东西，自己要等上半个小时，谁可以接受呢？可以这样说，WinRAR在自己4MB的小块田地里面精耕细作，而ComZip家大业大，不在乎一些细小地方的得失，只有这样才可以快速完成大容量数据字典的压缩运算。具体表现就是配置文件cz.ini里面的参数sight，如果sight设置得大一些，字符串匹配的次数就多一些，压缩率提高的同时压缩速度会降低。反之，sight设得小就会压缩得快，牺牲一点压缩率。
更进一步的细节就没什么值得说的了，无非就是常规的程序代码优化，例如尽量使用寄存器，减少内存访问，尽量让数据集中一些，使CPU的Cache发挥性能等等。这些琐碎的部分体现的是程序设计的功力，如果有10年以上的编程经验（当然不是那种简单的业务程序），软件表现方面体现出差距也就不足为奇，细节决定成败嘛。但是这个部分就真的只能够依靠自己不断的技术积累，跟武林高手需要长年累月的练功没什么两样，实在说不出什么窍门来。
ComZip也是有10多年的开发积累，才形成现在这个样子。开发改进的过程中，不断进行压缩实验测试相当重要。没有这些持续不断积累的测试数据，我们不会知道索引编码怎样设计才合适，不会知道算术编码里面的衰减系数应该怎样确定，不会知道怎样编码才会运行得更快。配置文件cz.ini里面有很多参数，您可以试试调节一下，看看对压缩结果有什么影响。
对于程序优化，文章《利用计算机算法优化提高效益》可以作为参考资料，链接地址：
http://www.28x28.com/index.php?id=tech_000000010
大致情况就是这样，感谢您的支持，这是我们前进的动力！
|
|
|
相关文章：
 [合著] 网友交流：关于ComZip压缩软件市场份额 [2009-02-01]
[原创] 提升自身实力，才能安度危机 [2009-01-01]
[原创] 议刘翔退赛“阴谋论” [2008-11-06]
[原创] ComZip阵列压缩与固实压缩对比测试 [2008-10-05]
[合著] 网友交流：关于“雅典娜”软件漏洞的发现 [2008-09-30]
[合著] 网友交流：关于ComZip超级压缩机 [2008-08-10]
最新留言：
 [2014-10-16]
[2014-10-16]
[2014-06-04]
[2014-06-04]
[2013-12-08]
[2013-11-29]
|
|
|
相关链接 |
|
人次