-
Notifications
You must be signed in to change notification settings - Fork 361
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
Add SIMD flag #467
base: main
Are you sure you want to change the base?
Add SIMD flag #467
Conversation
I'm not sure why we would disable this? Most of the simd enabled crates have either runtime and or compile time checks. They should work on both non-simd and simd enabled CPUs (which a large amount of CPUs has except for some RISC which is a bit out of scope). If this becomes a requested feature we should maybe provide optional "non-simd" builds but for now we'd like to keep it as fast as possible :) |
My concern is really with |
I asked my question to the lib author: Nugine/simd#44 |
Sorry I was a bit to quick on closing it. That makes sense. We can just enable it for LLRT executable and not for the libs. However, should SIMD be opt in or opt out? 🤔 |
The author wrote some precisions that I find acceptable. I am still on the fence on what to do here, on one hand those SIMD libraries are not mainstream vs the hex, base64 ones. Most people won't have them in their lockfile. On the other hand it seems safe to use that library since it does provide a fallback. It is usually currently accepted that the best practice for a library proposing SIMD is for it to allow users to opt-in, though I really don't care. |
Let’s enable it as default and then users can opt out by disable default features. Also I suggest that we only have one SIMD flag instead of multiple. LMKWYT |
Ok will change it, the problem with one flag is that you can't enable dependencies based on another flag. |
You don't have to right? They will be dead code since we have config blocks on non-simd alternatives |
The code is fine, the problem is enabling the dependency in [features]
default = ["encoding"]
encoding = []
# ... other features not related to SIMD
simd = []
[target.'cfg(all(feature = "simd", feature = "encoding"))'.dependencies]
base64-simd = "0.8.0"
[target.'cfg(all(not(feature = "simd"), feature = "encoding"))'.dependencies]
base64 = "0.22.0" |
I see what you mean and as you mentioned it's a cargo limitation. Size wise it's fine but it will add to compile times. I'm a bit reluctant of having multiple dependencies doing the same thing but are there any other alternatives? |
Same. AFAIK the only alternative is what I have done currently with |
I will implement the separate crate like discussed, I will bundle the |
Description of changes
The runtime detection will be skipped if the fastest implementation is already available at compile-time
)If we agree this is a good idea, then I would add some CI checks to make sure we compile both variants.
If the feature system of rust was a bit better I could add only a
simd
feature, but there is currently no way to do that so I added-simd
variants.Checklist
tests/unit
and/or in Rust for my feature if neededmake fix
to format JS and apply Clippy auto fixesmake check
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.