-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Investigate using Span in BigInteger implementation #22609
Comments
cc @stephentoub |
If that's the only need for |
It supports this now. Span<byte> stackSpan = stackalloc byte[100]; |
Marking this as |
Proposed refactoring according with issue: dotnet/runtime#22609. The implementation plan consists of the following steps: - [x] Replace unmanaged pointers with managed ones as well as remove unsafe code and pinning - [x] Beautify stack allocation - [x] Use spans wherever possible, especially for memory slicing - [ ] Simplify (or probably remove at all) `BitsBuffer` value type - [ ] Spannify `FastReducer` value type - [ ] Attempt to replace some array allocations with span slicing - [ ] Square, Multiply and bitwise operations use heap-based allocation of arrays if their length is greater than or equal to stack allocation threshold. Maybe replace it with array pooling using shared `ArrayPool<T>`? - [ ] BMI intrinsics?? Spannified versions of internal and private static methods look pretty nice. However, I'm not sure about performance of passing span to the method. If RyuJIT uses scalar replacement then it's good news. Otherwise, maybe pass length and managed pointer to the first element as separate arguments to ensure that they passed through registers. This version was implemented in the first commit. I need advice here as well as preliminary code review because further work fully based on signatures of spannified methods. cc @tannergooding , @stephentoub
@jeffhandley , PR has been merged so maybe we can close this issue? |
Indeed! Thanks again, @sakno!! 💯 |
As already mentioned within #22387 the all-new Span should bring many benefits to BigInteger.
We cannot get grid of unsafe code completely since there are stack-vs-heap paths based on stackalloc, but all the pointer based stuff should gracefully disappear; I think.
I'm interested to dive into this, after the summer or so.
The text was updated successfully, but these errors were encountered: