CLS-FP8MT(multi tasking)
 

Another cls based on chunks as cls-rz, but this time it's mt.

Nothing to say, just set up cls.ini, you know how to use a cls.

FP8 is slow, even in store mode because it precompresses data and then compresses it, so in level 0 it just precompresses, you get better result using level 0 fp8+srep+lzma rather than srep+lzma.

You can't set up how much threads to use because cls automatically defines it. Usually it uses all threads except one.

Configuring ini file:

There is already an example inside, but this is how it's done.

cls.ini

[fp8]
Level=5
ChunkSize=64m

Enjoy!

Original fp8 homepage in encode

so did quick test on Inside with fp8mt and without it , fp8mt level 0. the rest of the setting fp8mt+srep:m3f:a2+4x4:lzma:a1:mfbt4:d1m:fb273:mc10 000:lc8
so with fp8mt is 939mb,
and without fp8mt is 995mb..

Never heard of fp8, any further info for some reading on this?

whats for FP8 ?

FP8 (Fast PAQ8) is based paq8px, technically similar to precomp.

:man you are crazy :eek::eek::D;)

what about arc.ini ?
what should it be ?

bug decompression stuck
 

so test it on mass effect 1 with fp8mt+srep+lzma...
Level=0
changing the ChunkSize improve compression
with srep+lzma only 4.03 gb
with fp8mt chunksize 64m i get 3.33gb
with fp8mt chunksize 512m i get 2.92gb

BUT in decompression it use all cpu but stuck ???
ONLY WRITE 1.5GB AND YOU CAN SEE THAT fp8 continue to use all core but the zero disk usage

does it support stdin/out?

This doesn't look like a cls bug because here everything works fine, but fp8 is crazy if you ask me. And if it isn't working, it would not use that much cpu in idle stat.

My test:
fp8 is buggy

-Stays like this and in taskmgr looks like that

So it works and it doesn't work :confused:

Good, so fp8 bugs made the cls buggy, else it works

With all that said, the results you obtained are mostly false.

@Everyone

Precompression is buggy, so it's suggested to use it as compressor instead of precompressor+compressor. pZlib+srep+fp8(level8) should be fine if fp8 doesn't mess everything up but looks like cls is fine, normal bugs are caused by fp8 itself.

:confused:
 

it not false here new quick test i done to be sure but instead of using lzma:a1:mfbt4:d1024m:fb273:mc10000:lc8 like in the first time i 'm using
fp8mt+srep:m5f:l16:c8:a0+4x4:t2:lzma:a1:mfbt4:d64m :fb273:mc10000:lc8...
you welcome to test it yourself on the game with this setting...
forgot to mention the setting this time for fp8mt
[fp8]
Level=0
ChunkSize=64m

*i will test with the same setting like the first time ChunkSize=512m and srep:m3f:a2 and lzma:a1:mfbt4:d1024m:fb273:mc10000:lc8 when i get time lzma with this setting so slow maybe tomorrow...
but i confident of results ...

You can't be sure in that way.

Use only fp8 without cls (configure arc.ini yourself :P ) to test actually

so i get error zero byte ???

the setting for arc.ini

[External compressor:fp8]
header = 0
packcmd = fp8 -1 $$arcpackedfile$$.tmp $$arcdatafile$$.tmp
unpackcmd = fp8 -d $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
datafile = $$arcdatafile$$.tmp
packedfile = $$arcpackedfile$$.tmp

i tried different fp8 but the same...

I use this is fine

[External compressor:fp8]
packcmd = fp8 -8 $$arcpackedfile$$.tmp $$arcdatafile$$.tmp
unpackcmd = fp8 -d $$arcpackedfile$$.tmp.fp8
datafile = $$arcdatafile$$.tmp
packedfile = $$arcpackedfile$$.tmp.fp8

ain't working on mass effect...