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

Unsafe floating point optimizations #217

Closed
billyb2 opened this issue Jul 17, 2021 · 5 comments
Closed

Unsafe floating point optimizations #217

billyb2 opened this issue Jul 17, 2021 · 5 comments

Comments

@billyb2
Copy link

billyb2 commented Jul 17, 2021

Hi, would it be possible to maybe have a feature gate for unsafe floating point optimizations within this crate? The ease of using SIMD vectors is really nice, and I think having the option of having the crate run even faster (at the expense of precision of course) would be a great addition.

@bitshifter
Copy link
Owner

What specific optimizations are you referring to?

@billyb2
Copy link
Author

billyb2 commented Jul 20, 2021

Anything that is in std::intrinsics::*_fast

For example:
https://doc.rust-lang.org/std/intrinsics/fn.fadd_fast.html

@bitshifter
Copy link
Owner

Generally with glam I have focussed on functionality that is in stable rust or have a clear path to stabilisation. These intrinsics are unstable and as far as I know there is no plan to stabilise them on the horizon (https://doc.rust-lang.org/beta/unstable-book/library-features/core-intrinsics.html). In general the question of how to do "fast math" in Rust is unanswered (see rust-lang/rust#21690 which has been around since 2015). This is one of the reasons I built glam around explicit SIMD usage.

At some point perhaps Rust will get fast math support, but it might not be via explicit intrinsics, e.g. it could be a function attributes that allows the compiler optimise a block by disabling IEEE compliance, who knows. Therefore this isn't something I plan to spend time on. I would consider a PR but accepting it would depend on what the maintenance burden looked like.

@billyb2
Copy link
Author

billyb2 commented Jul 28, 2021

Oh okay, I totally understand. I might later work on a PR for this, so I think I'll keep this issue open for now if that's okay.

@bitshifter
Copy link
Owner

This has been inactive for a while, closing.

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