7-Zip LZMA Benchmark

LZMA Benchmark Description

The LZMA benchmark shows a rating in MIPS (million instructions per second). The rating value is calculated from the measured speed, and it is normalized with results of Intel Core 2 CPU with multi-threading option switched off, and measured with old version of 7-Zip.

The test data that is used for compression in that test is produced with special algorithm, that creates data stream that has some properties of real data, like text or execution code. Note that the speed of LZMA for real data can be slightly different. The data in benchmark workload is too artificial and is more random than real world data.

Compression

Compression speed strongly depends from memory (RAM) latency, Data Cache size/speed and TLB. Also it uses simple 32-bit integer instructions: "shift", "add", "multiply" and other. Out-of-Order execution feature of CPU is also important for that test.

Decompression

Decompression speed strongly depends on CPU integer operations. The most important things for that test are: branch misprediction penalty (the length of pipeline) and the latencies of 32-bit instructions ("multiply", "shift", "add" and other).

The decompression test has very high number of unpredictable branches. Note that some CPU architectures (for example, 32-bit ARM) support instructions that can be conditionally executed. So such CPUs can work without branches (and without pipeline flushing) in many cases in LZMA decompression code. And such CPUs can have some speed advantages over other architectures that don't support complex conditional execution.

Note: latest version of 7-Zip for x64 and arm64 contains optimized LZMA decoder that uses conditional move instructions instead of some of the unpredictable branches. That optimized code increases the speed of LZMA decompression in benchmark for up to 1.7 times.

Out-of-Order execution capability is not so important for LZMA Decompression.

ISA instructions, memory latency/bandwidth, IPC, SMT

The benchmark code doesn't use FPU and SSE. Most of the code is 32-bit integer code. Only some minor part in compression code uses also 64-bit integers.

The latencies of RAM/Cache are very important for compression speed.

The RAM bandwidth is not so important in single-thread compression/decompression, or if there is small number of working threads. But the RAM bandwidth can be main limiting factor for LZMA compression speed, if a big number of working threads are used.

The CPU's IPC (Instructions per cycle) rate is not very high for benchmark workloads. The estimated value of benchmark IPC is 1-2 (instructions per cycle) for modern CPU. The compression test has big number of random accesses to RAM and Data Cache. So big part of execution time the CPU waits the data from Data Cache or from RAM. The decompression test has big number of pipeline flushes after mispredicted branches and waiting for long dependency chains of instructions like 32-bit multiply. Such low IPC means that there are some unloaded CPU resources. And the CPU with SMT (Hyper-Threading) feature can load these free CPU resources using two threads. So SMT (Hyper-Threading) provides pretty big improvement in these tests.

LZMA in multithreading mode

When you specify (N*2) threads for test, the program creates N copies of LZMA encoder, and each LZMA encoder instance compresses separated block of test data. Each LZMA encoder instance creates 3 unsymmetrical execution threads: two big threads and one small thread. The total CPU load for these 3 threads can vary from 140% to 200%. To provide better CPU load during compression, we also can test the mode, where the number of benchmark threads is larger than the number of hardware threads.

Each LZMA encoder instance in multithreading mode divides the task of compression into 3 different tasks, where each task is executed in separated thread. Each of these tasks is simpler than original task, and it uses less memory. So each thread uses the data cache and TLB more effectively in multithreading mode. And LZMA encoder is slightly more effective in multithreading mode in value of "the Speed" divided to "CPU usage".

Note that there is some data traffic between 3 threads of LZMA encoder. So data exchange bandwidth via memory between CPU threads is also can be important, especially in multi-core system with big number of cores or CPUs.

All LZMA decoder threads are symmetrical and independent. So the decompression test uses all hardware threads, if the number of hardware threads is used.

LZMA results

We use benchmark results for 32 MB dictionary ("25:" line in results of console version). If 32 MB dictionary results are not available, we use the results for smaller dictionary. Most x86 tests were performed on Windows with official 7-Zip binaries. Some tests were performed in 64-bit mode. Most of the tests for other platforms were performed with p7zip compiled by GCC with speed optimization.

Note: new versions of 7-Zip provide improved performance. For example, latest versions of 7-Zip for x64 and arm64 platforms use optimized code for decompression written in assembler, so the rating results can be 1.7 times larger that with previous version of 7-Zip. But most results in the table represent measures performed with old version of 7-Zip before these optimizations. If some CPU was tested with new version of 7-Zip, there is a mark about version number of 7-Zip. If there is no version mark about version number, it was tested with version that provides the performance similar to version 7-Zip (p7zip) 16.02.

You can download binaries and source code of 7-Zip benchmark here:

7-Zip

LZMA SDK

7-Benchmark (Memlat and Pipelen)

If you have new interesting results, write about them on 7-max forum:

7-max forum