5 ms·

A tangential question: Why are SIMD instructions fixed-number-of-lanes? It seems to me that something like a semi-generic MAP_START(start, number, stride) <bun

A tangential question: Why are SIMD instructions fixed-number-of-lanes? It seems to me that something like a semi-generic MAP_START(start, number, stride) <bunch of instructions> MAP_END (where it's explicitly executing the instructions in an undefined order between lanes) would be easier to deal with, and easier to upgrade down the line too.

sunfish 11y ago
In part because if <bunch of instructions> is arbitrary JS, it may or may not be able to run in SIMD mode, so then you get surprising performance cliffs because your code runs in scalar sometimes. And in part because there's more to "short SIMD" programming than just charging through large arrays. Sometimes you need to swizzle elements around, for example, and this is easier if you can think about multiple lanes at a time.
- TheLoneWolfling 11y ago
  Not arbitrary JS. Semi-arbitrary machine code. The first few CPUs would restrict it to a couple instructions, with later generations potentially adding instructions. And as for your second, don't think of it as a standard map. I should have elaborated. Think of it more of a for loop with an index variable and temporary variable per-iteration. You can access (read and write) other things outside of that index too - the only restriction being that the iterations of the loop will execute in an arbitrary order, including simultaneously.
  - corysama 11y ago
    I think what you are looking for is https://github.com/IntelLabs/RiverTrail https://github.com/IntelLabs/RiverTrail The JS SIMD effort is aimed at finer-grained, hand-written but highly reliable and predictable SIMD as compared to the large-scale, convenient but kinda magic of RiverTrail.
    - TheLoneWolfling 11y ago
      I think you missed the start of my first comment: namely, I was not talking about JS. I was talking about SIMD at the instruction-set level in general.
      - deleted 11y ago
        [deleted]
      - lmeyerov 11y ago
        Adding fuel to your fire: hardware will often be implemented with multiple SIMD compute units (transistors are cheap!), and pipeline multiple SIMD calls. With instruction sets like AVX, the length is increasing. SIMD is non-controversial: it's just like another ALU instruction but maps the inputs to the outputs differently. Doing something more exotic, like VLIW, is an uphill battle. However, as seen with GPUs, that can be fruitful.
thechao 11y ago
I think you're asking about the distinction between SIMT (supported by GPUs/compute coprocessors), and SIMD. In SIMT, you want to issue a "bunch of the same work on a crapload of pseudo-threads"—in the most hardware-efficient manner possible (vectorized). SIMD is different—it is all about the interactions between lanes of data. As a bit of a tautology: the vector unit in x86 parts is SIMD, because it was designed for SIMD workloads.
- TheLoneWolfling 11y ago
  Effectively, yes. But I don't see why you couldn't interact between lanes with SIMT.
brigade 11y ago
For the same reason that CPUs don't operate on bignums. ALUs are fixed width, and you don't want to microcode every last instruction. That said, the original vector processors from the '70s and '80s were kind of like what you describe. Not coincidentally, they died off with the RISC movement.
stephencanon 11y ago
That has been tried multiple times by multiple companies in the past. Most recently (for CPUs, to my knowledge) by ARM in the armv6-era VFP ISA, which was deprecated and replaced by the "normal SIMD" (fixed width) NEON instructions in armv7. It's a good enough idea that people keep trying to make it work. But it's never been really successful, either.
- acqq 11y ago
  The major advantage of the "almost fixed"(1) width is the possibility to tightly control (that is, do it directly in the registers) operations "in both dimensions", which actually matters in real life algorithms. 1) It's not fixed as the processors actually get wider vectors instruction sets: SSE is 128 bits, but AVX is 256 bits.
  - TheLoneWolfling 11y ago
    With this method you can do direct register operations, though.
    - acqq 11y ago
      If you mean when it's fixed, yes. That's what I wanted to say. But I also wanted to mention that even the fixed width increases from time to time.
      - TheLoneWolfling 11y ago
        No, I mean with SIMT as well. And increasing the size of fixed-width operations from time to time does not help existing code.
        acqq 11y ago
        Still, having the fixed width allows you to optimize the existing code better than when you introduce the abstraction without the fixed width. See the shuffle operations and similar, which operate on the parts of the wide registers and which are actually needed for the real life optimizations to avoid expensive memory accesses and allow operating on the registers alone.

