@Tulio Magno Quites Machado Filho <tul...@ascii.art.br> there is one question I have due to the zlib-ng...
What is the difference between zlib-ng compiled with and without the `ZLIB_COMPAT=ON` option? Are there any differences in the performance, or is it only the names of the functions? I'm interested in this because I want to know why would someone use the "non-compat" zlib-ng? Are there any advantages in using it against the "compat" zlib-ng? Thanks for the information. On Wed, Aug 23, 2023 at 11:00 AM Lukas Javorsky <ljavo...@redhat.com> wrote: > In the end most of the patches were dropped the uplift wasn't worth the >> effort of maintaining them downstream, when the effort can be better >> spent getting a 10X uplift using a more modern compression >> implementation (ex zstd/lz4/lzo/etc) that isn't written with so many >> byte oriented assumptions. >> > > Yes, generally having downstream patches is not the goal we want to chase > in Fedora/RHEL. > It takes too much effort and knowledge which could be used much more > efficiently. > > And also one of the key values of Red Hat is "upstream first", so we > always propose the patches to upstream making it a win-win for both sides. > Unfortunately, zlib's upstream isn't too welcoming for complex patches > such as these, and most of them are stuck in open PR. > > That is a big plus for zlib-ng as its upstream is open for such PRs. > On the other hand, changes like these could lead to broken compatibility > which is a big concern for our products in the case of widely used > packages such as zlib. > > > > On Tue, Aug 22, 2023 at 10:26 PM Jeremy Linton <jeremy.lin...@arm.com> > wrote: > >> Hi, >> >> On 8/6/23 08:33, John Reiser wrote: >> > On 8/6/23 02:00, Peter Robinson wrote: >> >> We tried to pull some of the optimisations in some time ago to the >> >> Fedora package and they caused some issues with compatibility. >> > >> > Please provide *any* documentation! Such as: the dates the work was >> > performed, >> > the participants, the nature of the issues, the "other side" of the >> problem >> > cases (the other packages, the use cases, etc.) >> >> Waves, some of this was my fault. >> >> example bug: https://bugzilla.redhat.com/show_bug.cgi?id=1582555 >> look at the zlib rpm history you will see things like: >> >> >> https://src.fedoraproject.org/rpms/zlib/c/71a74f9c8684dd99c0e0657f53affb90a3ca3219?branch=rawhide >> >> there were a few others that were ignored, or we reverted part of the >> original set of 5 or 6 patches. The original patches were aarch64 + NEON >> optimizations, but there were a number of issues around unittests in >> various packages that zipped something then validated the results >> against a known crc/hash/etc which then failed because the hash changed, >> the size changed, padding issues, the optimized code touched valid parts >> of the buffer and tripped buffer poisoning logic, etc. >> >> Turns out zlib is old school byte oriented and any slight behavioral >> change can result in compatibility issues. The first obvious >> optimization is to increase the fetched word/matching sizes, which >> maintain binary compatibility with the zlib format/decompressor but >> results in buffer len/compressed size deltas. >> >> Of course some of these were potentially the fault of the patches, but >> you have to decide between perf or compatibility when writing these, and >> if the goal is faster, then the compatibility gets sacrificed. >> >> Bugzilla is taking its time retrieving some of the BZs that were closed >> without fixes. So you will have to search for them yourself. >> >> In the end most of the patches were dropped the uplift wasn't worth the >> effort of maintaining them downstream, when the effort can be better >> spent getting a 10X uplift using a more modern compression >> implementation (ex zstd/lz4/lzo/etc) that isn't written with so many >> byte oriented assumptions. >> >> >> >> >> > _______________________________________________ >> > devel mailing list -- devel@lists.fedoraproject.org >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > Fedora Code of Conduct: >> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> > List Archives: >> > >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > Do not reply to spam, report it: >> > https://pagure.io/fedora-infrastructure/new_issue >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > > > -- > S pozdravom/ Best regards > > Lukáš Javorský > > Software Engineer, Core service - Databases > > Red Hat <https://www.redhat.com> > > Purkyňova 115 (TPB-C) > > 612 00 Brno - Královo Pole > > ljavo...@redhat.com > <https://www.redhat.com> > -- S pozdravom/ Best regards Lukáš Javorský Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavo...@redhat.com <https://www.redhat.com>
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
