On 11 January 2012 02:47, F i L <[email protected]> wrote: > On Tuesday, 10 January 2012 at 14:14:41 UTC, Manu wrote: > >> Just thought I might share a real-life case study today. Been a lot of >> talk >> of SIMD stuff, some people might be interested. >> >> Working on an android product today, I noticed the matrix library was >> burning a ridiculous amount of our frame time. >> The disassembly looked like pretty normal ARM float code, so rewriting a >> couple of the key routines to use the VFPU (carefully), our key device >> moved from 19fps -> 34fps (limited at 30, we can now ship). >> GalaxyS 2 is now running at 170fps, and devices we previously considered >> un-viable can now actually get a release! .. Most devices saw around >> 25-45% >> speed improvement. >> >> Imagine if all vector code throughout was using the vector hardware >> nicely, >> and not just one or 2 key functions... >> Getting the API right (intuitively encouraging proper usage and >> disallowing >> inefficient operations), it'll make a big difference! >> > > Wow, impressive difference. > > In the future, how will [your idea of] D's SIMD vector libraries effect my > math libraries? Will I simply replace: > > struct Vector4(T) { > T x, y, z, w; > } > > with something like: > > struct Vector4(T) { > __vector(T[4]) values; > } >
This is too simple an example, but yes that's basically the idea. Have some code of more complex operations? > or will std.simd automatically provide a full range of vector operations > (normalize, dot, cross, etc) like mono.simd? I can't help but hope for the > latter, even if it does make my current efforts redundant, it would > defiantly be a benefit to future D pioneers. > Yes the lib would supply standard operations, probably even a matrix type or 2.
