8 ms·

Compiling Rust for GPUs

79 points by AndrewDucker 13y ago

okpatil 13y ago
That's great. This would be an edge over Golang. Go community has been working with similar problem for some time https://groups.google.com/forum/#!topic/golang-nuts/8OJ6etdl6WY https://groups.google.com/forum/#!topic/golang-nuts/8OJ6etdl...
- pcwalton 13y ago
  I don't know how many times I have to say "Rust and Go are not competing and are in totally different spaces" before it sinks in. This only works because Rust is a low-level design that does not rely on garbage collection; Go is a high-level design.
  - Pxtl 13y ago
    Because Go pretends to be in the same space as Rust even though nobody actually uses it that way.
    - zellyn 13y ago
      No, it doesn't. http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential...
  - okpatil 13y ago
    I don't think you read the thread properly. It's mentioned here, https://groups.google.com/d/msg/golang-nuts/8OJ6etdl6WY/0FKMVa1UpccJ https://groups.google.com/d/msg/golang-nuts/8OJ6etdl6WY/0FKM..., that you could access cuda architecture with golang. And as mentioned here http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential..., golang was designed to replace c++. Any modern language which gives flexibility for both high and low level use would live, if you don't think so, go and advertise assembly. If rust gives cuda and http-server, one could easily design a project like this http://www.rescale.com http://www.rescale.com.
