3 ms·

CUDA’s biggest advantage over OpenCL other than not being a camel was its C++ support which is still the main language in use for CUDA in production, I doubt FO

CUDA’s biggest advantage over OpenCL other than not being a camel was its C++ support which is still the main language in use for CUDA in production, I doubt FORTRAN was the reason why CUDA got to where it is, C++ on the other hand had quite a lot to do with it during its initial days when OpenCL was still stuck in OpenGL C-Land. NVIDIA understood also early on the importance of first party libraries and commercial partnerships something Intel also understands which is why OneAPI has wider adoption already than ROCm.

pjmlp 6y ago
CUDA supports much more languages than just C++ and Fortan. .NET, Java, Julia, Python (RAPIDS/cuDF), Haskell don't have a place on OneAPI so far. And yes, going back to C++, the hardware is based on C++11 memory model (which was based on Java/.NET models). So plenty of stuff to catch up, besides "we can do C++".
- dragandj 6y ago
  How does CUDA support any of these (.Net, Java, etc?). It's the first time I hear this claim. There are 3rd party wrappers in Java, .Net, etc. that call CUDA's C++ API, and that's all. Equivalet APIs exist for OpenCL too...
  - dogma1138 6y ago
    There are Java and C# compilers for CUDA such as JCUDA and http://www.altimesh.com/hybridizer-essentials/ http://www.altimesh.com/hybridizer-essentials/ but the CUDA runtime, libraries and the first party compiler only supports C/C++ and FORTRAN, for Python you need to use something like Numba. Most non C++ frameworks and implementations tho would simply use wrappers and bindings. I also am not aware of any high performance lib for CUDA that wasn’t written in C++.
  - pjmlp 6y ago
    "Hybridizer: High-Performance C# on GPUs" https://developer.nvidia.com/blog/hybridizer-csharp/ https://developer.nvidia.com/blog/hybridizer-csharp/ "Simplifying GPU Access: A Polyglot Binding for GPUs with GraalVM" https://developer.nvidia.com/gtc/2020/video/s21269-vid https://developer.nvidia.com/gtc/2020/video/s21269-vid And then you can browse for products on https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/tesla-product-literature/gpu-applications-catalog.pdf https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Cent...
    - dogma1138 6y ago
      Hybridizer simply creates CUDA C++ code from C# which is then compiled to PTX it also does it for AVX which you can the compile with Intel’s compiler or gcc, it’s not particularly good and you often need to debug the generated CUDA source code yourself, it’s also doesn’t always play well with the CUDA programming model especially its more advanced features. And again it’s a commercial product developed by a 3rd party, whilst someone uses it I wouldn’t even put it as a rounding error when accounting for why CUDA has the market share it has.
      - pjmlp 6y ago
        It is like everyone arguing about C++ for AAA studios, as if everyone was doing Crysis and Fortnight clones, while forgetting the legions of people making money selling A games. Or forgetting the days when games written in C were actually full of inline Assembly. It is still CUDA, regardless if it goes through PTX or CUDA C++ as implementation detail for the high level code.
        dogma1138 6y ago
        You aren’t seeing the forest for the trees. The market for these secondary implementations is tiny, and that is coming from someone who worked at a company that had CUDA executed from a spreadsheet. The C#/Java et. al isn’t what made CUDA popular nor what would make OneAPI succeed or fail. CUDA became popular because of its architecture, using an intermediate assembly to allow backward and forward compatibility, it had exe Elle to support across the entire NVIDIA GPU stack which means that it could run on everything form bargain bin laptops with the cheapest dGPU to HPC cards. It came with a large library of high performant libraries and yes the C++ programming model is why it was adopted so well by the big players. And even arguably more importantly is that when ML and GPU compute exploded and that wasn’t that long ago NVIDIA from a business perspective was the top dog in town, CUDA could’ve been dog shit but when AMD could barely launch a GPU that could compete with NVIDIA’s mid range for multiple generations it wouldn’t have mattered.
        6y ago
  - my123 6y ago
    The CUDA runtime gets as input the PTX intermediate language. The toolkit ships with compilers from C++ and Fortran to NVVM, and provides you documentation about the PTX virtual machine at https://docs.nvidia.com/cuda/parallel-thread-execution/index.html https://docs.nvidia.com/cuda/parallel-thread-execution/index... and about the higher-level NVVM (which compiles down to PTX) at https://docs.nvidia.com/cuda/nvvm-ir-spec/index.html https://docs.nvidia.com/cuda/nvvm-ir-spec/index.html.
    - navaati 6y ago
      Oooh, I didn’t know PTX was an intermediate representation and explicitly documented as such, I really thought it was the actual assembly ran by the chips…
      - my123 6y ago
        You can get the GPU-targeted assembly (sometimes called SASS by NVIDIA) through specifically compiling to a given GPU then using nvdisasm, which also has a very terse definition of the underlying instruction set in the docs (https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-ref https://docs.nvidia.com/cuda/cuda-binary-utilities/index.htm...). But it's one way only, NVIDIA ships a disassembler, but explicitly doesn't ship an assembler.
      - dogma1138 6y ago
        PTX is a virtual ISA and the reason why ROCm is doomed to fail well beyond its horrendous bugs. ROCm produces hardware specific binaries which not only means you need to produce binaries for multiple GPUs but you also don’t have any guarantee for forward compatibility. A CUDA binary from 10 years ago will still run today on modern hardware, ROCm breaks compatibility between minor releases sometimes and it’s often not documented.
  - The_rationalist 6y ago
    https://github.com/NVIDIA/grcuda https://github.com/NVIDIA/grcuda
- The_rationalist 6y ago
  in addition, grCuda is a breakthrough that enable interop with much more languages such as Ruby, R, Js, (soon python), etc https://github.com/NVIDIA/grcuda https://github.com/NVIDIA/grcuda

pjmlp 6y ago

CUDA supports much more languages than just C++ and Fortan. .NET, Java, Julia, Python (RAPIDS/cuDF), Haskell don't have a place on OneAPI so far. And yes, going back to C++, the hardware is based on C++11 memory model (which was based on Java/.NET models). So plenty of stuff to catch up, besides "we can do C++".

dragandj 6y ago
How does CUDA support any of these (.Net, Java, etc?). It's the first time I hear this claim. There are 3rd party wrappers in Java, .Net, etc. that call CUDA's C++ API, and that's all. Equivalet APIs exist for OpenCL too...
- dogma1138 6y ago
  There are Java and C# compilers for CUDA such as JCUDA and http://www.altimesh.com/hybridizer-essentials/ http://www.altimesh.com/hybridizer-essentials/ but the CUDA runtime, libraries and the first party compiler only supports C/C++ and FORTRAN, for Python you need to use something like Numba. Most non C++ frameworks and implementations tho would simply use wrappers and bindings. I also am not aware of any high performance lib for CUDA that wasn’t written in C++.
- pjmlp 6y ago
  "Hybridizer: High-Performance C# on GPUs" https://developer.nvidia.com/blog/hybridizer-csharp/ https://developer.nvidia.com/blog/hybridizer-csharp/ "Simplifying GPU Access: A Polyglot Binding for GPUs with GraalVM" https://developer.nvidia.com/gtc/2020/video/s21269-vid https://developer.nvidia.com/gtc/2020/video/s21269-vid And then you can browse for products on https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/tesla-product-literature/gpu-applications-catalog.pdf https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Cent...
  - dogma1138 6y ago
    Hybridizer simply creates CUDA C++ code from C# which is then compiled to PTX it also does it for AVX which you can the compile with Intel’s compiler or gcc, it’s not particularly good and you often need to debug the generated CUDA source code yourself, it’s also doesn’t always play well with the CUDA programming model especially its more advanced features. And again it’s a commercial product developed by a 3rd party, whilst someone uses it I wouldn’t even put it as a rounding error when accounting for why CUDA has the market share it has.
    - pjmlp 6y ago
      It is like everyone arguing about C++ for AAA studios, as if everyone was doing Crysis and Fortnight clones, while forgetting the legions of people making money selling A games. Or forgetting the days when games written in C were actually full of inline Assembly. It is still CUDA, regardless if it goes through PTX or CUDA C++ as implementation detail for the high level code.
      - dogma1138 6y ago
        You aren’t seeing the forest for the trees. The market for these secondary implementations is tiny, and that is coming from someone who worked at a company that had CUDA executed from a spreadsheet. The C#/Java et. al isn’t what made CUDA popular nor what would make OneAPI succeed or fail. CUDA became popular because of its architecture, using an intermediate assembly to allow backward and forward compatibility, it had exe Elle to support across the entire NVIDIA GPU stack which means that it could run on everything form bargain bin laptops with the cheapest dGPU to HPC cards. It came with a large library of high performant libraries and yes the C++ programming model is why it was adopted so well by the big players. And even arguably more importantly is that when ML and GPU compute exploded and that wasn’t that long ago NVIDIA from a business perspective was the top dog in town, CUDA could’ve been dog shit but when AMD could barely launch a GPU that could compete with NVIDIA’s mid range for multiple generations it wouldn’t have mattered.
        6y ago
- my123 6y ago
  The CUDA runtime gets as input the PTX intermediate language. The toolkit ships with compilers from C++ and Fortran to NVVM, and provides you documentation about the PTX virtual machine at https://docs.nvidia.com/cuda/parallel-thread-execution/index.html https://docs.nvidia.com/cuda/parallel-thread-execution/index... and about the higher-level NVVM (which compiles down to PTX) at https://docs.nvidia.com/cuda/nvvm-ir-spec/index.html https://docs.nvidia.com/cuda/nvvm-ir-spec/index.html.
  - navaati 6y ago
    Oooh, I didn’t know PTX was an intermediate representation and explicitly documented as such, I really thought it was the actual assembly ran by the chips…
    - my123 6y ago
      You can get the GPU-targeted assembly (sometimes called SASS by NVIDIA) through specifically compiling to a given GPU then using nvdisasm, which also has a very terse definition of the underlying instruction set in the docs (https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-ref https://docs.nvidia.com/cuda/cuda-binary-utilities/index.htm...). But it's one way only, NVIDIA ships a disassembler, but explicitly doesn't ship an assembler.
    - dogma1138 6y ago
      PTX is a virtual ISA and the reason why ROCm is doomed to fail well beyond its horrendous bugs. ROCm produces hardware specific binaries which not only means you need to produce binaries for multiple GPUs but you also don’t have any guarantee for forward compatibility. A CUDA binary from 10 years ago will still run today on modern hardware, ROCm breaks compatibility between minor releases sometimes and it’s often not documented.
- The_rationalist 6y ago
  https://github.com/NVIDIA/grcuda https://github.com/NVIDIA/grcuda
The_rationalist 6y ago
in addition, grCuda is a breakthrough that enable interop with much more languages such as Ruby, R, Js, (soon python), etc https://github.com/NVIDIA/grcuda https://github.com/NVIDIA/grcuda