LZPM 0.12 is here!

[encode]

Hi all!

After some break, here is a new version of the LZPM.

What's new:
+ Added an EXE-filter
+ Changed buffer size to 16 MB
+ Changed table size to 8K
+ Some extra optimizations and tunings

Overall, this version is more practical - faster, less memory needed, and even higher compression on some files, especially on executables.

Happy testing!

Link:
http://lzpm.encode.su/

[squxe]

thanx! cool!

[Vacon]

Hello everyone,

thank you Ilia!

Best regards!

[LovePimple]

Thanks Ilia!

Mirror: Download

[Fallon]

I got it. Thanks!

[Nania Francesco]

thank you Ilia!

[LovePimple]

Quick test...

All files were compressed with LZPM v0.12 using 9 (max) setting.

A10.jpg > 832,173
AcroRd32.exe > 1,476,859
english.dic > 946,198
FlashMX.pdf > 3,753,871
FP.LOG > 628,522
MSO97.DLL > 1,882,707
ohs.doc > 828,504
rafale.bmp > 1,053,632
vcfiu.hlp > 686,031
world95.txt > 573,642

Total = 12,662,139 bytes

Nice results!

[Nania Francesco]

I am happy indeed ILIA, LZPM is indeed a great project! it needs only to improve speed of compression!

[encode]

Well, I think the catch of the LZPM is efficiency with Fast modes. With current max compression it is not so efficient - mostly, the compression gain is not so high, compared to the fast modes and speed is drastically affected. "9" is for current MAX compression - since the decompression speed is not affected it's OK. Anyway, the development in progress...

[encode]

The work on LZPM v1.13 in progress. New version introduces some serious main engine changes:
+ Index context coding. LZPM code match index with a special context. This trick gives some compression gain.
+ Pre-built model. Initially, all counters now initialized by some values. Thus at the beginning literals and small indexes have higher probability.
+ Optimized/changed counter model. Now tricky counter update gives some compression gain. In addition to that, probably, I'll change the update rule to move more non-stationary. This means LZPM will have higher binary compression, at the some cost of slightly lower text/random data compression.

Some testing results:

rate = 5 - stationary update rule
rate = 4 - more non-stationary update rule

calgary.tar, (3,152,896 bytes):
LZPM 0.12: 866,595 bytes
LZPM 0.13 (rate = 5): 862,762 bytes
LZPM 0.13 (rate = 4): 861,645 bytes

canterbury.tar, (2,799,104 bytes):
LZPM 0.12: 529,037 bytes
LZPM 0.13 (rate = 5): 525,116 bytes
LZPM 0.13 (rate = 4): 514,608 bytes [!]

Reaktor.exe, (14,446,592 bytes):
LZPM 0.12: 2,069,060 bytes
LZPM 0.13 (rate = 5): 2,057,102 bytes
LZPM 0.13 (rate = 4): 2,028,759 bytes

A10.jpg, (842,468 bytes):
LZPM 0.12: 832,173 bytes
LZPM 0.13 (rate = 5): 831,312 bytes
LZPM 0.13 (rate = 4): 839,360 bytes

world95.txt, (2,988,578 bytes):
LZPM 0.12: 573,642 bytes
LZPM 0.13 (rate = 5): 569,657 bytes
LZPM 0.13 (rate = 4): 572,685 bytes

On SFC, LZPM 0.13 with rate = 5 performs slightly better compared to with rate = 4. However, on many files rate = 4 performs notable better. Not decided yet what rate to use. Any suggestions?