Helping thread :)

[aswadd]

Originally Posted by PrinceGupta2000

IMOH, if u r planning to use things with freearc then go with fazip
this will give u better compression speed and u don't even need fazip.exe to decompress and even better compression speed many times

yes i'm using fazip for 4x4 Anyway it took 100% of my cpu usage & a lot of ram but it's 4/5 time faster than normal lzma & 2x faster than xz Eventually it's a multi thread tool

I just want to ask can i control the cpu usage of 4x4 ?? or even making it take less cpu & ram i can't add more than 120mb dictionary to it , any way to limit 4x4 ??

[ChronoCross]

4x4 doesn't have dict option do you mean blocks options. 4x4:b1g:lzma

[ChronoCross]

Recently i was compiled zlib_jo for test.
Compressing 1,208,218 bytes with precomp -intense0 -cn +srep+exe+delta+lzma = 1.105.920 bytes
Compressing 1,208,218 bytes with zlib_jo
+srep+exe+delta+lzma = 1.114.112 bytes
Compressing 1,208,218 bytes with 7zR\7zR.exe a -t7z -m0=reflate:x6 +srep+exe+delta+lzma = 1.019.904 bytes
Compressing 1,208,218 bytes with reflateMT.exe -process -c6 -t6 +srep+exe+delta+lzma = 692.224 bytes

so reflateMT is the best! Good work guys!

[aswadd]

Originally Posted by ChronoCross

4x4 doesn't have dict option do you mean blocks options. 4x4:b1g:lzma

no i mean it take too much ram so that I can't add a larg dictionary because there is no much free ram

lzma:a1:mfbt4:d300m:fb128:mc999:lc8

4x4:lzma:a1:mfbt4:d100m:fb128:mc999:lc8

[~MAK~]

Originally Posted by aswadd

no i mean it take too much ram so that I can't add a larg dictionary because there is no much free ram

lzma:a1:mfbt4:d300m:fb128:mc999:lc8

4x4:lzma:a1:mfbt4:d100m:fb128:mc999:lc8

Matey, as I told you, Overall if you see by system usage and decompression speed, and multi threaded wise, then I vote for xz. Its my opinion and way to see.

[Gupta]

if u going with xz then
i advise u left the Freearc and take 7zip route

[aswadd]

Originally Posted by ~MAK~

Matey, as I told you, Overall if you see by system usage and decompression speed, and multi threaded wise, then I vote for xz. Its my opinion and way to see.

yes u are right but if the dictionary won't effect so much i'll go with 4x4

[ChronoCross]

I need some help to configure pzstd for arc.ini.

[felice2011]

Originally Posted by ChronoCross

I need some help to configure pzstd for arc.ini.

what's the problem.

[ChronoCross]

i have this code:

[External compressor:pzstd]
header = 0
packcmd   = pzstd.exe $$arcdatafile$$.tmp -o $$arcpackedfile$$.tmp  {options}    
unpackcmd = pzstd.exe -d -f $$arcpackedfile$$.tmp -o $$arcdatafile$$.tmp

the thing is to use numbers of threads (-n 6) in arc.exe

-mpzstd:n 6:p:u:19

