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

Option/feature to add generics #148

Open
LoganDark opened this issue Jul 26, 2022 · 0 comments
Open

Option/feature to add generics #148

LoganDark opened this issue Jul 26, 2022 · 0 comments

Comments

@LoganDark
Copy link
Contributor

I know that one of the goals of this library was explicitly to avoid generics. But this can be more annoying than it's worth in some scenarios. I don't want to have to use macros to re-declare my entire project 2 or 4 or 8 times depending on whether I want to use f64, SIMD, or both. And I don't want to be locked into my choice and face huge find-and-replaces.

This has always been the case, it's not like it's gotten harder recently. I have used ultraviolet to great success in the past, and I'm grateful that this library exists, since I hate quaternions, and I also hate libraries like nalgebra that require a full math degree to understand.

But times have changed since this library was first written, with large improvements in the performance of const generics. This is probably what made nalgebra so slow in the past... considering it now compiles about 60% faster (!!!). This means that ultraviolet may be able to afford generics, as an optional feature.

Plus, std::simd now exists (albeit nightly-only), which allows you to not just be generic over the float type (f32 or f64), but also be generic over the number of SIMD lanes, which is extremely valuable for prototyping and performance tuning. This generalizes to all amounts of SIMD, including only one lane, allowing you to unify the SIMD and non-SIMD types.

I know from my limited testing that stackblur-iter, which can use integer SIMD, is fastest on my particular CPU when it operates on 8 lanes in parallel, but I have no idea if that would carry to ray/path tracing, which uses floating-point SIMD (and different algorithms, of course). Right now the lack of generics makes it a tedious and manual process to test the different ultraviolet SIMD types, and even then, std::simd supports up to 64 lanes and ultraviolet only has up to 8. So flexibility is lost.

So here is my formal request for you to evaluate this situation and decide if you'd be open to supporting an optional feature that adds generic types. I'm willing to draft up a PR for it, but there's no point in doing the work if you don't approve of the idea.

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

1 participant