On Mon, 6 Mar 2023 13:10:57 GMT, Ilya Leoshkevich <d...@openjdk.org> wrote:
>> Amit Kumar has updated the pull request incrementally with one additional >> commit since the last revision: >> >> change acc to Alan comments > >> 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. @iii-i Thank you Ilya for those details. I haven't fully caught up with them, but while you are here - In the benchmarking table, are the "compress_cpu" and the "compress_wall" too ratios of hardware compress time to software compress time for level 1 (BEST_SPEED)? ------------- PR: https://git.openjdk.org/jdk/pull/12283