sunfish 11y ago

In part because if <bunch of instructions> is arbitrary JS, it may or may not be able to run in SIMD mode, so then you get surprising performance cliffs because your code runs in scalar sometimes. And in part because there's more to "short SIMD" programming than just charging through large arrays. Sometimes you need to swizzle elements around, for example, and this is easier if you can think about multiple lanes at a time.

TheLoneWolfling 11y ago
Not arbitrary JS. Semi-arbitrary machine code. The first few CPUs would restrict it to a couple instructions, with later generations potentially adding instructions. And as for your second, don't think of it as a standard map. I should have elaborated. Think of it more of a for loop with an index variable and temporary variable per-iteration. You can access (read and write) other things outside of that index too - the only restriction being that the iterations of the loop will execute in an arbitrary order, including simultaneously.
- corysama 11y ago
  I think what you are looking for is https://github.com/IntelLabs/RiverTrail https://github.com/IntelLabs/RiverTrail The JS SIMD effort is aimed at finer-grained, hand-written but highly reliable and predictable SIMD as compared to the large-scale, convenient but kinda magic of RiverTrail.
  - TheLoneWolfling 11y ago
    I think you missed the start of my first comment: namely, I was not talking about JS. I was talking about SIMD at the instruction-set level in general.
    - deleted 11y ago
      [deleted]
    - lmeyerov 11y ago
      Adding fuel to your fire: hardware will often be implemented with multiple SIMD compute units (transistors are cheap!), and pipeline multiple SIMD calls. With instruction sets like AVX, the length is increasing. SIMD is non-controversial: it's just like another ALU instruction but maps the inputs to the outputs differently. Doing something more exotic, like VLIW, is an uphill battle. However, as seen with GPUs, that can be fruitful.

thechao 11y ago

I think you're asking about the distinction between SIMT (supported by GPUs/compute coprocessors), and SIMD. In SIMT, you want to issue a "bunch of the same work on a crapload of pseudo-threads"—in the most hardware-efficient manner possible (vectorized). SIMD is different—it is all about the interactions between lanes of data. As a bit of a tautology: the vector unit in x86 parts is SIMD, because it was designed for SIMD workloads.

TheLoneWolfling 11y ago
Effectively, yes. But I don't see why you couldn't interact between lanes with SIMT.

brigade 11y ago

For the same reason that CPUs don't operate on bignums. ALUs are fixed width, and you don't want to microcode every last instruction. That said, the original vector processors from the '70s and '80s were kind of like what you describe. Not coincidentally, they died off with the RISC movement.

stephencanon 11y ago

That has been tried multiple times by multiple companies in the past. Most recently (for CPUs, to my knowledge) by ARM in the armv6-era VFP ISA, which was deprecated and replaced by the "normal SIMD" (fixed width) NEON instructions in armv7. It's a good enough idea that people keep trying to make it work. But it's never been really successful, either.

acqq 11y ago
The major advantage of the "almost fixed"(1) width is the possibility to tightly control (that is, do it directly in the registers) operations "in both dimensions", which actually matters in real life algorithms. 1) It's not fixed as the processors actually get wider vectors instruction sets: SSE is 128 bits, but AVX is 256 bits.
- TheLoneWolfling 11y ago
  With this method you can do direct register operations, though.
  - acqq 11y ago
    If you mean when it's fixed, yes. That's what I wanted to say. But I also wanted to mention that even the fixed width increases from time to time.
    - TheLoneWolfling 11y ago
      No, I mean with SIMT as well. And increasing the size of fixed-width operations from time to time does not help existing code.
      - acqq 11y ago
        Still, having the fixed width allows you to optimize the existing code better than when you introduce the abstraction without the fixed width. See the shuffle operations and similar, which operate on the parts of the wide registers and which are actually needed for the real life optimizations to avoid expensive memory accesses and allow operating on the registers alone.