x86 compatible compression equivalent

[romulus_ut3]

Just to update on the situation, I took FD_RLT's advice and compressed everything with X64 Binaries, and used X86 Binaries for decompression, and there's visibly no changes in decompression speed whatsoever between the two, and everything worked out like a charm.

I thank each and everyone of you for your input, and also Felice2011 and RamiroCruzo, whom I have pestered via PM!

I have one last question though, what's the difference in Srep m3f and m5f? Is there an advantage in using Srep m3f over m5f?

[felice2011]

Originally Posted by romulus_ut3

I have one last question though, what's the difference in Srep m3f and m5f? Is there an advantage in using Srep m3f over m5f?

Select the help-info from the command line or the Viper and you will get all the information.

[romulus_ut3]

Originally Posted by felice2011

Select the help-info from the command line or the Viper and you will get all the information.

I did that before I posted the question.

The answer looked greek to me.

I could use the explanation in Layman's terms.

-m0: only in-memory compression (REP algorithm)
   -m1: fixed-window content-defined chunking with matches checked by VMAC
   -m2: order-1 content-defined chunking with matches checked by VMAC
   -m3: check matches by VMAC digest (compression memory = 7-8% of filesize)
   -m4: check matches by rereading old data (compression memory = 3-4% of filesize)
   -m5/-mx: rereading with byte-accurate matches (compression memory = 7-9% of filesize)
   -l: minimum LZ match length, default 0
   -c: size of hash chunk, by default as small as required to find all these LZ matches
   -aX[/Y]: alloc X bytes of those Y bits will be set per L input bytes for compression accelerator
            Y=0/1/2/4/8/16/32/64, -a0 is slowest but requires least memory
   -ia-: disable I/O acceleration to reduce memory usage (-m5* only)
   -tN: use N compression threads (only for -m1/-m2)
   -dBYTES: dictionary size for in-memory compression (REP algorithm), default 512mb
   -dhBYTES/-dcN/-dlN: size of hash / size of hash chunk / minimum match length for in-memory compression

   -m1..-m5: index-LZ - list of matches saved at the end of compressed file
   -m1f..-m5f: future-LZ - decompression dictionary will hold only future matches

I could've sworn I saw a post where someone said that using m3f gives compressors like lzma2 to achieve better ratios, though I am not a 100% certain. Pardon me if I have mistaken, as I can't really recall this correctly.