4 ms·

re: zig's SIMD vectors - I would caution you to do some proof-of-concept with some perf testing because as I understand it, these are more well suited for doing

re: zig's SIMD vectors - I would caution you to do some proof-of-concept with some perf testing because as I understand it, these are more well suited for doing bulk operations on a large array of things, rather than for modeling linear algebra. For example, if you had 100 PointA objects and 100 PointB objects and you wanted to compute the midpoint of all of them in an output array, you would use SIMD vectors to represent, e.g. 10 X values at a time, and 10 Y values at a time, and then do the math on that, rather than to represent each Point as a separate vector. But that's just something I heard, of course real world experience would be interesting to hear about.

slimsag 5y ago
Interesting to hear, thanks for the info! I imagine Zig's SIMD is still very immature, I haven't tinkered with it at all yet either - so what I said above is pure speculation about the future.
- Jasper_ 5y ago
  Yes, you really don't want SIMD types for your vec4, that's a classic mistake, you want to chop vegetables. https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...
  - pcwalton 5y ago
    I generally agree that vertical SIMD is more efficient than horizontal SIMD when both are options, but the dot product is kind of an unfair example: that's literally the worst case for horizontal SIMD. A fairer example would be something like 4x4 matrix times vector transformation, where horizontal SIMD is pretty efficient with AVX2 broadcast instructions.
    - dnautics 5y ago
      Does SSE not have a one-cycle dot product between two vector registers? I'd be surprised if it didn't.... Though not sure if zig compiles to that assembly via llvm
      - Tuna-Fish 5y ago
        ... no. And your mental model of what operations cost is a little out of whack. On the newest Intel cpus, a vector double precision multiply is 4 cycles. A horizontal add is 6 cycles. There is a single instruction dot product, which is 9 cycles. Something like a dot product for fp can only ever be 1 cycle in a cpu that has a very low clockspeed. (Or is a barrel processor or something.) There is simply too much to do.
        dnautics 5y ago
        Sorry I should have been precise and said dispatch able one per clock cycle, not latency one clock cycle. Amortized over pipelined operations with no dependencies, the net cost of such an operation is one clock cycle. Anyways I checked it, it's DPPS, and it is a 25 clock cycle latency operation, with a throughput that yields an amortized 6 clock cycle cost.
    - Jasper_ 5y ago
      Sure, but often do you do 4x4 matrix times vector? In most cases I imagine, you're going to be using a 3x4 matrix times a vec3 with implicit w=1, or a 3x3 matrix times a vec3 with implicit w=0, making the wins a lot less clear. If you want to implement 3x3 * vec3 with SIMD, then go for it, but I don't quite think that should influence your core data structure design.
      - pcwalton 5y ago
        Well, I generally think that CPU SIMD is best used for little one-off things that you don't want to bother uploading to the GPU or other accelerators, not large-scale batch data processing. Like, if your game logic is running on CPU, then you're probably running the logic for one entity at a time anyway, in which case you probably just don't have enough batch data to make good use of vertical SIMD. So horizontal SIMD is useful there. This is why Pathfinder uses horizontal SIMD, incidentally: most of the heavy number crunching is in super branchy code (e.g. clipping, or recursive de Casteljau subdivision) where there just isn't enough batch data available to make good use of vertical SIMD. Compute shader is going to be faster for any heavy-duty batch processing that is non-branchy. The game code I've written is similar. I guess I can imagine things like physics simulations where you could have a lot of batch data processing on CPU, but even then, running that on GPU is attractive…
  - AndyKelley 5y ago
    I clicked hoping for pictures of vegetables chopped in silly ways, was slightly disappointed tbh, but then stayed for the rest of the excellent presentation. 10/10
pcwalton 5y ago
Pathfinder uses horizontal SIMD everywhere (e.g. vec4 stores x/y/z/w in a single SSE register). I measured about a 10% improvement across the board when enabling SSE+SSE2+SSSE3+SSE4.2+AVX vs. using scalar instructions only. The primary wins were from operations like de Casteljau curve subdivision which are very efficient when expressed in vector operations. So, at least in this particular application, horizontal SIMD didn't make an enormous difference, but a 10% boost is nice.
wyldfire 5y ago
Which architectures backends support Zig's SIMD vector types? do they all codegen vector instructions/registers or do some arches degrade into scalar?
- dnautics 5y ago
  Pretty sure they degrade to scalar; I accidentally compiled 8x64-bit to arm and it worked just fine (maybe not as fast), even though arm only supports 2x64-bit SIMD.