the code in arc.exe does not accept spaces and that`s is the problem because i need to write this option in arc.ini

[External compressor:pzstd]
header = 0
packcmd   = pzstd.exe $$arcdatafile$$.tmp -o $$arcpackedfile$$.tmp -n 6  {options}    
unpackcmd = pzstd.exe -d -f $$arcpackedfile$$.tmp -o $$arcdatafile$$.tmp

where i can get the source code only to chage this parameter -n (the space thing)

thanks

----------------------------------------------------------------------

Edited

Problem solved with quotation marks!

-mpzstd:"n 6":p:u:19

sorry for spend your time

[felice2011]

I have not had this problem with Cmd use, used individually or with FA support, awesome speed and good compression.

pzstd -u -22 -f -n 4 -p

[External compressor:pzstd]
;header = 0
packcmd    = pzstd --ultra -22 -f -n 8 -p $$arcdatafile$$.tmp -o $$arcpackedfile$$.tmp
unpackcmd  = pzstd -d -f -n 8 -p $$arcpackedfile$$.tmp -o $$arcdatafile$$.tmp

OK you've solved.

[aswadd]

Have anyone an idea to Multithread lzma ?? I already know 4x4 but it took 100% of the cpu so is their a way to multi thread it ?? also i saw something named lzmax64.exe have anyone idea about this ??

[mikey26]

lzma64 is hard on system resources if you dont have a decent machine.and it slow as F**K :P not worth looking at rather stick with normal lzma.
If it aint broken dont fix (stick with what works)
but by all means test new things but dont fix what works :P

[felice2011]

@aswadd ...lzmax64.exe ... is the 64 version should use all the processor cores.

Also uses this scheme, to move in the right direction for optimal settings.

a=[0|1] : ( Defaul 1 ) : Sets compressing mode

a=[0|1] : Sets compression mode: 0 = fast, 1 = normal. Default value is 1.

mf={MF_ID} : ( Defaul 1 ) : Sets Match Finder

mf={MF_ID} : Sets Match Finder for LZMA. Default method is bt4. Algorithms from hc* group don't provide a good compression ratio, but they often work pretty fast in combination with fast mode (a=0). Memory requirements depend on dictionary size (parameter "d" in table below).
             
             MF_ID 	Memory 	Description
             bt2 	d*9.5 + 4 MB 	Binary Tree with 2 bytes hashing.
             bt3 	d*11.5 + 4 MB 	Binary Tree with 3 bytes hashing.
             bt4 	d*11.5 + 4 MB 	Binary Tree with 4 bytes hashing.
             hc4 	d*7.5 + 4 MB 	Hash Chain with 4 bytes hashing.

    Note: Your operation system also needs some amount of physical memory for internal purposes. So keep at least 32MB of physical memory unused.

d={Size}[b|k|m] : ( Defaul 24 )	: Sets Dictionary size

d={Size}[b|k|m] : Sets Dictionary size for LZMA. You must specify the size in bytes, kilobytes, or megabytes. The maximum value for dictionary size is 1 GB = 2^30 bytes. Default values for LZMA are 24 (16 MB) in normal mode, 25 (32 MB) in maximum mode (-mx=7) and 26 (64 MB) in ultra mode (-mx=9). If you do not specify any symbol from the set [b|k|m], the dictionary size will be calculated as DictionarySize = 2^Size bytes. For decompressing a file compressed by LZMA method with dictionary size N, you need about N bytes of memory (RAM) available.

fb={NumFastBytes} : ( Defaul 32 ) Sets number of Fast Bytes for Deflate encoder.

fb={NumFastBytes} : Sets the number of fast bytes for the Deflate/Deflate64 encoder. It can be in the range from 3 to 258 (257 for Deflate64). Usually, a big number gives a little bit better compression ratio and a slower compression process. A large fast bytes parameter can significantly increase the compression ratio for files which contain long identical sequences of bytes.

mc={N} : ( Defaul 32 ) : Sets Number of Cycles for Match Finder

mc={N} : Sets number of cycles (passes) for match finder. It can be in range from 0 to 1000000000. Default value is (16 + number_of_fast_bytes / 2) for BT* match finders and (8 + number_of_fast_bytes / 4) for HC4 match finder. If you specify mc=0, LZMA will use default value. Usually, a big number gives a little bit better compression ratio and slower compression process. For example, mf=HC4 and mc=10000 can provide almost the same compression ratio as mf=BT4.

lc={N} : ( Defaul 32 ): Sets number of Literal Context bits - [0, 8]

lc={N} : Sets the number of literal context bits (high bits of previous literal). It can be in range from 0 to 8. Default value is 3. Sometimes lc=4 gives gain for big files.

[aswadd]

Originally Posted by mikey26

lzma64 is hard on system resources if you dont have a decent machine.and it slow as F**K :P not worth looking at rather stick with normal lzma.
If it aint broken dont fix (stick with what works)
but by all means test new things but dont fix what works :P

thnx now i'm pessimistic maybe i'll end up with xz