4 ms·
Not the person you were replying to, but no. Basically, instead of trying to gain a bit performance out of one [x, y, z, w], you group your data so you have to
by yoklov 11y ago
Not the person you were replying to, but no.
Basically, instead of trying to gain a bit performance out of one [x, y, z, w], you group your data so you have to process all of them at once, and then you load them as [x0, x1, x2, x3], [y0, y1, y2, y3], [z0, z1, z2, z3], [w0, w1, w2, w3], and then do 4 (or 8, or 16) steps of the loop at a time.
This ends up having roughly a 4 (or 8, or 16) times speed up. More if your data wasn't already in that format, which is inherently cache friendly.
I linked this elsewhere in these comments, but here's a good overview of SIMD techniques (as well as what not to do, which is basically what you had suggested) https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...
- ant6n 11y agoI still don't get it. Doing exactly what you describe would be much easier if we had a [x, y, z, w] types built into the language. I just don't get the downside of having packed types builtin -- so far it was said that it would be faster to do some operations in scalar. If there is actually some way to express operations in scalar faster than using SIMD operations, then the compiler could probably regognize that as well and express my float32x4 operations in scalar. Like the dot product example from the linked slides. I see this line of code, and I want to write the comment as code, rather than the code: __m128 dw = _mm_mul_ps(aw, bw); // dw = aw * bw
- yoklov 11y agoI'm not saying they wouldn't be nice, but they would certainly encourage SIMD antipatterns.
- tbirdz 11y agoYou could use Agner Fog's vector class, but keep in mind that just using a vector class isn't always the best idea: http://www.agner.org/optimize/#vectorclass http://www.agner.org/optimize/#vectorclass