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

Investigate System.Numerics and SIMD capable types #146

Open
paulcscharf opened this issue Jan 20, 2019 · 4 comments
Open

Investigate System.Numerics and SIMD capable types #146

paulcscharf opened this issue Jan 20, 2019 · 4 comments
Labels
discussion-needed Issue that is not ready for implementation, but still requires discussion enhancement

Comments

@paulcscharf
Copy link
Member

Since we use many of our own types, we might be able to use vector and matrix types from System.Numerics instead of OpenTK types which may result in significant speedups with calculations.

We should look into this!

@tomrijnbeek
Copy link
Member

I assume we would be using this as underlying types. Would we still support conversion to OpenTK natively in our library? Alternatively if we can cut out the actual dependencies on OpenTK, we could always consider having the conversions to OpenTK types as extension methods in Bearded.Utilities.OpenTK, making the OpenTK dependency completely optional.

@tomrijnbeek
Copy link
Member

That being said, I am not so sure whether it will be faster than OpenTK types. I've noticed they're really focusing on performance of operations of things like Vector multiplication in that library, so the only way System.Numerics would be faster is if they do some fancy stuff, which I doubt.

@paulcscharf
Copy link
Member Author

They do fancy stuff, yes, they compile to SIMD operations when available. Maybe OpenTK has doing that too, or gonna do at some point, but if so I'm not aware.

@tomrijnbeek
Copy link
Member

https://github.com/jackmott/LinqFaster

This library seems to have some optimisations for not just Linq, but also SIMD, in case that was a blocker or something we wanted to consider.

Just leaving this here so we don't lose the linq (pun intended) in the future.

@tomrijnbeek tomrijnbeek added the discussion-needed Issue that is not ready for implementation, but still requires discussion label Sep 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion-needed Issue that is not ready for implementation, but still requires discussion enhancement
Projects
None yet
Development

No branches or pull requests

2 participants