Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade zlib to 1.3.1 #99472

Merged
merged 4 commits into from
Mar 11, 2024
Merged

Conversation

carlossanlop
Copy link
Member

No description provided.

 "implicit-int-conversion" warning

The change to deflate.c is legal because 'len' has an upper bound of
MAX_STORED, which means it fits cleanly into a 16-bit integer. So
writing out 2x 8-bit values will not result in data loss.

The change to trees.c is legal because within this loop, 'count' is
intended to have an upper bound of 138, with the target assignment
only executing if 'count' is bounded by 4. Neither the 'count' local
in isolation nor the addition that's part of the target line is
expected to result in integer overflow. But even if it did, that's a
matter for a different warning code and doesn't impact the correctness
of the narrowing cast being considered here.

Author: Levi Broderick <[email protected]>
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

Copy link
Member

@GrabYourPitchforks GrabYourPitchforks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, modulo what appears to be a stray readme deletion. I diffed the files against the zlib repo and the only changes are what are documented in our readme file.

@carlossanlop carlossanlop merged commit e5179e7 into dotnet:main Mar 11, 2024
180 checks passed
@carlossanlop carlossanlop deleted the carlossanlop/main-zlib-131 branch March 11, 2024 20:15
@carlossanlop
Copy link
Member Author

carlossanlop commented Mar 14, 2024

@ericstj @GrabYourPitchforks @artl93

Edit: Rerunning perf in a Windows arm64 machine, I ran it in x64 and that uses zlib-intel...

@carlossanlop
Copy link
Member Author

@ericstj @GrabYourPitchforks @artl93 here are the results in Windows arm64, which actually consumes zlib (not zlib-intel). There wasn't any significant perf difference.

Note that new is top, base is bottom:

