4 ms·

Interesting post. I'm bummed that there isn't more interest in bringing C++ to ASIC/Accelerator scene from the committee. I think projects like Nvidia's Thrust[

Interesting post. I'm bummed that there isn't more interest in bringing C++ to ASIC/Accelerator scene from the committee. I think projects like Nvidia's Thrust[1] show that C++ is poised to be fantastic medium for software developers to break into experimenting with FPGAs, GPUs, and potential future commercially available equivalents to the TPU. There is some really cool cross-platform software infrastructure that is still under active development. 1 = https://thrust.github.io/ https://thrust.github.io/ 2 = https://mlir.llvm.org/ https://mlir.llvm.org/

jcelerier 6y ago
> Interesting post. I'm bummed that there isn't more interest in bringing C++ to ASIC/Accelerator scene from the committee. isn't that purely an implementation issue ? e.g. both Apple and NVidia have brought C++ to the GPU, one with Cuda and the other with Metal... that did not require any help from the committee.
- dwrodri 6y ago
  No and yes. Is it strictly the language’s responsibility to deal with the implementation? Not really. I agree in theory. In practice, Google is behind this statement. Nvidia is behind this statement. Two of the largest supercomputing facilities in the US are backing this. The document heavily implies that these are the goals for C++ based on their use cases. These are also organizations that have had a massive role getting the accelerator space to where it is today. Sure, MLIR is technically a project underneath the LLVM foundation, but isn’t it mostly Google employees who were working on it. Lattner has moved on from there and is now setting his sights on RISC-V it seems. As someone who likes modern C+ + and is interested in new, open hardware, I’m really happy RISC-V is being made a priority, along with bare metal compilation. But I’m also confused and here’s why. I agree entirely that CUDA support for modern C++ is moving along nicely, especially since CUDA 11 supports C++17. However, a good chunk of these authors are Nvidia employees and now they’re implying their “use case” for C++ isn’t associated with accelerators?

jcelerier 6y ago

> Interesting post. I'm bummed that there isn't more interest in bringing C++ to ASIC/Accelerator scene from the committee. isn't that purely an implementation issue ? e.g. both Apple and NVidia have brought C++ to the GPU, one with Cuda and the other with Metal... that did not require any help from the committee.

dwrodri 6y ago
No and yes. Is it strictly the language’s responsibility to deal with the implementation? Not really. I agree in theory. In practice, Google is behind this statement. Nvidia is behind this statement. Two of the largest supercomputing facilities in the US are backing this. The document heavily implies that these are the goals for C++ based on their use cases. These are also organizations that have had a massive role getting the accelerator space to where it is today. Sure, MLIR is technically a project underneath the LLVM foundation, but isn’t it mostly Google employees who were working on it. Lattner has moved on from there and is now setting his sights on RISC-V it seems. As someone who likes modern C+ + and is interested in new, open hardware, I’m really happy RISC-V is being made a priority, along with bare metal compilation. But I’m also confused and here’s why. I agree entirely that CUDA support for modern C++ is moving along nicely, especially since CUDA 11 supports C++17. However, a good chunk of these authors are Nvidia employees and now they’re implying their “use case” for C++ isn’t associated with accelerators?