slimsag 5y ago

Interesting to hear, thanks for the info! I imagine Zig's SIMD is still very immature, I haven't tinkered with it at all yet either - so what I said above is pure speculation about the future.

Jasper_ 5y ago
Yes, you really don't want SIMD types for your vec4, that's a classic mistake, you want to chop vegetables. https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...
- pcwalton 5y ago
  I generally agree that vertical SIMD is more efficient than horizontal SIMD when both are options, but the dot product is kind of an unfair example: that's literally the worst case for horizontal SIMD. A fairer example would be something like 4x4 matrix times vector transformation, where horizontal SIMD is pretty efficient with AVX2 broadcast instructions.
  - dnautics 5y ago
    Does SSE not have a one-cycle dot product between two vector registers? I'd be surprised if it didn't.... Though not sure if zig compiles to that assembly via llvm
    - Tuna-Fish 5y ago
      ... no. And your mental model of what operations cost is a little out of whack. On the newest Intel cpus, a vector double precision multiply is 4 cycles. A horizontal add is 6 cycles. There is a single instruction dot product, which is 9 cycles. Something like a dot product for fp can only ever be 1 cycle in a cpu that has a very low clockspeed. (Or is a barrel processor or something.) There is simply too much to do.
      - dnautics 5y ago
        Sorry I should have been precise and said dispatch able one per clock cycle, not latency one clock cycle. Amortized over pipelined operations with no dependencies, the net cost of such an operation is one clock cycle. Anyways I checked it, it's DPPS, and it is a 25 clock cycle latency operation, with a throughput that yields an amortized 6 clock cycle cost.
  - Jasper_ 5y ago
    Sure, but often do you do 4x4 matrix times vector? In most cases I imagine, you're going to be using a 3x4 matrix times a vec3 with implicit w=1, or a 3x3 matrix times a vec3 with implicit w=0, making the wins a lot less clear. If you want to implement 3x3 * vec3 with SIMD, then go for it, but I don't quite think that should influence your core data structure design.
    - pcwalton 5y ago
      Well, I generally think that CPU SIMD is best used for little one-off things that you don't want to bother uploading to the GPU or other accelerators, not large-scale batch data processing. Like, if your game logic is running on CPU, then you're probably running the logic for one entity at a time anyway, in which case you probably just don't have enough batch data to make good use of vertical SIMD. So horizontal SIMD is useful there. This is why Pathfinder uses horizontal SIMD, incidentally: most of the heavy number crunching is in super branchy code (e.g. clipping, or recursive de Casteljau subdivision) where there just isn't enough batch data available to make good use of vertical SIMD. Compute shader is going to be faster for any heavy-duty batch processing that is non-branchy. The game code I've written is similar. I guess I can imagine things like physics simulations where you could have a lot of batch data processing on CPU, but even then, running that on GPU is attractive…
- AndyKelley 5y ago
  I clicked hoping for pictures of vegetables chopped in silly ways, was slightly disappointed tbh, but then stayed for the rest of the excellent presentation. 10/10

pcwalton 5y ago

Pathfinder uses horizontal SIMD everywhere (e.g. vec4 stores x/y/z/w in a single SSE register). I measured about a 10% improvement across the board when enabling SSE+SSE2+SSSE3+SSE4.2+AVX vs. using scalar instructions only. The primary wins were from operations like de Casteljau curve subdivision which are very efficient when expressed in vector operations. So, at least in this particular application, horizontal SIMD didn't make an enormous difference, but a 10% boost is nice.

wyldfire 5y ago

Which architectures backends support Zig's SIMD vector types? do they all codegen vector instructions/registers or do some arches degrade into scalar?

dnautics 5y ago
Pretty sure they degrade to scalar; I accidentally compiled 8x64-bit to arm and it worked just fine (maybe not as fast), even though arm only supports 2x64-bit SIMD.