Update docs.

This commit is contained in:
Con Kolivas 2010-12-12 10:46:22 +11:00
parent 34f76fa73c
commit 28079083c1
4 changed files with 51 additions and 8 deletions

View file

@ -94,7 +94,7 @@ system and some basic working software on it. The default options on the
10GB Virtual image:
These benchmarks were done on the quad core with version 0.530
These benchmarks were done on the quad core with version 0.550
Compression Size Percentage Compress Time Decompress Time
None 10737418240 100.0
@ -102,10 +102,10 @@ gzip 2772899756 25.8 05m47s 2m46s
bzip2 2704781700 25.2 16m15s 6m19s
xz 2272322208 21.2 50m58s 3m52s
7z 2242897134 20.9 26m36s 5m41s
lrzip 1239219863 11.5 15m45s 3m07s
lrzip -M 1079682231 10.1 12m03s 2m50s
lrzip -l 1754694010 16.3 05m30s 2m23s
lrzip -lM 1414958844 13.2 04m38s 2m20s
lrzip 1372218189 12.8 11m03s 3m43s
lrzip -M 1079682231 10.2 09m30s 3m02s
lrzip -l 1831906483 17.1 05m38s 3m05s
lrzip -lM 1414958844 13.2 05m24s 2m52s
lrzip -zM 1066902006 9.9 71m20s 72m0s
@ -116,7 +116,7 @@ scalability with multiple CPUs has a huge impact on compression time here,
with zpaq almost being as fast on quad core as xz is, yet producing a file
less than half the size.
What appears to be a big disappointment is actually zpaq here which takes more
than 6 times longer than lzma for a measly .2% improvement. The reason is that
than 6 times longer than lzma for a measly .3% improvement. The reason is that
most of the advantage here is achieved by the rzip first stage since there's a
lot of redundant space over huge distances on a virtual image. The -M option
which works the memory subsystem rather hard making noticeable impact on the