On Tue, 7 Mar 2023 05:57:34 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>>> Finally, are you or someone in your team, in contact with the author(s) of >>> the custom zlib implementation >>> [iii-i/zlib@1132034](https://github.com/iii-i/zlib/commit/113203437eda67261848b14b6c80a33ff7e33d34)? >>> Would you be able to ask for their inputs on whether this (large?) >>> difference in the deflated content size expected and are there any specific >>> input (sizes) that this shows up or is it for all inputs? >> >> This can happen for any poorly compressible inputs, regardless of their >> size. Here is the calculation for the worst case: >> https://github.com/iii-i/zlib/blob/dfltcc-20230109/contrib/s390/dfltcc.h#L17 >> (TL;DR: the size can double), but, of course, we don't expect this to be >> happening often. >> >> Here are some benchmarking results: >> https://github.com/iii-i/zlib-ng/wiki/Performance-with-dfltcc-patch-applied-and-dfltcc-support-built-on-dfltcc-enabled-machine. >> The interesting data is in column `compressed_size` where `level` is 1. >> This is the hardware compressed size divided by the software compressed >> size. Most of the time it's +5-20%, in a few cases it compresses better than >> software, and only in one case (kennedy.xls) we see a big difference of +44%. >> >> P.S. Here we are compressing random data, if I read the testcase correctly >> (`rnd.nextBytes(dataIn);`), so poor results are expected. Ideally we should >> emit stored blocks, but the hardware engine does not support this at the >> moment. > >> Here are some benchmarking results: >> https://github.com/iii-i/zlib-ng/wiki/Performance-with-dfltcc-patch-applied-and-dfltcc-support-built-on-dfltcc-enabled-machine. >> The interesting data is in column `compressed_size` where `level` is 1. >> This is the hardware compressed size divided by the software compressed >> size. Most of the time it's +5-20%, in a few cases it compresses better than >> software, and only in one case (kennedy.xls) we see a big difference of +44%. >> >> P.S. Here we are compressing random data, if I read the testcase correctly >> (`rnd.nextBytes(dataIn);`), so poor results are expected. Ideally we should >> emit stored blocks, but the hardware engine does not support this at the >> moment. > > Thank you Ilya, that was helpful in understanding the current behaviour of > this custom zlib implementation. Hi @jaikiran @AlanBateman please review it.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1522702761
