- Notifications
You must be signed in to change notification settings - Fork180
Switch from adler2 to simd-adler32 crate when using miniz_oxide backend#492
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
CI fails because Clippy complains about code I didn't touch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Thanks so much! Particularly the motivation and explanation was helpful as otherwise I would have worried that adding SIMD instructions will reduce compatibility and break downstream.
Also, I have fixed the clippy warnings, including additional ones that come up withcargo clippy --all-targets.
7145603 intorust-lang:mainUh oh!
There was an error while loading.Please reload this page.
Switch over tohttps://crates.io/crates/simd-adler32 for a performance boost.
Introduces some unsafe code into the dependency tree due to the use of raw CPU intrinsics. However, this unsafe code is low risk due to the way it's structured, and the crate has also undergone extensive fuzzing.
This has been enabled in the famously risk-averse
image-pngfor a good while now, and is even enabled in the Chromium field trials on stable channel.It's worth noting that Rust v1.87 has dramatically regressed performance of lots of SIMD code relying on runtime feature etection; this negatively affected the AVX2 codepath of simd-adler32, seerust-lang/rust#142603
Which is why I didn't open this earlier.
On all other compiler versions dating back all the way to MSRV this crate is dramatically faster than adler2.