<div dir="ltr"><div><br><br>On Tue, Oct 31, 2017 at 12:16 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>><br>> On Mon, Oct 30, 2017 at 9:58 AM, Markus Metz<br>> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>> ...<br>> > Some more tests:<br>> > corine land cover 250 meter, relatively small, easy to compress Byte type<br>> > LZ4: 33 sec, 54 MB<br>> > ZLIB level 1: 36 sec, 39 MB<br>> > ZSTD level 3: 34 sec, 29 MB<br>> ><br>> > GMTED2010 for the corine region as float, difficult to compress<br>> > LZ4: 27 sec, 3.1 GB<br>> > ZLIB level 1: 129 sec, 2.7 GB<br>> > ZSTD level 3: 38 sec, 2.8 GB<br>> ><br>> > GMTED2010 for the corine region as integer, easy to compress but a lot of<br>> > data<br>> > LZ4: 38 sec, 1.4 GB<br>> > ZLIB level 1: 73 sec, 993 MB<br>> > ZSTD level 3: 53 sec, 982 MB<br>> ><br>> > attempting maximum compression of GMTED2010 as integer<br>> > ZLIB level 9: 735 sec, 945 MB<br>> > ZSTD level 19: 485 sec, 846 MB<br>> > BZIP2: 273 sec, 618 MB<br>> ><br>> > With easy to compress data, ZSTD is faster and compresses better than ZLIB.<br>> > With difficult to compress data (floating point), ZSTD is at least 3x faster<br>> > than ZLIB with slightly worse compression than ZLIB, but still better than<br>> > LZ4.<br>><br>> Thanks for these comparisons! Quite interesting (especially for<br>> datasets which need to be stored on expensive SSDs).<br><br></div>Also interesting for a GRASS database on a remote cloud (i.e. slow data transfer).<br><div>><br>> >> The zstd API is similar to the API of zlib/lz4/bzip2, that means adding<br>> >> zstd to GRASS could be done by cloning e.g. the GRASS interface to lz4.<br>> ><br>> > ZSTD seems to be an improvement over ZLIB: it is always faster and most of<br>> > the time compression ratio is higher. I see the biggest advantage for<br>> > difficult to compress data where ZSTD is considerably faster than ZLIB, with<br>> > similar compression. Therefore I think adding ZSTD to GRASS would be a good<br>> > idea.<br>><br>> It looks very promising (how much effort would that be?).<br></div><div><br></div><div>basically the same like for bzip2<br></div><div><br></div><div>1. add ZSTD to configure, <a href="http://config.h.in">config.h.in</a>, <a href="http://Platform.make.in">Platform.make.in</a></div><div>2. link gislib against ZSTD if requested and available</div><div>3. add the interfaces to ZSTD in a new cmprzstd.c</div><div>4. test that everything is working fine and that ZSTD in GRASS is indeed an improvement over ZLIB.<br></div><div><br></div><div>alltogether 4-5 days I guess. <br></div><div>><br>> ...looks like becoming more widespread: <a href="http://www.zstd.net">http://www.zstd.net</a><br></div><div><br></div><div>Indeed. It is also available for RHEL 7 and its derivates (important production systems) through EPEL.<br></div><div><br></div><div>Also, the authors seem to be quite confident about it, calling it Z standard, the new standard for LZ77 compression.<br></div><div><br></div><div>Markus M<br></div><div><br></div><div>><br>> markusN<br><br></div></div>