You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Therefore, there should never be any need to re-implement it.
but this is incorrect since re-implementing PartialEq::ne makes often a lot of sense for performance purposes where it can be implemented more efficiently than just !eq.
The text was updated successfully, but these errors were encountered:
Do you have an example where it is more efficient? I have had this discussion several times (and I've been on your side at the beginning). I wasn't able to actually find any example unless you already know how your runtime data is statistically laid out, at which point I believe you should not be using the comparison operators, but extra custom code.
This holds for every type for which ne can be implemented more efficiently than !eq(a, b).
One example that comes to mind for which the impact is not minimal is all the mask types in std (std::simd::m{...}) , which implement ne as a.vertical_ne(b).any(). The default implementation !eq(a,b) which after inlining is !a.vertical_eq(b).all() (note that all lanes are compared in both cases, so this wouldn't apply to vector, slices, etc.).
There are also many manual implementations of ne within std (for pretty much every std type), although I don't know the motivation for most of these. Looking at some of them I'd expect LLVM to optimize many cases, but providing a manual implementation saves LLVM from having to do any work there.
The documentation for the
partialeq_ne_impl
states:but this is incorrect since re-implementing
PartialEq::ne
makes often a lot of sense for performance purposes where it can be implemented more efficiently than just!eq
.The text was updated successfully, but these errors were encountered: