P@baebey @kaijellinghaus (and maybe @whiteblackgoose) I'd like to start getting the SIMD Revision proposal in ship shape for a rereview, seeing as we have stuff queued up for the working group meeting now but not quite enough to justify calling one.
So we settled on having Estimate APIs (which use a silk-defined algorithm for performance) and non-estimate APIs (which use a IEEE754 compliant algorithm)
I think we also settled on not focusing too much on extreme correctness in all cases so long as it's sufficiently accurate, and makes the most sense & least surprise
However, one thing that has changed since that proposal was made is that .NET 7's xplat intrinsics has landed. So we could scrap our proposals entirely and focus on making the newest platforms as fast as possible, rather than spending a lot of time making our own abstraction and bikeshedding each individual element of it.
What do you guys think?
cc @tannergooding
So we settled on having Estimate APIs (which use a silk-defined algorithm for performance) and non-estimate APIs (which use a IEEE754 compliant algorithm)
I think we also settled on not focusing too much on extreme correctness in all cases so long as it's sufficiently accurate, and makes the most sense & least surprise
However, one thing that has changed since that proposal was made is that .NET 7's xplat intrinsics has landed. So we could scrap our proposals entirely and focus on making the newest platforms as fast as possible, rather than spending a lot of time making our own abstraction and bikeshedding each individual element of it.
What do you guys think?
cc @tannergooding
Pdoes anyone actually remember how far we got on the implementation side as well?
Wthere's a tracking issue number 666
Pah, thanks
Wall API I did is "estimate" as in I didn't care about platform-specific conventions when I did them
Pyeah makes sense
Ptbf i'd rather algorithms be managed, but i do agree that we shouldn't just use an approximate algorithm without saying so. what that looks like i have no idea, but i'd imagine it'd be finding the algorithm that presents the least surprises and implementing it
Pit looks like the ones that are implemented today are pretty unobjectionable on the approximation front given they seem to be primitive operations (assuming 666 is up to date)
Wshould be up to date unless someone besides me worked on that
Wyeah I personally don't find platform-conventional API to be very important and useful
Walthough it'd be nice to have it for full completeness, but it ended up by nobody willing to finish the work :/
K
Sounds good to me.I don't remember having any estimates api implemented, but some implementations are already estimates. Might be wrong though.
Pointing out that I always felt like maths was a perfect candidate for TDD. Adding tests for everything w/ not implemented exceptions is a great way to get started imo.
Pmy main concern rn is that there's a lot of work
Pand not really anyone to do it
Pand it's work that .NET 7 already has done
Pwell, to a certain extent at least
Wdid it unify all SIMD?
Pthere are now primitive operations implemented directly on
Vector128, Vector256, etcPthings like Sin, Cos, Tan, etc we will still need to implement ourselves
Pbut these could just be extension methods tbh
WWeren't they implemented in .net 6 too?
WWasn't the problem that we wanted to have those functions for low targets?
Pnah, .NET 6 was generic maths
Pwell, in preview at least
Wbut those types existed in net 6
Pyes they did
Wand I think down to ns2.1
Pnah, they were introduced in nca3.1
Wokay
Pbut yeah those types existed
Wbut still, were they not hw accelerated?
Pwell, yes and no
Pyes in that they represented a value used in hardware accelerated stuff
Pbut no in that... you couldn't do anything at all with a
Vector128 without calling into the ISA-specific APIsPe.g. now you can do
Vector128<float> * Vector128<float>Pwhereas before you could not
Pbefore they were strictly just an interchange type
Wah I see
Wdoes it include all of those ops?
Pthe vast majority yes
Pi think one or two are missing
WI see
WCool (although a bit sad for me)
Pi know, you did some great work and i would like to keep it
Pas you're right about the lower targets
Wwe could still keep those as polyfills for low target though
Pon NS20 we have Vector<T> which, while a lot more cursed, could be used
Wbtw I also released https://github.com/WhiteBlackGoose/CodegenAnalysis
which could be used to test JIT output
just in case it's still needed
which could be used to test JIT output
just in case it's still needed
Pi think we would definitely love something like that
Pbut again we have the problem of noone to implement it