You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 differentultraviolet
SIMD types, and even then,std::simd
supports up to 64 lanes andultraviolet
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.
The text was updated successfully, but these errors were encountered: