Re: [Lzip-bug] bug report: 'plzip -vf9' fails to compress files over a certain size

[Erik Jan Tromp]

Hey Antonio,

I'm back again with yet another set of test results.

TL;DR version: With the latest patch, plzip is as fast as before but doesn't 
throw errors wrt threads. Full system utilization - that's what I'd hoped for. 
Kudos!

Some stats:

   test file name: tribes2-25034-i686-1_ejt.tlz
uncompressed size: 661166080 bytes
  compressed size: 485020872 bytes

plzip options used: -vf9

atom n270 w/ 1.5gb ram
system default: 2 threads
     unpatched: 21m 48s (threads: 4, 3, 2, 1)
   patched 2GB: 21m 47s (threads: 4, 3, 2)
   patched 3GB: 21m 42s (threads: 4, 3, 2)

atom d525 w/ 2gb ram
system default: 4 threads
     unpatched: 11m 14s (threads: 6, 5, 4, 3, 1)
   patched 2GB: 10m 44s (threads: 5, 4, 3, 2)
   patched 3GB: 11m 33s (threads: 6, 5, 4, 3, 2, 1)

celeron 3205u w/ 8gb ram
system default: 2 threads
     unpatched:  4m 50s (threads: 4, 3, 2, 1)
   patched 2GB:  4m 50s (threads: 4, 3, 2)
   patched 3GB:  4m 48s (threads: 4, 3, 2)

core i3 w/ 8gb ram
system default: 4 threads
     unpatched:  2m 51s (threads: 6, 5, 4, 3, 2, 1)
   patched 2GB:  3m 34s (threads: 5, 4, 3, 2, 1)
   patched 3GB:  2m 39s (threads: 6, 5, 4, 3, 2, 1)

core i7 w/ 6gb ram
system default: 8 threads
     unpatched:  1m 25s (threads: 10, 8, 7, 6, 5, 1) [1]
   patched 2GB:  2m 20s (threads: 5, 4, 3, 2, 1)
   patched 3GB:  1m 28s (threads: 7, 6, 5, 4, 3, 2, 1) [1]

[1] I used the same script as before. Unpatched, plzip trips the error handler 
(as expected), reducing the thread count until compression succeeds. With the 
latest patch, the error handler doesn't get tripped yet I see essentially the 
same time as with the unpatched version. Impressive!

Thanks for all the effort. It's much appreciated.

Kind Regards,
Erik

-- 
If I wanted to hear the pitter-patter of little feet, I'd put shoes on my cat.