4 ms·

I found it very surprising that the article didn't mention machine learning applications. Machine learning and scientific computing is where a company like NVID

I found it very surprising that the article didn't mention machine learning applications. Machine learning and scientific computing is where a company like NVIDIA really shines. The reason for this is CUDA. Nearly all deep learning frameworks, such as tensorflow, use CUDA to run on GPUs. Until AMD comes up with their version of CUDA, and convinces the authors of deep learning frameworks to support it, they will be behind. NVIDIA.

fulafel 9y ago
AMD has been working on CUDA for a while now, it's called HIP. Here's Tensorflow for it: https://github.com/ROCmSoftwarePlatform/hiptensorflow https://github.com/ROCmSoftwarePlatform/hiptensorflow I have no experience so can't comment on how production-ready it is.
- paulmd 9y ago
  HIP is fine for very basic programs but you have always been able to convert those pretty trivially with find-and-replace. The bigger problem has always been middleware. Effectively, HIP needs to duplicate everything that NVIDIA provides, 1:1, and it doesn't. More complex libraries (particularly ones that touch hardware features like texture units/etc) cannot be insta-converted with HIP either. It's impractical, for the most part. I've always been of the opinion that what AMD needs is something like GPU Ocelot that can transpile PTX rather than working at a source level. Unfortunately I'm sure that would be legally frought for AMD.
  - generic_T 9y ago
    I'm just getting started with machine learning and deep learning, so I'm certainly no expert. I wonder if building frameworks on top of OpenCL would be a viable alternative?
    - paulmd 9y ago
      Sure. And like I said, for relatively trivial stuff you can almost do a find-and-replace of CUDA keywords with OpenCL keywords and get something that will run with relatively minimal tweaking. The problem is the middleware - i.e. when you go to write a program, you want to write your financial simulation or whatever, not a RNG library. Once that stuff gets written, OpenCL will be perfectly viable. It's just sort of a slog now, vs a huge amount of stuff available for CUDA, both from NVIDIA and from others. Another, more general problem is that OpenCL is not really a GPGPU language, it's a general framework for dispatching tasks to heterogeneous processors. You can hypothetically use OpenCL to dispatch tasks to a FPGA or a DSP or anything else. This means there's a relatively silly amount of boilerplate compared to CUDA, which is stylistically annoying but not really complex. But in general it's also up to the vendor to implement their own SDK, compiler, etc, and there's no guarantee that what runs on one OpenCL platform will run on another. What is commonly referred to as "OpenCL" is actually the AMD APP SDK and the NVIDIA OpenCL SDK, which both implement their own version of parallel C++ dispatched according to the OpenCL function interface/semantics. So in other words, OpenCL suffers from a bit of Architecture Astronaut syndrome. AMD solved the problem of making a framework that can dispatch tasks to any coprocessor that implements their interface, NVIDIA solved the problem of making a GPGPU language. As such, AMD sometimes struggles to fulfill the cross-platform promise of their language and suffers in conciseness. For learning CUDA, I really like the Thrust language. You can write GPGPU programs that are literally 10 lines or less. It looks like regular C++ STL but you can execute it on the GPU. You can easily call __device__ functions using functors iterating across your dataset, or get raw_pointers into a device_vector and then pass them into a normal kernel launch, so there's a lot of flexibility there to tune stuff as you want to make it more complex. http://docs.nvidia.com/cuda/thrust/index.html http://docs.nvidia.com/cuda/thrust/index.html For a non-trivial program, here's my master's thesis, which I did in Thrust. Not really machine learning but at least you can see what you're getting into. https://github.com/pholvs/PandemicThrust https://github.com/pholvs/PandemicThrust For AMD, there is supposedly an equivalent called "Bolt Framework" but I have not used it personally. As is customary for AMD's libraries, after release it was abandoned and it has not been updated in several years, best of luck. https://hsa-libraries.github.io/Bolt/html/ https://hsa-libraries.github.io/Bolt/html/ https://github.com/HSA-Libraries/Bolt https://github.com/HSA-Libraries/Bolt