Method Commit level file Mean Error StdDev Median Min Max Ratio MannWhitney(5%) RatioSD Gen0 Allocated Alloc Ratio
Compress e5179e7 (new) Optimal alice29.txt 9,931.6 us 22.07 us 20.64 us 9,936.1 us 9,891.2 us 9,959.9 us 1.00 Same 0.00 - 8.26 KB 1.00
Compress e9e33e1 (old) Optimal alice29.txt 9,932.4 us 14.51 us 12.12 us 9,937.3 us 9,911.7 us 9,946.8 us 1.00 Base 0.00 - 8.26 KB 1.00
Decompress e5179e7 (new) Optimal alice29.txt 615.3 us 2.59 us 2.30 us 615.1 us 611.9 us 620.4 us 1.00 Same 0.01 2.5000 8.27 KB 1.00
Decompress e9e33e1 (old) Optimal alice29.txt 614.9 us 2.51 us 2.22 us 614.7 us 611.0 us 618.4 us 1.00 Base 0.00 2.5000 8.27 KB 1.00
Compress e5179e7 (new) Optimal sum 2,313.6 us 7.69 us 6.82 us 2,312.8 us 2,302.7 us 2,325.7 us 1.00 Same 0.00 - 8.26 KB 1.00
Compress e9e33e1 (old) Optimal sum 2,317.9 us 8.45 us 7.91 us 2,316.5 us 2,307.0 us 2,333.2 us 1.00 Base 0.00 - 8.26 KB 1.00
Decompress e5179e7 (new) Optimal sum 158.4 us 0.62 us 0.58 us 158.5 us 156.8 us 159.2 us 1.01 Same 0.01 3.7500 8.27 KB 1.00
Decompress e9e33e1 (old) Optimal sum 157.6 us 1.01 us 0.95 us 157.6 us 155.8 us 159.3 us 1.00 Base 0.01 3.7500 8.27 KB 1.00
Compress e5179e7 (new) Optimal TestDocument.pdf 4,182.0 us 9.11 us 8.07 us 4,179.4 us 4,169.1 us 4,198.6 us 1.00 Same 0.00 - 8.26 KB 1.00
Compress e9e33e1 (old) Optimal TestDocument.pdf 4,187.7 us 16.48 us 14.61 us 4,183.1 us 4,168.5 us 4,220.2 us 1.00 Base 0.00 - 8.26 KB 1.00
Decompress e5179e7 (new) Optimal TestDocument.pdf 476.7 us 1.28 us 1.14 us 476.6 us 474.7 us 478.8 us 1.00 Same 0.00 3.9063 8.27 KB 1.00
Decompress e9e33e1 (old) Optimal TestDocument.pdf 478.2 us 1.76 us 1.65 us 478.3 us 475.1 us 480.8 us 1.00 Base 0.00 3.9063 8.27 KB 1.00
Compress e5179e7 (new) Fastest alice29.txt 2,953.2 us 16.97 us 14.17 us 2,954.9 us 2,925.8 us 2,980.8 us 0.92 Same 0.07 - 8.26 KB 1.00
Compress e9e33e1 (old) Fastest alice29.txt 3,238.6 us 222.71 us 247.54 us 3,182.8 us 2,944.8 us 3,796.3 us 1.01 Base 0.10 - 8.26 KB 1.00
Decompress e5179e7 (new) Fastest alice29.txt 654.6 us 1.94 us 1.62 us 654.6 us 650.9 us 656.5 us 1.00 Same 0.00 2.6042 8.27 KB 1.00
Decompress e9e33e1 (old) Fastest alice29.txt 656.7 us 2.55 us 2.39 us 656.6 us 652.7 us 661.1 us 1.00 Base 0.00 2.7174 8.27 KB 1.00
Compress e5179e7 (new) Fastest sum 629.8 us 5.34 us 4.99 us 630.4 us 618.4 us 637.0 us 0.99 Same 0.01 2.5000 8.26 KB 1.00
Compress e9e33e1 (old) Fastest sum 633.6 us 7.43 us 6.95 us 634.9 us 617.1 us 641.9 us 1.00 Base 0.02 2.5000 8.26 KB 1.00
Decompress e5179e7 (new) Fastest sum 170.9 us 1.13 us 1.00 us 170.9 us 169.0 us 172.6 us 1.00 Same 0.01 3.3967 8.27 KB 1.00
Decompress e9e33e1 (old) Fastest sum 170.2 us 0.90 us 0.84 us 169.9 us 169.2 us 171.9 us 1.00 Base 0.01 4.0323 8.27 KB 1.00
Compress e5179e7 (new) Fastest TestDocument.pdf 4,057.5 us 21.44 us 20.05 us 4,061.9 us 4,024.1 us 4,090.2 us 1.00 Same 0.01 - 8.26 KB 1.00
Compress e9e33e1 (old) Fastest TestDocument.pdf 4,041.7 us 8.36 us 7.82 us 4,040.0 us 4,027.0 us 4,052.8 us 1.00 Base 0.00 - 8.26 KB 1.00
Decompress e5179e7 (new) Fastest TestDocument.pdf 481.7 us 2.11 us 1.76 us 481.4 us 479.3 us 485.8 us 1.00 Same 0.00 3.9063 8.27 KB 1.00
Decompress e9e33e1 (old) Fastest TestDocument.pdf 481.5 us 1.95 us 1.73 us 480.9 us 478.7 us 485.3 us 1.00 Base 0.00 3.9063 8.27 KB 1.00

@ericstj
Copy link
Member

ericstj commented Mar 15, 2024

Looks good. We can also double-check the results from the perf-lab since this is merged now. Looks like we have some ZLIB benchmarks that will run on more platforms. I think that's https://pvscmdupload.blob.core.windows.net/reports/allTestHistory/TestHistoryIndexIndex.html

@carlossanlop
Copy link
Member Author

Sure, I can also check those results. First I need to understand if they get executed periodically in an automated way or if I need to execute them myself manually.

Since the servicing branches are currently closed, would anyone object to merging the servicing PRs so they bake in staging until the branches open again?

@github-actions github-actions bot locked and limited conversation to collaborators Apr 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants