Module optimath::insights

Some insight about simd, autovectorization, const generics and specialization gained from building this library

i used a lot of experimental parts of rust. this is supposed to give some feedback on how usable i feel they are and where issues remain. This library is very Type Astronaut-y so this feedback is for the bleeding edge and will not represent the average usecase.

SIMD

simd is a pain in the butt to deal with. This is true in general and specifically for rust. Luckily autovectorization is quite reliable if you try to play nicely with the compiler

packed_simd has more #[doc(hidden)] than i have fingers, especially the core defining trait, SimdArray is private, which is annoying if you want to build a library thats generic over simd.

simd is very platform dependent, so you have to choose to either just ask people to “-C target-cpu=native” or you need to provide a way to at runtime switch between implementations.

rn you can’t build your structs to suit your simd-needs bc compiler-bug/unfinishedness

Autovectorization

Autovetcorization actually works quite well, at least in my usecase. the problem is reliability. i can’t assure a loop actually gets vectorized. it is kinda similar to tail call optimization. a solution would be to have an attribute that forces optimization or fails the compile.

Const Generics

Seem quite cool to me, but severely limited by the inability to build vectors of sizes calculated at compile time. once you can do that some really nice stuff becomes possible.

Limitations are that there is no dedicated place to do const calculations on structs as you can’t have associated constants on them. that will especially be annoying if const generics need to come from the same “place/expression” to be considered equal. a workaround is to have a wrapper type that does the calculations and an inner type that stores the results. Right now that leads to the inner struct not being buildable, but i think thats the same bug that also stops calculations in array sizes.

i feel like there is some higher level concept unexpressed, a type whose size is known, but not nescesarily at compile time, kinda similar to TrustedLen.

also, slightly related, its not possible to build a completely different struct with different fields based on generics or const generics. maybe thats a good thing though.

specialization

really cool concept, have not had too many issues except some weird type inference bugs on (imo) unrelated places, but im not 100% sure those are due to specialization, could also be one of the other 10 nightly features.

whats a bit weird is having a trait that has associated types and methods taking or returning that associated type, both being default. because when writing a default implementation you can’t assume anything about the type since it could be overridden independently from the function. this is not clear from the error messages though. a solution here is to constrain the associated type by traits in the trait definition and only rely on trait methods. this does not work for return types though.

also specialization feels suspiciously like inheritance

Generic Associated Types (GAT)

there are multiple places in the library where i think GATs would have been usefull, mainly to stop combinatorial explosion of diferent vector-types and Add/Sub/Mul between them. The compiler would then on-demand be able to instanciate them into the code instead of me having to macro them.

so im looking forward to them being implemented so i can play with them a bit

The Index trait

sucks hard, cause it requires you to treturn an actual reference to something stored in the type, can’t use it to on the fly generate a view (not 100% true as there is the fat pointer trick but thats not really… documented behaviour). had the Iterator trait made the same decision rust would be in a horrible state right now.