diff --git a/Makefile b/Makefile index 4d837af8..8d63928f 100644 --- a/Makefile +++ b/Makefile @@ -32,7 +32,7 @@ # ################################################################ # Version number -export VERSION := 0.3.0 +export VERSION := 0.3.1 PRGDIR = programs ZSTDDIR = lib diff --git a/NEWS b/NEWS index e8d8affa..7d67e028 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,6 @@ +v0.3.1 : +Small compression ratio improvement + v0.3 HC mode : compression levels 2-26 diff --git a/README.md b/README.md index a634fc8a..d8766656 100644 --- a/README.md +++ b/README.md @@ -13,36 +13,31 @@ For a taste of its performance, here are a few benchmark numbers from a number o |-----------------|-------|--------:|--------:| | | | MB/s | MB/s | | **zstd 0.3** |**2.858**|**280**| **670** | -| [zlib 1.2.8] -1 | 2.730 | 70 | 300 | +| [zlib] 1.2.8 -1 | 2.730 | 70 | 300 | | QuickLZ 1.5.1b6 | 2.237 | 370 | 415 | | LZO 2.06 | 2.106 | 400 | 580 | | [LZ4] r131 | 2.101 | 450 | 2100 | | Snappy 1.1.0 | 2.091 | 330 | 1100 | | LZF 3.6 | 2.077 | 200 | 560 | -[zlib 1.2.8]:http://www.zlib.net/ +[zlib]:http://www.zlib.net/ [LZ4]:http://www.lz4.org/ -Zstd can also offer stronger compression ratio at the cost of compression speed, but preserving its decompression speed. In the following test, a few compressors suitable for this scenario are selected (they offer very asymetric performance, useful when compression time has little importance). The test was completed on a Core i7-5600U @ 2.6 GHz, using [benchmark 0.6.1](http://encode.ru/threads/1266-In-memory-benchmark-with-fastest-LZSS-(QuickLZ-Snappy)-compressors?p=45217&viewfull=1#post45217), an open-source benchmark program by inikep. +Zstd can also offer stronger compression ratio at the cost of compression speed. Compression speed is highly configurable, by small increment, to fit different situations. Note however that decompression speed is preserved and remain roughly the same at all settings, a property shared by most LZ compression algorithms, such as [zlib]. The following test is run on a Core i7-3930K CPU @ 4.5GHz, using [lzbench], an open-source in-memory benchmark by inikep. -|Name | Ratio | C.speed | D.speed | -|-----------------|-------|--------:|--------:| -| | | MB/s | MB/s | -| brotli -9 | 3.729 | 4 | 340 | -| **zstd 0.3 -9** |**3.447**|**30** | **640** | -| [zlib 1.2.8] -9 | 3.133 | 10 | 300 | -| LZO 2.06 -999 | 2.790 | 1 | 560 | -| [LZ4] r131 -9 | 2.720 | 25 | 2100 | +[lzbench]:https://github.com/inikep/lzbench +Compression Ratio vs Speed | Decompression Speed +---------------------------|-------------------- +![Compression Ratio vs Speed](images/CSpeed.png "Compression Ratio vs Speed") | ![Decompression Speed](images/DSpeed.png "Decompression Speed") -[lzma]:http://www.7-zip.org/ - -Zstd compression speed is highly configurable, by small increment, to fit different situations. Its memory requirement can also be configured to fit into low-memory hardware configurations, or servers handling multiple connections/contexts in parallel. Zstd entropy stage is provided by [Huff0 and FSE, from Finite State Entrop library](https://github.com/Cyan4973/FiniteStateEntropy). -Zstd has not yet reached "stable" status. Specifically, it doesn't guarantee yet that its current compressed format will remain stable and supported in future versions. It may still change to adapt further optimizations still being investigated. That being said, the library is now pretty robust, able to withstand hazards situations, including invalid input. The library reliability has been tested using [Fuzz Testing](https://en.wikipedia.org/wiki/Fuzz_testing), with both [internal tools](programs/fuzzer.c) and [external ones](http://lcamtuf.coredump.cx/afl). Therefore, it's now safe to test Zstandard even within production environments. +Its memory requirement can also be configured to fit into low-memory hardware configurations, or servers handling multiple connections/contexts in parallel. -"Stable Format" is projected sometimes early 2016. +Zstd has not yet reached "stable format" status. It doesn't guarantee yet that its current compressed format will remain stable and supported in future versions. During this period, it can still change to adapt new optimizations still being investigated. "Stable Format" is projected sometimes early 2016. + +That being said, the library is now fairly robust, able to withstand hazards situations, including invalid inputs. The library reliability has been tested using [Fuzz Testing](https://en.wikipedia.org/wiki/Fuzz_testing), with both [internal tools](programs/fuzzer.c) and [external ones](http://lcamtuf.coredump.cx/afl). Therefore, it seems now safe to test Zstandard even within production environments. ### Branch Policy The "dev" branch is the one where all contributions will be merged before reaching "master". If you plan to propose a patch, please commit into the "dev" branch or its own feature branch. Direct commit to "master" are not permitted. diff --git a/images/CSpeed.png b/images/CSpeed.png new file mode 100644 index 00000000..6e60dbc7 Binary files /dev/null and b/images/CSpeed.png differ diff --git a/images/DSpeed.png b/images/DSpeed.png new file mode 100644 index 00000000..b252ab65 Binary files /dev/null and b/images/DSpeed.png differ diff --git a/programs/Makefile b/programs/Makefile index 3535ec5d..8332871b 100644 --- a/programs/Makefile +++ b/programs/Makefile @@ -30,7 +30,7 @@ # fullbench32: Same as fullbench, but forced to compile in 32-bits mode # ########################################################################## -VERSION?= 0.3.0 +VERSION?= 0.3.1 DESTDIR?= PREFIX ?= /usr/local