Here we go
Code:
Original file(same as in past posts): 660mb
LOLZ(default+mt4 = base setting):
-: 242.73mb 7:18min
+tt1: 244.16mb 5:47min (0.6% size gain, +24% speed gain)
+tt1+mtt1: 241.39mb 6:02min !(better than mtt0 here)
+tt1+al0: 244.46mb 5:47min
+tt1+mc32: 244.17mb 5:50min
+tt1+cm0: 247.37mb 5:52min
+tt1+dto0: 244.39mb 5:24min
+tt1+fba512: 244:13mb 6:09min
+tt1+fba128: 244.15mb 6:03min
+tt1+fba32: 244.22mb 5:42min
+tt1+fba8: 244.76mb 5:52min
+tt1+fba0: 244.12mb 6:26min
+tt1+dm00: 243.63mb 5:49min
+tt1+gm11 244.28mb 5:54min
DLZ: 265.52mb
DDS test:
file1.dds(21.33mb) | ARC -m5(lzma) -> 7.29mb | ARC(&bmp) -> 6.46mb | DLZ-> 4.72mb | LOLZ -> 4.18mb
file2.dds(5.33mb) | ARC -m5(lzma) -> 4.6mb | ARC($bmp) -> 4.34mb | DLZ -> 3.77mb | LOLZ -> 3.58mb
BMP file(~5mb):
arc -m5 -> ~2mb
lolz -> ~1.5mb (+25% gain)
Ok so first of all, lolz is very stable in both output speed and compression. There doesnt seem to be anything one can do to significantly change neither. Best speed compression I was able to achieve was with combination of options but it wasnt much worth it even then. Biggest variable was
-tt parameter. I personally recommend
-mc32 -tt1 -mtt1 -mt(#) as a best set overall.
You may ask about
-mtt1 vs -mtt0. Here as you see, despite recommendations, -mtt1 gave better ratio. With -mtt0 after all you need at least 2x+ more dictionary size than block size, whereas in -mtt1 mode they can be both same. But -mtt1 have another advantage, it does what made FA -m5 so great: 4x4. And it goes further, its actually XxX fully scalable so its even better. With -mtt0 you will use same number of threads for both compression and decompression, but with -mtt1, only your system is a limit(and you can also use less for decmp than was used by packer). So lolz can decompress using all cores! Finally, thats what I call progress, unlike that crappy lzma2 replacement!
Today, you pack a game with your 4 core CPU, but in 5-10 years you come back to it and unpack it on your new 32 core cpu and you will be able to utilize all cores. And *that* is
AMAZING.
As you see lolz is also better at compressing pictures, you may consider replacing old FA's -mm $bmp with lolz($bmp=lolz). Making it specialized at compressing textures, pictures and especially dds formats make it prime choice for packing games.
But, not all is great. For starters it is significantly slower than FA -m5. Remember previous page tests:
lzma lc8: 266.57mb - 42s
This is the same file I keep testing on. Here it took almost 6 mins. Thats like.. I dont know, 8x+ slower. Compressing 22gb game took me around 3:40h from that pure lolz was around 3h I guess, decompression should be better though. Question is, is it worth it? 241.39mb vs 266.57mb =
~9.5%. That is level of zpaq I tested before. Pretty much 2 digit gain and I replicated same gain with full game compression where with FA -m5 I got it to ~9.9gb and with lolz to ~8.9gb. 10% is not bad and on some files like bmp 25% is even better. But its also slower. If you really wanted good replacement to internal FA's lzma, this may be it. Even I am going to use it, at least sometimes.
But there is one more issue, lolz doesnt(to my knowledge) support <stdio>. Call me spoiled, but all those gigabytes of game tmp files to trash my disk is horrible. I could not get unpack cls to work yet thats another problem(for me). If they can make io to work(both for packer and unpack) that would be different story. Anyway, potential is there, this is one of the better compressors out there.
Oh and I also included DLZ packer for reference. I think its great even though only single threaded. Specialized for dds and lagging only slightly behind lolz. Its only problem is that it came at the same time as lolz(to public), otherwise this could be what uharc once was. I was complaining in another thread for lack of dds compressors(msc didnt work) and now I got 2 at once, oh well
.