4 ms·

I totally agree that Bulldozer was ahead of its time. In some ways, it was a case of being too clever, trying to do things under the hood for the FPU similarly

I totally agree that Bulldozer was ahead of its time. In some ways, it was a case of being too clever, trying to do things under the hood for the FPU similarly to Hyper-Threading for decoder/front-end resources (which also caused problems). Getting integrated with the underlying software (e.g., the kernel and its scheduler) in big.LITTLE was a comparative revelation. Conversely, the Cell took this too far, requiring that high level software be deeply SPE and memory-shuffling aware, almost like having a bank of DSPs in-package. The instruction-set/functional difference between the PPE and SPE made for encumbrances that likely would never have been fully solved by the toolchain (even if the toolchain had shipped ahead of the processor rather than well afterwards). Larrabee made attempts to solve the instruction set difference problem (in a very Intel way), but the topology, cache behavior, and pure core size proved to be far too limiting in real applications. In the end, Intel missed on the balance of core/execution-unit size vs. count when compared to Nvidia and ATI. GPGPU progress has definitely demonstrated the value of toolchain abstraction, though, and adherence to a given instruction set (and the architectural implications that came from that) proved to be a limiting constraint for Larrabee. The last 20-25 years in compute architecture design have seen many interesting articulations of clever ideas. Some deaths were predictable, but each of the explorations should be commended for the ways that they pushed boundaries and cleared the path for their successors.

cpgxiii 4y ago
I think you could draw somewhat different lessons from this, though: - Cell failed because it required too much work and was too incompatible with any other platform (save for DSPs). - Larrabee failed because KNC wasn't binary compatible and the toolchain was too much of a pain to work with, and KNL/KNM "failed" because they were too hard to get (although, I think "failed" is perhaps too strong here, the "lots of general-purpose cores with vector units" is exactly where Intel, AMD, and the aarch64 vendors have gone since). KNC's lack of binary compatibility is really what got things off on the wrong foot, the whole advantage it had over AMD/Nvidia GPUs was it amenability to GPU-unfriendly code, but I think the barrier of having to rebuild everything was prohibitive for many of the smaller users who would have been well-positioned to use it. - NVidia "won" in the GPGPU space because CUDA and its libraries have provided a stable-enough basis for complex applications to use, and the underlying hardware has evolved to be ever more performant and capable. - AMD "failed" in the GPGPU space because their toolchain abstraction is too weak and compatibility is poor. Unlike CUDA, there's no capable API that works on the whole range (even with OpenCL AMD's support is questionable at times, with two totally different driver stacks). I'd say the biggest lessons are: (1) compatibility with existing code is king, and (2) toolchain and hardware accessibility is critical. You can survive breaking (1) if your tools are good enough, but you can't win by breaking both of them.
- Const-me 4y ago
  > Unlike CUDA, there's no capable API that works on the whole range Microsoft's D3D is very capable, and vendor-agnostic, same code works on all GPUs because the user-mode half of the GPU driver includes a JIT compiler for these shaders. Not sure why it's not popular outside of game development. IMO their GPGPU API is the best one currently available.
  - cpgxiii 4y ago
    D3D is the exception to basically everything in graphics-land, avoiding the pitfalls that basically every other cross-hardware-vendor API suffers. The problem, obviously, is that it is Windows-only. It's only popular in cases where the rest of the system is also Windows-only, since otherwise you'd have to write multiple backends anyways (at which point you either stick to OpenCL, or you do both CUDA and OpenCL for better performance). Being limited to Windows makes DirectCompute a non-starter to basically anything in the HPC/server/embedded space.

cpgxiii 4y ago

I think you could draw somewhat different lessons from this, though: - Cell failed because it required too much work and was too incompatible with any other platform (save for DSPs). - Larrabee failed because KNC wasn't binary compatible and the toolchain was too much of a pain to work with, and KNL/KNM "failed" because they were too hard to get (although, I think "failed" is perhaps too strong here, the "lots of general-purpose cores with vector units" is exactly where Intel, AMD, and the aarch64 vendors have gone since). KNC's lack of binary compatibility is really what got things off on the wrong foot, the whole advantage it had over AMD/Nvidia GPUs was it amenability to GPU-unfriendly code, but I think the barrier of having to rebuild everything was prohibitive for many of the smaller users who would have been well-positioned to use it. - NVidia "won" in the GPGPU space because CUDA and its libraries have provided a stable-enough basis for complex applications to use, and the underlying hardware has evolved to be ever more performant and capable. - AMD "failed" in the GPGPU space because their toolchain abstraction is too weak and compatibility is poor. Unlike CUDA, there's no capable API that works on the whole range (even with OpenCL AMD's support is questionable at times, with two totally different driver stacks). I'd say the biggest lessons are: (1) compatibility with existing code is king, and (2) toolchain and hardware accessibility is critical. You can survive breaking (1) if your tools are good enough, but you can't win by breaking both of them.

Const-me 4y ago
> Unlike CUDA, there's no capable API that works on the whole range Microsoft's D3D is very capable, and vendor-agnostic, same code works on all GPUs because the user-mode half of the GPU driver includes a JIT compiler for these shaders. Not sure why it's not popular outside of game development. IMO their GPGPU API is the best one currently available.
- cpgxiii 4y ago
  D3D is the exception to basically everything in graphics-land, avoiding the pitfalls that basically every other cross-hardware-vendor API suffers. The problem, obviously, is that it is Windows-only. It's only popular in cases where the rest of the system is also Windows-only, since otherwise you'd have to write multiple backends anyways (at which point you either stick to OpenCL, or you do both CUDA and OpenCL for better performance). Being limited to Windows makes DirectCompute a non-starter to basically anything in the HPC/server/embedded space.