electrograv 13y ago
This is very cool. I really hope that GPU programming becomes increasingly tightly integrated into more languages over time. If we could reach a point where every major compiler has GPU support built into the language itself, it would be so much easier for a thriving ecosystem of libraries and other supporting software to emerge (not that this doesn't exist already, but right now it's mostly divided into different groups for each GPU vendor, sadly). Unfortunately the GPU vendor divide still exists (mainly CUDA for NVIDIA, and OpenCL for AMD/Intel) with no immediately obvious solution. For example even the Rust-to-PTX compiler from this article will fail if you try to run it on AMD, or Intel, or anything but NVIDIA because PTX is an NVIDIA-only pseudo-assembly intermediate format. Projects like "gpuocelot" promise to translate PTX to run on other GPUs, but until such translation layers reach maturity (and don't sacrifice any performance in the process of translation), OpenCL will remain the only viable "intermediate" format that is truly GPU-agnostic. Which is really a shame, because quite frankly OpenCL is horrible to develop for multiple GPUs, because each GPU vendor has their own OpenCL compiler with a slightly different interpretation of the spec (not to mention severe performance differences between OpenCL and CUDA for NVIDIA GPUs), plus their own proprietary extensions. It's like writing C code that has to run on N different, immature, and mostly quirky compilers all with their own different subset of features, where N is completely unknown to you -- in fact N will grow over time after you release your application.
- pjmlp 13y ago
  You forgot Renderscript for Android. Google doesn't seem very keen in supporting OpenCL.
- foxhill 13y ago
  i don't understand what's horrible about OpenCL for all the vendors? aside from beta platforms, i've had all my codes work across platforms that claim to support the full profile. also, gpuocelot is a terrible idea. it's a reimplementation of a closed standard, entirely controlled by nvidia. it will always be catching up to CUDA. the thing is, we already have a portable binary solution in OpenCL, SPIR. it's just a dialect of llvm-ir, in fact. projects like this (that use CUDA/closed standards) are just deepening the divide between the GPU vendors, and moves us away from a single open standard.
foxhill 13y ago
i'm glad to see that GPUs are becoming more accessible! given that they use OpenCL to run kernels, i'm really confused to see that they're compiling kernels to PTX, and not just intermediary OpenCL C. that way they could run on any OpenCL supporting device. in the future, i would hope to at least see SPIR used in place of PTX.
salient 13y ago
Does the Rust team take into account what AMD and ARM are trying to do with HSA? What about the changes in OpenCL 2.0? I think they should keep them in mind now before their Rust design spec is finalized, and if possible, try to optimize for them, too.
- foxhill 13y ago
  better yet, use SPIR and OpenCL. HSA is polluting the GPGPU space, along with CUDA. we need less proprietary crap, and more open standards.
  - pjmlp 13y ago
    HSA is a standard like many other in the industry. OpenCL cannot offer what CUDA does in terms of tooling.
    - foxhill 13y ago
      there are far fewer vendors behind HSA than SPIR. AMD and ARM seem to be pushing it hard (and argue it compliments rather than competes with SPIR). but it's just muddying the waters. hmm, you'll need to be specific about what OpenCL lacks, as there are a lot of tools out there (and a lot of them support CUDA as well)
      - pjmlp 13y ago
        > there are far fewer vendors behind HSA than SPIR. AMD and ARM seem to be pushing it hard (and argue it compliments rather than competes with SPIR). but it's just muddying the waters. It will also be the official GPGPU for Java. > hmm, you'll need to be specific about what OpenCL lacks, as there are a lot of tools out there (and a lot of them support CUDA as well) Ability to write kernels in C++, Fortran or any other language that targets PTX.
  - salient 13y ago
    What's not open about HSA? If Intel and Nvidia haven't joined it (yet) doesn't mean it's not open. Nvidia treats OpenCL as 2nd class citizen compared to CUDA anyway, and I don't think Intel is that interested in OpenCL anymore, now that they have Phi. So if neither party is too interested in OpenCL, then I'd rather have HSA than the actual proprietary CUDA/Phi solutions.
antonyme 13y ago
This article is about a year old by now. Since then, a significant amount of progress has been made. Full details are available in this research paper published at the HIPS conference this year. http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf This describes in some detail how they used the PTX backend and linked the host and GPU to perform matrix operations and so forth. Awesome stuff!
Pxtl 13y ago
I really feel like game development is the ideal space for Rust to carve out a name for itself, and going after GPU support is a great place to focus.

79 points by AndrewDucker 13y ago

That's great. This would be an edge over Golang. Go community has been working with similar problem for some time https://groups.google.com/forum/#!topic/golang-nuts/8OJ6etdl6WY https://groups.google.com/forum/#!topic/golang-nuts/8OJ6etdl...

pcwalton 13y ago
I don't know how many times I have to say "Rust and Go are not competing and are in totally different spaces" before it sinks in. This only works because Rust is a low-level design that does not rely on garbage collection; Go is a high-level design.
- Pxtl 13y ago
  Because Go pretends to be in the same space as Rust even though nobody actually uses it that way.
  - zellyn 13y ago
    No, it doesn't. http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential...
- okpatil 13y ago
  I don't think you read the thread properly. It's mentioned here, https://groups.google.com/d/msg/golang-nuts/8OJ6etdl6WY/0FKMVa1UpccJ https://groups.google.com/d/msg/golang-nuts/8OJ6etdl6WY/0FKM..., that you could access cuda architecture with golang. And as mentioned here http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential..., golang was designed to replace c++. Any modern language which gives flexibility for both high and low level use would live, if you don't think so, go and advertise assembly. If rust gives cuda and http-server, one could easily design a project like this http://www.rescale.com http://www.rescale.com.

electrograv 13y ago

This is very cool. I really hope that GPU programming becomes increasingly tightly integrated into more languages over time. If we could reach a point where every major compiler has GPU support built into the language itself, it would be so much easier for a thriving ecosystem of libraries and other supporting software to emerge (not that this doesn't exist already, but right now it's mostly divided into different groups for each GPU vendor, sadly). Unfortunately the GPU vendor divide still exists (mainly CUDA for NVIDIA, and OpenCL for AMD/Intel) with no immediately obvious solution. For example even the Rust-to-PTX compiler from this article will fail if you try to run it on AMD, or Intel, or anything but NVIDIA because PTX is an NVIDIA-only pseudo-assembly intermediate format. Projects like "gpuocelot" promise to translate PTX to run on other GPUs, but until such translation layers reach maturity (and don't sacrifice any performance in the process of translation), OpenCL will remain the only viable "intermediate" format that is truly GPU-agnostic. Which is really a shame, because quite frankly OpenCL is horrible to develop for multiple GPUs, because each GPU vendor has their own OpenCL compiler with a slightly different interpretation of the spec (not to mention severe performance differences between OpenCL and CUDA for NVIDIA GPUs), plus their own proprietary extensions. It's like writing C code that has to run on N different, immature, and mostly quirky compilers all with their own different subset of features, where N is completely unknown to you -- in fact N will grow over time after you release your application.

pjmlp 13y ago
You forgot Renderscript for Android. Google doesn't seem very keen in supporting OpenCL.
foxhill 13y ago
i don't understand what's horrible about OpenCL for all the vendors? aside from beta platforms, i've had all my codes work across platforms that claim to support the full profile. also, gpuocelot is a terrible idea. it's a reimplementation of a closed standard, entirely controlled by nvidia. it will always be catching up to CUDA. the thing is, we already have a portable binary solution in OpenCL, SPIR. it's just a dialect of llvm-ir, in fact. projects like this (that use CUDA/closed standards) are just deepening the divide between the GPU vendors, and moves us away from a single open standard.

foxhill 13y ago

i'm glad to see that GPUs are becoming more accessible! given that they use OpenCL to run kernels, i'm really confused to see that they're compiling kernels to PTX, and not just intermediary OpenCL C. that way they could run on any OpenCL supporting device. in the future, i would hope to at least see SPIR used in place of PTX.

salient 13y ago

Does the Rust team take into account what AMD and ARM are trying to do with HSA? What about the changes in OpenCL 2.0? I think they should keep them in mind now before their Rust design spec is finalized, and if possible, try to optimize for them, too.

foxhill 13y ago
better yet, use SPIR and OpenCL. HSA is polluting the GPGPU space, along with CUDA. we need less proprietary crap, and more open standards.
- pjmlp 13y ago
  HSA is a standard like many other in the industry. OpenCL cannot offer what CUDA does in terms of tooling.
  - foxhill 13y ago
    there are far fewer vendors behind HSA than SPIR. AMD and ARM seem to be pushing it hard (and argue it compliments rather than competes with SPIR). but it's just muddying the waters. hmm, you'll need to be specific about what OpenCL lacks, as there are a lot of tools out there (and a lot of them support CUDA as well)
    - pjmlp 13y ago
      > there are far fewer vendors behind HSA than SPIR. AMD and ARM seem to be pushing it hard (and argue it compliments rather than competes with SPIR). but it's just muddying the waters. It will also be the official GPGPU for Java. > hmm, you'll need to be specific about what OpenCL lacks, as there are a lot of tools out there (and a lot of them support CUDA as well) Ability to write kernels in C++, Fortran or any other language that targets PTX.
- salient 13y ago
  What's not open about HSA? If Intel and Nvidia haven't joined it (yet) doesn't mean it's not open. Nvidia treats OpenCL as 2nd class citizen compared to CUDA anyway, and I don't think Intel is that interested in OpenCL anymore, now that they have Phi. So if neither party is too interested in OpenCL, then I'd rather have HSA than the actual proprietary CUDA/Phi solutions.

antonyme 13y ago

This article is about a year old by now. Since then, a significant amount of progress has been made. Full details are available in this research paper published at the HIPS conference this year. http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf This describes in some detail how they used the PTX backend and linked the host and GPU to perform matrix operations and so forth. Awesome stuff!

Pxtl 13y ago

I really feel like game development is the ideal space for Rust to carve out a name for itself, and going after GPU support is a great place to focus.