xz

>>20
Did you know the guy who came up with the Peace Prize also was the inventor of dynamite? It's a hypocrite prize.

>>23
Alfred Nobel didn't come up with the Peace Prize, and he invented dynamite because nitroglycerin was killing too many miners. So you're wrong on two levels.

>>24
Yeah but nitroglycerin can still be used as an explosive

>>25
Did you know that the man who invented the lie detector was also the chief engineer of ENIAC?

>>26
LIE MY ANUS

What's the difference between LZMA and LZMA2?

>>28
One LZMA.

>>28
An integer's worth of revisions and updates.

>>28
Google is hard.

Basically nothing in terms of the meat of the algorithm.

>>28
LZMA2 divides LZMA in packets. This allows:

1. Parallelization of compression and decompression (every packet can be processed in parallel, at the cost of higher memory usage and worse compression ratio)

2. Uncompressed packets, useful for data that can't be compressed (it wouldn't expand much anyway, but decompression of this kind of data used to be slow and this fixes it, as well as improving compression ratio 1% or so)

3. Limited data recovery capabilities

4. Partial flush support (end a packet and the decoder will be able to decode up to that point, no need to restart compression entirely)

5. Some added limits to ease implementations (the number of bits used for prediction is limited to 4 to limit the size of the range coder statistical context model)

The actual compression algorithm is exactly the same (and the code is fully shared between both versions). The added overhead (due to the packet division) and improvements (for incompressible data) means that in practice the compressed size is within 1% of LZMA.

As I read the xz specification, it would appear that you're expected to encapsulate each LZMA2 packet into a xz block. xz blocks allow to preprocess the data with additional filters, such as entropy reduction filters for executables which convert relative jump addresses to absolute ones.

such as entropy reduction filters for executables which convert relative jump addresses to absolute ones.
My overlays!

>>3
ACTUALLY one of the main reasons for that is that the implementation you're likely using ("XZ Utils") is terrible.

It's an ancient fork of the original LZMA code, mangled in several ways. I just did a few benchmarks using the 9.xx series of 7-Zip. In single-threaded mode, 7-Zip was already over 30% faster, and the resulting file was a hair smaller (a few bytes out of a few megabytes, probably just a different header). I tried to choose comparable settings (defaults for XZ Utils; xz+lzma2+ultra+8mb dictionary for 7-Zip). I checked that the resulting files can be decompressed by both implementations.

On top of that 7z has multithreading. Two threads are absolutely free (same memory use, same result file bit-by-bit) and provide a additional 70% speedup (at this point we've more than doubled the speed). Then you can use even more threads in exchange for more memory and less compression ratio.

Decompression is harder to benchmark since it's too fast but it seemed there wasn't much difference at all.

Don't change these.

Name:		Email:
Entire Thread Thread List