6 ms·

SIMD instructions were a mistake in CPU instruction set design. Vector instructions have register size independent code which makes vector programming from CPU

SIMD instructions were a mistake in CPU instruction set design. Vector instructions have register size independent code which makes vector programming from CPUs much more approachable and binary compatible.

zeckalpha 6y ago
Vector instructions are a type of SIMD
- throwaway81523 6y ago
  I think SIMD referred to Intel SSE*/AVX/etc., where the vectors are of fixed length. That meant new instructions had to keep getting introduced for new sizes of vectors.
  - zeckalpha 6y ago
    SIMD as a term predates those Intel instructions by 30 years.
phkahler 6y ago
AVX style vectors IMHO should have been used for all those vec3 and vec4 operations that are used in graphics applications. They should not have been used for general parallelization of loops - although they have had some success in that. GPUs have geometrically relevant vectors as basic data types. I wish language designers would realize the value in that, but they are too concerned with abstraction. RISC-V vectors are meant for the abstract general parallel concepts, but could also help with graphics code. There really seems to be a disconnect around which types of vectors are good for which uses.
- incrudible 6y ago
  > AVX style vectors IMHO should have been used for all those vec3 and vec4 operations that are used in graphics applications. That is the naive application of SIMD, which many have attempted. It does not lead to a meaningful speedup. To get a good speedup from SIMD, you need SOA or AOSOA layout. Ergonomically this is already similar to vector instructions.
  - phkahler 6y ago
    >> That is the naive application of SIMD, which many have attempted. It does not lead to a meaningful speedup. How can it not provide a meaningful speedup? If I have 3- or 4-element vectors a,b, and c, with scalars u,v. I want to compute: a = ub + vc; These should be first class data types, passed by value, and that line of code should take 2 SIMD instructions at most. That should also not require a fancy vectorizing compiler to do the analysis to find the parallelism because the data types map directly to the ISA vector registers. GPUs have this, the benefit should be very real.
    - atq2119 6y ago
      By and large, GPUs don't have this anymore, actually (they used to, but this changed many years ago). On modern GPUs your example is "scalarized" and results in separate instructions for each vector component. Of course execution is still "vectorized", but only in the sense of operating on the data for 16/32/64 threads at once. The reason for this design is that while vec3 and vec4 are common, they are by no means universal in modern shader code. A micro-architecture built on vec3 or vec4 would be under-utilized in the large amounts of shader code that are scalar in the source language. There are some exceptions, e.g. native support for 16-bit vec2 comes naturally on architectures with 32-bit registers. But those are exceptions.

zeckalpha 6y ago

Vector instructions are a type of SIMD

throwaway81523 6y ago
I think SIMD referred to Intel SSE*/AVX/etc., where the vectors are of fixed length. That meant new instructions had to keep getting introduced for new sizes of vectors.
- zeckalpha 6y ago
  SIMD as a term predates those Intel instructions by 30 years.

phkahler 6y ago

AVX style vectors IMHO should have been used for all those vec3 and vec4 operations that are used in graphics applications. They should not have been used for general parallelization of loops - although they have had some success in that. GPUs have geometrically relevant vectors as basic data types. I wish language designers would realize the value in that, but they are too concerned with abstraction. RISC-V vectors are meant for the abstract general parallel concepts, but could also help with graphics code. There really seems to be a disconnect around which types of vectors are good for which uses.

incrudible 6y ago
> AVX style vectors IMHO should have been used for all those vec3 and vec4 operations that are used in graphics applications. That is the naive application of SIMD, which many have attempted. It does not lead to a meaningful speedup. To get a good speedup from SIMD, you need SOA or AOSOA layout. Ergonomically this is already similar to vector instructions.
- phkahler 6y ago
  >> That is the naive application of SIMD, which many have attempted. It does not lead to a meaningful speedup. How can it not provide a meaningful speedup? If I have 3- or 4-element vectors a,b, and c, with scalars u,v. I want to compute: a = ub + vc; These should be first class data types, passed by value, and that line of code should take 2 SIMD instructions at most. That should also not require a fancy vectorizing compiler to do the analysis to find the parallelism because the data types map directly to the ISA vector registers. GPUs have this, the benefit should be very real.
  - atq2119 6y ago
    By and large, GPUs don't have this anymore, actually (they used to, but this changed many years ago). On modern GPUs your example is "scalarized" and results in separate instructions for each vector component. Of course execution is still "vectorized", but only in the sense of operating on the data for 16/32/64 threads at once. The reason for this design is that while vec3 and vec4 are common, they are by no means universal in modern shader code. A micro-architecture built on vec3 or vec4 would be under-utilized in the large amounts of shader code that are scalar in the source language. There are some exceptions, e.g. native support for 16-bit vec2 comes naturally on architectures with 32-bit registers. But those are exceptions.