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

Opt-in std::simd support #37

Open
Shnatsel opened this issue Jul 28, 2024 · 4 comments
Open

Opt-in std::simd support #37

Shnatsel opened this issue Jul 28, 2024 · 4 comments

Comments

@Shnatsel
Copy link
Contributor

The std::simd module provides a safe, portable API for SIMD. Together with the multiversion crate it allows for SIMD that works from a single source file on every platform, and entirely in safe code!

The drawback is that it is nightly-only, and still technically unstable despite not having changed in quite some time. It would be great to add support for it and expose this as an opt-in feature, e.g. nightly-portable-simd. While the platform coverage of this crate is already outstanding, this would allow people on nightly channel to use an implementation with less unsafe code.

@Cykooz
Copy link
Owner

Cykooz commented Jul 29, 2024

"Using experimental, unstable, nightly-only features to get less unsafe implementation."
That sounds a bit contradictory. 😄

I looked through std::simd a while back and didn't find some useful functions that I use in my implementation for certain SIMD instructions. For example I didn't find how to implement something like vld4_u8 instruction from NEON. This instruction loads multiple 4-element structures from memory and writes the result to the four SIMD registers, with de-interleaving.

@Shnatsel
Copy link
Contributor Author

It's not like the portable SIMD implementation is incomplete, it's just that the API stability is not guaranteed yet. That's the same situation in which TryFrom lingered for years. There's nothing unsafe about either of those APIs.

For example I didn't find how to implement something like vld4_u8 instruction from NEON.

Ah, yes, that could be a problem. There might be a pattern of several higher-level operations that the compiler will recognize and optimize down into a single instruction. Or there might not. Gotta play around with godbolt and see.

@Cykooz
Copy link
Owner

Cykooz commented Jul 29, 2024

There might be a pattern of several higher-level operations

I'm afraid there will be different patterns for different architectures. And these patterns may be unstable and change from one version of Rust to another.

I may try to do what you want, but I can't promise I'll do it soon. Right now I want to add support for multi-threading.

@Shnatsel
Copy link
Contributor Author

That's fair! I don't expect it will fully replace the existing handwritten SIMD for every platform. More like, it will provide something in between no simd at all and platform-specific unsafe intrinsics.

Thank you for considering this request!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants