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

Implement SIMD where applicable #49

Open
olback opened this issue May 22, 2020 · 4 comments
Open

Implement SIMD where applicable #49

olback opened this issue May 22, 2020 · 4 comments
Labels
enhancement New feature or request

Comments

@olback
Copy link

olback commented May 22, 2020

What got me looking into this was the somewhat slow key generation and the related issue #29. A solution or rather, improvement would be to implement SIMD, Single Instruction Multiple Data. I found a paper by freescale semiconductor on this topic here: http://application-notes.digchip.com/314/314-66328.pdf.

Since all processors do not support the AVX/SSE/SIMD family of instructions, this would have to be implemented under a feature flag or as in the case of aes_gcm, the feature is enabled when the compiler is passed these flags:

RUSTFLAGS="-Ctarget-cpu=sandybridge -Ctarget-feature=+aes,+sse2,+sse4.1,+ssse3"

Update: What takes time during key generation is finding big primes, and that is done here: https://github.com/dignifiedquire/num-bigint/blob/master/src/bigrand.rs#L324-L371

I might take a deeper look at this when my exams are over.

@zicklag
Copy link
Contributor

zicklag commented Sep 16, 2020

I would suggest looking/asking around about the best ways to support SIMD in Rust, too, because I think there are crates that allow for determining whether or not to use SIMD at runtime based on CPU features and such.

@tarcieri
Copy link
Member

tarcieri commented Sep 16, 2020

Yes, there's a stable std::is_x86_feature_detected macro as well as the cpuid-bool cpufeatures crate. There's also a nightly-only std::is_arm_feature_detected macro. But these are only helpful after you have a SIMD backend in the first place.

Another crate to look at is packed_simd, which is an implementation of the std::simd proposal. Unfortunately, it's also nightly-only.

@dignifiedquire dignifiedquire added the enhancement New feature or request label Jul 26, 2021
@burdges
Copy link

burdges commented Nov 14, 2021

Any idea what is optimal here? We'd first want some fixed size bigint crate that avoids the Vec used by num-bigint? We'd then do SIMD support only for that crate? Or something more bespoke?

@tarcieri
Copy link
Member

We'd first want some fixed size bigint crate that avoids the Vec used by num-bigint?

This is what we wrote crypto-bigint for: https://github.com/rustcrypto/crypto-bigint

Should have another release soon, although it doesn't yet have any SIMD features.

One thing I can try to do prior to the next release is add support for loading certain sizes of big ints (it's using const generics internally, but still allows specialization around size) into SIMD registers, which will at least leave the door open for SIMD optimizations.

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

No branches or pull requests

5 participants