Optionally use wide crate for DCT, which adds support for ARM64, WASM and SSE2 on stable

[mcroomp]

The result is a 50% speedup for non-AVX SSE2 (default for rust x86_64). If compiling for AVX2, the code is about 20% slower than the hand-rolled AVX2 code.

The wide crate already has safe abstractions for most of the common CPU architectures, so this means we support for WASM and ARM64 Neon CPUs.

Wide works on stable.

[Shnatsel]

I like the idea!

The main drawback of wide is the lack of runtime CPU feature detection. But since that's not relevant to ARM or WASM, and this crate already has a specialized AVX2 codepath with runtime detection, this seems like a great use of the wide crate.

[Shnatsel]

There was also a prototype of RGB-YCbCr conversion using std::simd in #13, I think it can be translated to wide quite easily. I've translated it to NEON intrinsics in #24 without much trouble.

[vstroebel]

Wide is an interesting crate, especially before the stabilization of std::simd.

What bothers me about integrating it is the following version policy:
The rust-version entry may increase in any new release (major, minor, or patch)
This sound a little bit like We can change our MSRV like our underpants.

Don't get me wrong on this. I understand that creates like wide needs to be a little bit bleeding edge when it comes to rustc and I'm not against bumping requirements. Version 0.7 of jpeg-encoder will increase the MSRV and has some API breaking changes, too. But wide’s current policy is a little bit too broad for me, even for an optional feature.

Maybe we could add it as an "experimental" feature. But i'm not sure how this would interact with the "rust-version" in cargo.toml.

[Shnatsel]

MSRV bumps are no longer a concern now that our MSRV is above 1.85.

Cargo has shipped the Rust-version aware resolver and made it the default in Rust 1.85. Anyone using Rust 1.85 or later will automatically get the latest wide that works on their compiler version.

[vstroebel]

MSRV bumps are no longer a concern now that our MSRV is above 1.85.

Cargo has shipped the Rust-version aware resolver and made it the default in Rust 1.85. Anyone using Rust 1.85 or later will automatically get the latest wide that works on their compiler version.

My concerns are more of social than a technical reason.
What would happen if a critical bugfix in wide is only released for newer MSRV based versions?
If a patch release can increase the MSRV, how is it possible to apply this bugfix without changing the MSVR of jpeg-encoder and/or it's users, too.

[Shnatsel]

People who stay on older Rust compiler (e.g. Linux distributions) are already backporting critical bugfixes by themselves. They already have to do it for the Rust compiler and standard library, after all!

Speaking as a former Debian maintainer, Debian already has a sophisticated system of distro-level patches for backporting fixes to the old software versions that they ship.

[Lokathor]

So one problem is that, within Cargo's view of the universe, when the leading version number is 0 then is just "does semver with two numbers". The positions become 0.major.minor, basically. I'd love to bump wide to a 1.0, but the last time we tried someone immediately showed up with a problem or two. maybe i can try it again soon. so right now, again in cargo's view, there's basically no way to do an update without either it being a breaking change (middle value) or a compatible change that you can't hold back (third value).

But I'm with Shnatsel, people should be using resolver 3.

but if you'd like i can make another 1.0 alpha and see if anyone complains again?