Denys Vlasenko wrote:
Parallel compression benchmark isn't interesting: the task is trivially
parallelizable, so the speedup will be nerly exactly proportional
to the number of CPUs.
Not exactly. Unless you also have lots of RAM to store the processed
blocks, speed is limited by the slowest blocks.
Compare one-thread xz against one-thread lzip.
This is a useless exercise because (given the same parameters) both
behave almost identically, except that lzip tends to compress a little
more. Here you have a sample (latest rc of lzip, xz is 5.0.4). Note the
time differences between the C++ and C versions of lzip in spite of
using exactly the same algorithm and being compiled with the same compiler:
gcc-4.7.2.tar 529940480
lzip -m64: 67201618, real 7m57s, user 7m22s
clzip -m64: 67201618, real 7m45s, user 7m10s
xz: 67246172, real 7m32s, user 7m30s
gmp-5.0.1.tar 12687360
lzip -9: 1643117, real 15.170s, user 14.910s
clzip -9: 1643117, real 14.384s, user 14.280s
xz -8e: 1644780, real 16.063s, user 15.940s
xz -9e: Cannot allocate memory
Note that "xz -9" won't work on my desktop computer with 512MiB of RAM,
(but it does not make a difference in this case because gmp-5.0.1.tar is
smaller than the dictionary size selected by -8). The computer from
which I am writing this has only 256MiB of RAM and does not even have xz
installed.
Note also that the benchmark page of lzip[1] does not mention xz. Lzip
is not competing against xz. I am simply trying to write the best LZMA
compressor for unix-like systems, and I don't see xz as a LZMA compressor.
I consider the xz approach an error. Tar and xz lack the communication
capabilities needed to make the filters in xz to be applied to the
correct files. The way to make an effective use of filters is including
them in an archiver program, like 7zip or zip.
[1] file:///home/internet/savannah/lzip/cvs/lzip/benchmark.txt
Regards,
Antonio.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
