Cls-lzham
 

No chunking, No Temps, No external executable

Current Version: 1092018

test it on small file size decompress work will with inno with the setting that you gave lzham:b4:w24:s4:l10 decompression speed around 87 mb/s on ssd but in compression it slower than lzma...
is there other setting to make better ratio or this is the max setting for lzham,
the cls work great so far no error...

L10 is not that useful try l9, and increase window size until u get error

Increase buffer size to 16 may be, lzham really like big inputs at once

got error with 64ws

Increase it slowly slowly, there is no limit but is limited by the hardware, or maybe something i am unware of,,,,,,, lzham initialization fails for too big win size

So increments it by 1 and see how far u can get, decompression remains unaffected from Window size

Limited by memory probably, cls is x86 therefore 2GB memory limit

Cpp compilers provides tricks to use int64_t

Or maybe u r right haven't checked lzham sources may be changing int type for x86 build will run tests tomorrow

got error on 27ws
worked 1 to 26 ws

I think that's a 64-bit integer, nothing to do with architecture. That's just an integer that's constructed using 64 bits in terms of binary.

@Razor12911 please can you update the cls-zstd to the newer ver 1.3.3 (there new setting like ultra and Long Range Mode)

If u can't represent more than 4 gb in int how will u address memory space more then that

You can represent 4GB> in int. Remember, 64-bit converts to 8 bytes. Int64 takes up just 8 bytes in memory, so really you can store that much data in the integer, but when it comes to addressing memory, this is not possible. At least from my understanding.

Edit:
At least in pascal, we are told that memory addresses can be recalled by pointers. These pointers in 32-bit environment are an equivalence to a 32-bit integer because they are 4 bytes while in 64-bit, they are 8 bytes.
I'll assign 78372 to do it :)

shouldn't lzham:b512mb:w24:s4:l9 use more memory like 5gb???
it using 1gb and the ratio is worst than lzham:b4:w24:s4:l10...

@razor12911
For memory addressing processor or os prefers native integer types, 32 bit os performs bit level arithmetic to adress memory address more tha limit, and compilers stay away from this arithmetic overhead in x86 build unles told to do soo

Don't go too much high, lzham may flush data on high ram uses and can't use the redundancy and patterns from previously processed chunks