5 ms·

> So many people think SIMD is somehow about parallel computation, but to me the obvious use is small vector math with basic vector types and standard operators

> So many people think SIMD is somehow about parallel computation, but to me the obvious use is small vector math with basic vector types and standard operators. The fact that you think that indicates that you have no experience with SIMD programming or instruction sets. Using SIMD for small vector math is at best a wash, and typically a poor idea for performance. You only get significant performance benefit out of SIMD instructions when you can use vectorize an entire inner loop (moving between scalar and vector ALUs is fairly expensive on some microarchitectures), and when data arrangement and movement is arranged to maximize throughput (think SoA instead of AoS). Using SIMD for short vector math is generally moving in the opposite direction of those goals, resulting neutral to negative performance delta compared to scalar code.

ant6n 11y ago
I'm not sure what you are trying to say -- are you saying it is faster to use x87 instructions for, say, vector3d operations rather than sse?
- 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 ago
    I 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 ago
      I'm not saying they wouldn't be nice, but they would certainly encourage SIMD antipatterns.
    - tbirdz 11y ago
      You 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
phkahler 11y ago
>> Using SIMD for small vector math is at best a wash, and typically a poor idea for performance. I just want to have a vector X = [1,2,3,4] and Y = [5,6,7,8] and be able to write A = X+Y. Or for a constant k, write A += k*X. These are extremely fast when using vector operations on intrinsics (one instruction). 2,3, and 4-element vectors are so common, it makes perfect sense to support them directly in a language.

ant6n 11y ago

I'm not sure what you are trying to say -- are you saying it is faster to use x87 instructions for, say, vector3d operations rather than sse?

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 ago
  I 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 ago
    I'm not saying they wouldn't be nice, but they would certainly encourage SIMD antipatterns.
  - tbirdz 11y ago
    You 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

phkahler 11y ago

>> Using SIMD for small vector math is at best a wash, and typically a poor idea for performance. I just want to have a vector X = [1,2,3,4] and Y = [5,6,7,8] and be able to write A = X+Y. Or for a constant k, write A += k*X. These are extremely fast when using vector operations on intrinsics (one instruction). 2,3, and 4-element vectors are so common, it makes perfect sense to support them directly in a language.