Printable View
OK, the new release is here! http://www.encode.su/images/smilies/cool.gif
This version represents a next step in LZPM's development.
Highlights:
+ Improved match index coding - now match index coded using special order-1 context
+ Pre-built model - initially, all models are initialized with some state
+ Some predictor improvements & optimizations
Have fun with the new LZPM v0.13! http://www.encode.su/images/smilies/grin.gif
http://lzpm.encode.su/
http://www.encode.su/images/smilies/pim16.png
Intel Core duo 2 E6600 2GB RAM
SFC Test
Opt 9 =12.603.519 (comp. 288,453 sec., dec. 3,298 sec.)
Opt 1= 13.113.955 (comp. 11,860 sec, dec. 2,830 sec)
MONSTER OF COMPRESSION BMP Test (14.686.020 Byte)
Opt. 1=6.905.290 (comp. 5,078 sec., dec. 1,421 sec.)
Opt. 9=6.859.111 (comp. 19,141 sec., dec. 1,452 sec.)
Hook 512 MB=5.107.672 (comp. 8,094,dec. 8,906)
Hello everyone,
thank you Ilia http://www.encode.su/images/smilies/grin.gif
Best regards!
Thanks Ilia! http://www.encode.su/images/smilies/grin.gif
Mirror: Download
Quick test...
A10.jpg > 831,312
AcroRd32.exe > 1,472,275
english.dic > 921,900
FlashMX.pdf > 3,750,539
FP.LOG > 622,723
MSO97.DLL > 1,878,005
ohs.doc > 827,489
rafale.bmp > 1,047,836
vcfiu.hlp > 681,783
world95.txt > 569,657
Total = 12,603,519 bytes
Some testing results for upcoming <u>LZPM v0.14</u>:
acrord32.exe (3,870,784 bytes)
LZPM 0.13: 1,472,275 bytes
LZPM 0.14: 1,448,081 bytes
english.dic (4,067,439 bytes)
LZPM 0.13: 921,900 bytes
LZPM 0.14: 911,174 bytes
MPTRACK.EXE (1,159,172 bytes)
LZPM 0.13: 508,079 bytes
LZPM 0.14: 499,164 bytes
Reaktor.exe (14,446,592 bytes)
LZPM 0.13: 2,057,102 bytes
LZPM 0.14: 2,013,086 bytes
pak0.pak (183,997,730 bytes)
LZPM 0.13: 89,441,693 bytes
LZPM 0.14: 87,961,456 bytes
http://www.encode.su/images/smilies/grin.gif
calgary.tar (3,152,896 bytes)
LZPM 0.13: 862,762 bytes
LZPM 0.14: 858,759 bytes
http://www.encode.su/images/smilies/pim16.png
What's already done with LZPM v0.14:
+ Added a special model for coding LZ output. My invention - we keep two models with different update rules and merge them together
+ Improved EXE-filter. A funny trick - we search for executable header within a block, and only after enable the transformation. It's cool and simple thing which in most cases can prevent address transformation for non-executable data
+ Enlarged buffer size to 32 MB
http://www.encode.su/images/smilies/pim16.png
LZPM v0.14 at almost written, I think it will be released 1st Jan 2008! http://www.encode.su/images/smilies/wink.gif
OK, now check its SFC results:
http://www.encode.su/images/smilies/pim16.pngQuote:
A10.jpg: 835,634 bytes
acrord32.exe: 1,431,018 bytes
english.dic: 902,655 bytes
FlashMX.pdf: 3,757,477 bytes
fp.log: 603,379 bytes
mso97.dll: 1,861,226 bytes
ohs.doc: 824,473 bytes
rafale.bmp: 1,050,071 bytes
vcfiu.hlp: 670,389 bytes
world95.txt: 569,964 bytes
Total: 12,506,286 bytes
Yeah. A constant better result! by the same decompression speed I hope? http://www.encode.su/images/smilies/wink.gif
In the next steps you have to do a big one to beat 7-Zip http://www.encode.su/images/smilies/cool.gif
It depends on CPU cache. New LZ output model is twice larger - 1 MB instead of 512 KB. On my machine the decompression speed is about the same. Not only the better LZ output coding makes the compression better. But also:Quote:
Originally Posted by Simon Berger
+ An improved EXE-filter
+ A larger 32 MB buffer
+ An improved parsing [!]
If I will keep such improvement rate I will! http://www.encode.su/images/smilies/cool.gifQuote:
Originally Posted by Simon Berger