LZPM 0.02 available!

[encode]

Okay, here is a new version of LZPM. Still very draft, but it needs to be tested plus I want to make a small break in development to think more deeply on the new LZ conception and implementation details...

Enjoy anyway!



Link:
lzpm002.zip (26 KB)

[LovePimple]

Thanks Ilia!

[LovePimple]

Quick test...

A10.jpg > 832,328
AcroRd32.exe > 1,634,409
english.dic > 1,016,014
FlashMX.pdf > 3,768,244
FP.LOG > 805,204
MSO97.DLL > 2,012,007
ohs.doc > 836,949
rafale.bmp > 1,104,232
vcfiu.hlp > 726,222
world95.txt > 619,408

Total = 13,355,017 bytes


ENWIK8:

Compressed Size = 29,274,461 bytes
Compression Time = 00:03:29.360

[Black_Fox1]

LZPM 0.02 outcompresses QUAD 1.02a on my testset!

Some datas:
File_QUAD1.12__LZPM0.02
PDF - 714,908 - 709,072
PNG - 245,756 - 241,392
PPS - 644,426 - 627,749

(almost seems like the first P stands for Precompressed )

[encode]

Looks like LZPM is more powerful than QUAD 1.12 with Max mode. I've made many tests and LZPM often wins! For myself, LZPM is just further evolution of QUAD (quad2 ). But the main thing is really fast decompression. By the way, how fast LZPM works on your test, BF?

[Black_Fox1]

Looks like LZPM is more powerful than QUAD 1.12 with Max mode. Ive made many tests and LZPM often wins! For myself, LZPM is just further evolution of QUAD (quad2 ). But the main thing is really fast decompression. By the way, how fast LZPM works on your test, BF?

Outputs on my testset:
13,694,827 bytes - LZPM 0.02
13,457,607 bytes - QUAD 1.12 -x

LZPMs speed - 1,125 kB/s compression / 9,287 kB/s decompression

[encode]

Pretty cool!

Tech comparison of LZPM and QUAD

LZ layer
LZPM has much stronger LZ coder. However, it uses non-optimal parsing (Lazy Matching) and thus keeps some air in compressed files. Overall, the scheme used with LZPM must be more efficient on binary data, at the same time QUAD's approach is better for text files. Anyway, with LZPM I've made many things and finally LZPM's scheme must be better on almost files. In addition, keep in mind that LZPM still has no EXE filter. Firstly, I not included this filter to see performance of the pure engine and not to overload the source code and keep all eyes on the main compression. Secondly, in some cases the EXE filter can only hurt compression, in this case preferable to keep standalone engine.

LZ-output coding
QUAD has more stronger LZ-output encoder - order-2-0 PPM. Even without any LZ part such encoder can acheive some compression. LZPM has very simple encoder, newly designed, very fast and efficient. One important thing that LZPM is much more stable on precompressed files - simply look at A10.jpg compression results - QUAD can't compress this file, LZPM compresses it very well, compared to others programs.

Concluding, the LZPM is the future. The bright future. I very often compare my LZPM to mcomp algorithms like LZ77 and ROLZ2. LZ77 from mcomp is just some kind of clone of LZMA. What can I say, my programs becomes more and more competitive. LZPM is the proof. I can say that even at this early stage of development it outperforms many compressors - without cheating like tunable parameters, without tons of memory...
In addition, I continue playing with my LZARI - to find additional ideas and to compare the performance of pure LZ77 vs. tricky LZ77. To be honest, on some files like PAK0.PAK (QUAKE 2 resources) improved LZARI already outperforms LZPM, however, on almost files LZPM is one step ahead.

Never stop working... Never stop thinking... 24/7... Have a nice day!

[encode]

According to the Large Text Compression Benchmark, LZPM 0.02 is faster than LZMA!

LZPM 0.02 decompresses ENWIK9 within 59 seconds, at the same time LZMA decompresses it within 63 seconds.

http://cs.fit.edu/~mmahoney/compression/text.html#2545

[LovePimple]

Awesome!

[Black_Fox1]

LZPM 0.02 is faster than LZMA!

Congratz! Long live the LZPM

[encode]

<u>Hash comparison.</u>
LZPM 0.02 was used with just different hash functions.

calgary.tar
crc16: 899,480 bytes
current: 899,486 bytes
bernstein: 899,514 bytes

reaktor.exe
current: 2,249,335 bytes
bernstein: 2,249,339 bytes
crc16: 2,249,507 bytes

world95.txt
current: 619,408 bytes
crc16: 619,417 bytes
bernstein: 619,451 bytes

As you can see, current hash function does very well even compared to the ANSI CRC-16.