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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