nonbel 9y ago
>"Until AMD comes up with their version of CUDA, and convinces the authors of deep learning frameworks to support it, they will be behind." I agree AMD needs to do this badly, but don't think it will take much convincing as long as it works. You can read reddit/etc ml forums and see people are desperate for some alternative (AMD or otherwise) due to Nvidia's abuses of its monopoly.
- generic_T 9y ago
  I would definitely like to see more competition.

fulafel 9y ago

AMD has been working on CUDA for a while now, it's called HIP. Here's Tensorflow for it: https://github.com/ROCmSoftwarePlatform/hiptensorflow https://github.com/ROCmSoftwarePlatform/hiptensorflow I have no experience so can't comment on how production-ready it is.

paulmd 9y ago
HIP is fine for very basic programs but you have always been able to convert those pretty trivially with find-and-replace. The bigger problem has always been middleware. Effectively, HIP needs to duplicate everything that NVIDIA provides, 1:1, and it doesn't. More complex libraries (particularly ones that touch hardware features like texture units/etc) cannot be insta-converted with HIP either. It's impractical, for the most part. I've always been of the opinion that what AMD needs is something like GPU Ocelot that can transpile PTX rather than working at a source level. Unfortunately I'm sure that would be legally frought for AMD.
- generic_T 9y ago
  I'm just getting started with machine learning and deep learning, so I'm certainly no expert. I wonder if building frameworks on top of OpenCL would be a viable alternative?
  - paulmd 9y ago
    Sure. And like I said, for relatively trivial stuff you can almost do a find-and-replace of CUDA keywords with OpenCL keywords and get something that will run with relatively minimal tweaking. The problem is the middleware - i.e. when you go to write a program, you want to write your financial simulation or whatever, not a RNG library. Once that stuff gets written, OpenCL will be perfectly viable. It's just sort of a slog now, vs a huge amount of stuff available for CUDA, both from NVIDIA and from others. Another, more general problem is that OpenCL is not really a GPGPU language, it's a general framework for dispatching tasks to heterogeneous processors. You can hypothetically use OpenCL to dispatch tasks to a FPGA or a DSP or anything else. This means there's a relatively silly amount of boilerplate compared to CUDA, which is stylistically annoying but not really complex. But in general it's also up to the vendor to implement their own SDK, compiler, etc, and there's no guarantee that what runs on one OpenCL platform will run on another. What is commonly referred to as "OpenCL" is actually the AMD APP SDK and the NVIDIA OpenCL SDK, which both implement their own version of parallel C++ dispatched according to the OpenCL function interface/semantics. So in other words, OpenCL suffers from a bit of Architecture Astronaut syndrome. AMD solved the problem of making a framework that can dispatch tasks to any coprocessor that implements their interface, NVIDIA solved the problem of making a GPGPU language. As such, AMD sometimes struggles to fulfill the cross-platform promise of their language and suffers in conciseness. For learning CUDA, I really like the Thrust language. You can write GPGPU programs that are literally 10 lines or less. It looks like regular C++ STL but you can execute it on the GPU. You can easily call __device__ functions using functors iterating across your dataset, or get raw_pointers into a device_vector and then pass them into a normal kernel launch, so there's a lot of flexibility there to tune stuff as you want to make it more complex. http://docs.nvidia.com/cuda/thrust/index.html http://docs.nvidia.com/cuda/thrust/index.html For a non-trivial program, here's my master's thesis, which I did in Thrust. Not really machine learning but at least you can see what you're getting into. https://github.com/pholvs/PandemicThrust https://github.com/pholvs/PandemicThrust For AMD, there is supposedly an equivalent called "Bolt Framework" but I have not used it personally. As is customary for AMD's libraries, after release it was abandoned and it has not been updated in several years, best of luck. https://hsa-libraries.github.io/Bolt/html/ https://hsa-libraries.github.io/Bolt/html/ https://github.com/HSA-Libraries/Bolt https://github.com/HSA-Libraries/Bolt

nonbel 9y ago

>"Until AMD comes up with their version of CUDA, and convinces the authors of deep learning frameworks to support it, they will be behind." I agree AMD needs to do this badly, but don't think it will take much convincing as long as it works. You can read reddit/etc ml forums and see people are desperate for some alternative (AMD or otherwise) due to Nvidia's abuses of its monopoly.

generic_T 9y ago
I would definitely like to see more competition.