4 ms·

All the Spark GPU acceleration right now is done via the Spark-RAPIDS plugin, so HIP would somehow have to support that. Since cuDF is the core part and hipDF i

All the Spark GPU acceleration right now is done via the Spark-RAPIDS plugin, so HIP would somehow have to support that. Since cuDF is the core part and hipDF is a thing, it might be doable in the near future.

latchkey 1y ago
Oh, interesting! Thanks for the additional context. This is one area where it is clear that Nvidia is a leader by not only providing the underlying kernels, but also the overall product framework integrations. One would have to port that entire plugin project over, which would probably be a ton of work to maintain. For what it is worth, AMD just recently released two blog posts on hipDF, so at least they are putting that effort in. https://rocm.blogs.amd.com/artificial-intelligence/cupy_hipdf_portfolio_opt/README.html https://rocm.blogs.amd.com/artificial-intelligence/cupy_hipd... https://rocm.blogs.amd.com/artificial-intelligence/hipDF_pandas_accelerated/README.html https://rocm.blogs.amd.com/artificial-intelligence/hipDF_pan...
- winwang 1y ago
  Thanks for the links! I'm planning on contributing kernels back to open source, so will think of a way to be vendor agnostic. As far as I understand, HIP should make that doable.
  - latchkey 1y ago
    hipify attempts to do that, but it potentially requires you to maintain two source trees, which isn't optimal. In this case, you'd want to run a CI/CD to convert your CUDA code at build time and compile that. But I think there are edge cases where that isn't possible. As you learned at the event, Modular is trying to make it more transparent by abstracting to a whole new language (Mojo). Another solution coming down the line which doesn't require changes to your CUDA code, nor learning a new language is: https://docs.scale-lang.com/ https://docs.scale-lang.com/
    - winwang 1y ago
      Thanks for the link! Not the first time I came across it, but it's a good one. If I had to bet on the longer term, I think that something like Mojo will win out -- a programming language (mostly) agnostic to the underlying vector processor hardware. Similar to how Rust can target various SIMD implementations, though I've only dabbled in that.

latchkey 1y ago

Oh, interesting! Thanks for the additional context. This is one area where it is clear that Nvidia is a leader by not only providing the underlying kernels, but also the overall product framework integrations. One would have to port that entire plugin project over, which would probably be a ton of work to maintain. For what it is worth, AMD just recently released two blog posts on hipDF, so at least they are putting that effort in. https://rocm.blogs.amd.com/artificial-intelligence/cupy_hipdf_portfolio_opt/README.html https://rocm.blogs.amd.com/artificial-intelligence/cupy_hipd... https://rocm.blogs.amd.com/artificial-intelligence/hipDF_pandas_accelerated/README.html https://rocm.blogs.amd.com/artificial-intelligence/hipDF_pan...

winwang 1y ago
Thanks for the links! I'm planning on contributing kernels back to open source, so will think of a way to be vendor agnostic. As far as I understand, HIP should make that doable.
- latchkey 1y ago
  hipify attempts to do that, but it potentially requires you to maintain two source trees, which isn't optimal. In this case, you'd want to run a CI/CD to convert your CUDA code at build time and compile that. But I think there are edge cases where that isn't possible. As you learned at the event, Modular is trying to make it more transparent by abstracting to a whole new language (Mojo). Another solution coming down the line which doesn't require changes to your CUDA code, nor learning a new language is: https://docs.scale-lang.com/ https://docs.scale-lang.com/
  - winwang 1y ago
    Thanks for the link! Not the first time I came across it, but it's a good one. If I had to bet on the longer term, I think that something like Mojo will win out -- a programming language (mostly) agnostic to the underlying vector processor hardware. Similar to how Rust can target various SIMD implementations, though I've only dabbled in that.