CentOS 6.5 x86-64上的Linux压缩工具大比拼
时间:2014-08-25 12:35 来源:linux.it.net.cn 作者:it
今年,我想为各位读者转发Gionatan Danti所写的一篇饶有意思的文章,这篇文章最先发表于其个人博客http://www.ilsistemista.net/,但愿大家也与我一样很喜欢这篇文章。
文件压缩是老把戏:最先能够压缩文章的软件之一是“SQ”,其历史可以追溯到上世纪80年代初期,而第一款广泛使用、众所周知的压缩工具恐怕非1989年发布的ZIP莫属。
换句话说,压缩文件以节省存储空间不是什么新鲜事;虽然目前TB级别的低成本磁盘提供了庞大空间,但有时压缩还是颇受欢迎,因为加密不仅缩减了存储数据所需的空间,由于减少了写入到存储子系统或从存储子系统读取的数据量,甚至还能提升输入/输出性能。如果将越来越快的处理器速度与多少停滞不前的机械磁盘性能(当然固态硬盘是另一码事)相比较,更是如此。
虽然压缩算法和软件各不一样,但我们基本上可以分成两大类:普通的无损压缩工具和专门的有损压缩工具。
后一类包括压缩系数相当高的压缩工具,只有当你想保护整个一般的信息,你又没有兴趣想准确呈现原始数据的每个比特,才通常使用它们。换句话说,你可以使用有损压缩工具,用来存储高分辨率照片或歌曲,而不是用来将压缩后的可执行文件存储到磁盘上(可执行文件需要逐个比特地完美存储),或者用来存储文本日志文件(我们不想丢失文本文件方面的信息,是吧?)。
所以,如果是一般的使用场合,无损压缩工具是不二的选择。但是面对那么多可用的压缩工具,该选择哪个是好?有时候,不同的压缩软件使用同一种基本算法,或者甚至同一种库实现方法,于是到底使用哪一种压缩工具是相对不大重要的选择。不过,在比较使用不同压缩算法的压缩工具时,选择势必是加权的选择:你看重的是高压缩比还是压缩速度?换句话说,你是需要一种速度快、压缩比低的算法,还是一种速度快,但压缩比高的算法?
我们在本文中将介绍多款基于几种不同压缩库的不同压缩工具:
•lz4:一种新的高速压缩软件和算法。
•lzop:基于快速的lzo库,实现了LZO算法。
•gzip和pigz(多线程gzip):基于zip库,实现了ZIP算法。
•bzip2和pbzip2(多线程bzip2):基于libbzip2库,实现了Burrows–Wheeler压缩方法。
•7-zip:主要(但不是完全)基于LZMA算法。
•xz:另一种基于LZMA的软件。
软件、实现、库和算法
在讲解压缩未经处理的原始数据之前,不妨先阐述一下相关术语。
无损压缩算法是一种数学算法,它定义了如何将特定的数据集缩减(压缩)成比较小的数据集,但又不丢失信息。换句话说,它需要使用比原始版本更少的比特编码信息,但又不丢失信息。要想做到有用,压缩算法必须是可逆的――它应该让我们能够还原压缩后的数据集,获得原始源数据集的精确副本。不难看到基本功能(压缩、压缩比和压缩速度)如何根源于算法本身,而不同算法的压缩结果和适应范围大不一样。
下一步就是算法实现――简而言之,用来表示压缩算法的数学行为的实际代码。这是另一个关键的步骤:比如说,向量化代码或多线程代码的速度比普通的单线程代码要快得多。
如果某种代码实现被认为足够好,它常常以一种独立的方式来封包化,形成压缩库。以一种独立的库来分化算法实现的优点在于,你可以编写好多不同的压缩软件,而不需要多次重新实现基本的算法。
最后,我们有了压缩软件本身。压缩软件提供了命令行接口(CLI)或图形用户界面(GUI),把用户和压缩库“结合”起来。
有时候,算法、库和程序有同一个名称(比如:zip)。而有时候,我们没有独立的库,但它完全是在压缩软件里面编制的。虽然这有点让人混淆,但上述内容仍然适用。
总而言之,我们的基准测试将涵盖算法、库和软件,如下所示:
测试平台和方法
基准测试在搭载如下配置的系统上进行:
•PhenomII 940处理器(四核@ 3.0 GHz,1.8 GHz北桥和6 MB三级缓存)
•8 GB DDR2-800 DRAM(双通道内存模式)
•华硕M4A78 Pro主板(采用AMD 780G + SB700芯片组)
•4只500 GB硬盘(1只西部数据绿盘,3只希捷鱼子酱),4只硬盘采用高级主机控制器接口(AHCI)模式,配置方式采用了软件RAID 10“near”布局。
•操作系统CentOS 6.5 x64
我对两种不同数据集的压缩和解压缩进行了计时:
1.含有未经压缩的CentOS 6.5 最小安装/(root)映像(/boot不包括在内)的tar文件
2.含有Linux 3.14.1稳定内核的tar文件
为了避免磁盘子系统带来的任何影响,我将两个数据集都移到了使用内存作为后备存储器的/dev/shm目录(你可以将它视作内存虚拟盘)。
如果可能,我尽量将单线程结果与多线程结果分开来。不过,7-zip似乎没有线程选择选项;默认情况下,处理器提供多少硬件线程,它就能生成多少线程。于是,我用星号(*)来标记7-zip的结果。
许多压缩工具可以进行某种调优――比如说,选择“-1”通常意味着比“-9”更快(但效果较差)的压缩。我还在适用的地方试用了这些标记。
压缩CentOS 6.5根映像文件
不妨先压缩主要含有大量可执行文件的数据集:最小的CentOS 6.5根映像文件来开始我们的分析。可执行文件和二进制文件常常可以缩减,尽管压缩低有点偏低。
如你所见,无论是压缩还是解压缩,lz4和lzop都兑现了速度很快这一承诺――不过lz4是绝对的赢家。另一方面,它们的压缩系数比较低。不过,要求它们提高压缩比(通过“-9”参数选项符),它们的速度就会大幅慢下来,并不生成明显更小的文件。
Gzip、尤其是bzip2的表现不是很好;虽然它们的压缩系列更高(3X),但它们存在性能严重下降的不足。
7-zip和xz都有非常慢的压缩速度,但有着很高的压缩比和尚可接受的解压缩速度。
切记:这些是单线程结果。可以使用一些多线程压缩软件,让拥有多核的现代处理器充分利用起来:
压缩缩放:
Pigz、pbzip2和pxz得到的结果都远胜于它们的单线程结果。不过,虽然压缩缩放常常非常好,但只有pbzip2也能够解压缩加快。
压缩linux内核3.14.1源文件
源文件是文本文件,而文本文件一般有着非常好的压缩比。不妨看一下这些压缩软件在压缩linux内核3.14.1 tar源文件时各自的表现如何:
虽然相对排名仍然一样,但我们可以看到两处区别:
1.不出所料,压缩比更高一点。
2.与上一轮测试相比,lzop在压缩时速度快得多。
现在看看多线程测试部分:
压缩缩放:
压缩缩放仍然很出色,而pxz名列末位。
结束语
从上述基准测试可以清楚地看出,每个压缩软件有其特定的使用场合:
•lz4和lzop非常适合实时压缩或近实时压缩,以非常快的速度,提供了大幅节省空间的优点。
•gzip、尤其是多线程pgiz版本,非常适合一般的使用场合:它既有相当高的压缩比,速度也不慢。
•普通的单线程bzip2表现不是非常好:压缩系数和速度都不如xz。只有出色的pbzip2多线程实现多少有所弥补。
•xz是压缩比方面明显的赢家,但它却是压缩和解压缩方面速度较慢的软件之一。如果你主要担心的是压缩比,而不是速度(比如在线存档文件下载),那么选择它不会有错。
•7zip基本上是xz的衍生版本,但它的主要实现属于窗口生态系统。在Linux下,只要使用xz,而不是7-zip。
(责任编辑:IT)
今年,我想为各位读者转发Gionatan Danti所写的一篇饶有意思的文章,这篇文章最先发表于其个人博客http://www.ilsistemista.net/,但愿大家也与我一样很喜欢这篇文章。 文件压缩是老把戏:最先能够压缩文章的软件之一是“SQ”,其历史可以追溯到上世纪80年代初期,而第一款广泛使用、众所周知的压缩工具恐怕非1989年发布的ZIP莫属。 换句话说,压缩文件以节省存储空间不是什么新鲜事;虽然目前TB级别的低成本磁盘提供了庞大空间,但有时压缩还是颇受欢迎,因为加密不仅缩减了存储数据所需的空间,由于减少了写入到存储子系统或从存储子系统读取的数据量,甚至还能提升输入/输出性能。如果将越来越快的处理器速度与多少停滞不前的机械磁盘性能(当然固态硬盘是另一码事)相比较,更是如此。 虽然压缩算法和软件各不一样,但我们基本上可以分成两大类:普通的无损压缩工具和专门的有损压缩工具。 后一类包括压缩系数相当高的压缩工具,只有当你想保护整个一般的信息,你又没有兴趣想准确呈现原始数据的每个比特,才通常使用它们。换句话说,你可以使用有损压缩工具,用来存储高分辨率照片或歌曲,而不是用来将压缩后的可执行文件存储到磁盘上(可执行文件需要逐个比特地完美存储),或者用来存储文本日志文件(我们不想丢失文本文件方面的信息,是吧?)。 所以,如果是一般的使用场合,无损压缩工具是不二的选择。但是面对那么多可用的压缩工具,该选择哪个是好?有时候,不同的压缩软件使用同一种基本算法,或者甚至同一种库实现方法,于是到底使用哪一种压缩工具是相对不大重要的选择。不过,在比较使用不同压缩算法的压缩工具时,选择势必是加权的选择:你看重的是高压缩比还是压缩速度?换句话说,你是需要一种速度快、压缩比低的算法,还是一种速度快,但压缩比高的算法? 我们在本文中将介绍多款基于几种不同压缩库的不同压缩工具: •lz4:一种新的高速压缩软件和算法。 •lzop:基于快速的lzo库,实现了LZO算法。 •gzip和pigz(多线程gzip):基于zip库,实现了ZIP算法。 •bzip2和pbzip2(多线程bzip2):基于libbzip2库,实现了Burrows–Wheeler压缩方法。 •7-zip:主要(但不是完全)基于LZMA算法。 •xz:另一种基于LZMA的软件。 软件、实现、库和算法 在讲解压缩未经处理的原始数据之前,不妨先阐述一下相关术语。 无损压缩算法是一种数学算法,它定义了如何将特定的数据集缩减(压缩)成比较小的数据集,但又不丢失信息。换句话说,它需要使用比原始版本更少的比特编码信息,但又不丢失信息。要想做到有用,压缩算法必须是可逆的――它应该让我们能够还原压缩后的数据集,获得原始源数据集的精确副本。不难看到基本功能(压缩、压缩比和压缩速度)如何根源于算法本身,而不同算法的压缩结果和适应范围大不一样。 下一步就是算法实现――简而言之,用来表示压缩算法的数学行为的实际代码。这是另一个关键的步骤:比如说,向量化代码或多线程代码的速度比普通的单线程代码要快得多。 如果某种代码实现被认为足够好,它常常以一种独立的方式来封包化,形成压缩库。以一种独立的库来分化算法实现的优点在于,你可以编写好多不同的压缩软件,而不需要多次重新实现基本的算法。 最后,我们有了压缩软件本身。压缩软件提供了命令行接口(CLI)或图形用户界面(GUI),把用户和压缩库“结合”起来。 有时候,算法、库和程序有同一个名称(比如:zip)。而有时候,我们没有独立的库,但它完全是在压缩软件里面编制的。虽然这有点让人混淆,但上述内容仍然适用。 总而言之,我们的基准测试将涵盖算法、库和软件,如下所示: 测试平台和方法 基准测试在搭载如下配置的系统上进行: •PhenomII 940处理器(四核@ 3.0 GHz,1.8 GHz北桥和6 MB三级缓存) •8 GB DDR2-800 DRAM(双通道内存模式) •华硕M4A78 Pro主板(采用AMD 780G + SB700芯片组) •4只500 GB硬盘(1只西部数据绿盘,3只希捷鱼子酱),4只硬盘采用高级主机控制器接口(AHCI)模式,配置方式采用了软件RAID 10“near”布局。 •操作系统CentOS 6.5 x64 我对两种不同数据集的压缩和解压缩进行了计时: 1.含有未经压缩的CentOS 6.5 最小安装/(root)映像(/boot不包括在内)的tar文件 2.含有Linux 3.14.1稳定内核的tar文件 为了避免磁盘子系统带来的任何影响,我将两个数据集都移到了使用内存作为后备存储器的/dev/shm目录(你可以将它视作内存虚拟盘)。 如果可能,我尽量将单线程结果与多线程结果分开来。不过,7-zip似乎没有线程选择选项;默认情况下,处理器提供多少硬件线程,它就能生成多少线程。于是,我用星号(*)来标记7-zip的结果。 许多压缩工具可以进行某种调优――比如说,选择“-1”通常意味着比“-9”更快(但效果较差)的压缩。我还在适用的地方试用了这些标记。 压缩CentOS 6.5根映像文件 不妨先压缩主要含有大量可执行文件的数据集:最小的CentOS 6.5根映像文件来开始我们的分析。可执行文件和二进制文件常常可以缩减,尽管压缩低有点偏低。
如你所见,无论是压缩还是解压缩,lz4和lzop都兑现了速度很快这一承诺――不过lz4是绝对的赢家。另一方面,它们的压缩系数比较低。不过,要求它们提高压缩比(通过“-9”参数选项符),它们的速度就会大幅慢下来,并不生成明显更小的文件。 Gzip、尤其是bzip2的表现不是很好;虽然它们的压缩系列更高(3X),但它们存在性能严重下降的不足。 7-zip和xz都有非常慢的压缩速度,但有着很高的压缩比和尚可接受的解压缩速度。 切记:这些是单线程结果。可以使用一些多线程压缩软件,让拥有多核的现代处理器充分利用起来:
压缩缩放:
Pigz、pbzip2和pxz得到的结果都远胜于它们的单线程结果。不过,虽然压缩缩放常常非常好,但只有pbzip2也能够解压缩加快。
压缩linux内核3.14.1源文件 源文件是文本文件,而文本文件一般有着非常好的压缩比。不妨看一下这些压缩软件在压缩linux内核3.14.1 tar源文件时各自的表现如何:
虽然相对排名仍然一样,但我们可以看到两处区别: 1.不出所料,压缩比更高一点。 2.与上一轮测试相比,lzop在压缩时速度快得多。 现在看看多线程测试部分:
压缩缩放:
压缩缩放仍然很出色,而pxz名列末位。 结束语 从上述基准测试可以清楚地看出,每个压缩软件有其特定的使用场合: •lz4和lzop非常适合实时压缩或近实时压缩,以非常快的速度,提供了大幅节省空间的优点。 •gzip、尤其是多线程pgiz版本,非常适合一般的使用场合:它既有相当高的压缩比,速度也不慢。 •普通的单线程bzip2表现不是非常好:压缩系数和速度都不如xz。只有出色的pbzip2多线程实现多少有所弥补。 •xz是压缩比方面明显的赢家,但它却是压缩和解压缩方面速度较慢的软件之一。如果你主要担心的是压缩比,而不是速度(比如在线存档文件下载),那么选择它不会有错。 •7zip基本上是xz的衍生版本,但它的主要实现属于窗口生态系统。在Linux下,只要使用xz,而不是7-zip。 (责任编辑:IT) |