About 8 years ago an NVIDIA developer released a tool called Copperhead that let you write CUDA kernels in straight Python that were then compiled to C, no "C-in-a-string" like is shown here. I always thought it was so elegant and had great potential, and I introduced a lot of people in my circle to it, but then it seems NVIDIA buried it. This blog post is great, and we need these kind of tools for sure, but we also…
I’m so glad you liked it. It was a labor of love and I was super proud of it. Means a lot to me that you would still remember it. I flatter myself to think that some ideas from that project have lived on in Tensorflow and PyTorch, etc. But the project itself wrapped up when I decided to focus on DL, and it would take a lot of work to bring it back to life.
Unifying the CUDA Python Ecosystem
51–60 of 62 posts
Re: Unifying the CUDA Python Ecosystem
#52Re: Unifying the CUDA Python Ecosystem
#53Earlier quoted context omitted.
I think the contrast is probably less about the language, and more about the scope and objective of the projects. the blog is describing low-level interfaces in python - probably more comparable is the old CUDAdrv.jl package (now merged into CUDA.jl): https://github.com/JuliaGPU/CUDAdrv.jl/blob/master/examples/... here is writing a similar kernel in python with numba: https://github.com/ContinuumIO/gtc2017-numba/blob…
I gave numba CUDA a spin in late 2018 and was severely disappointed. It didn't work out of the box, I had to tweak the source to remove a reference to an API that had been removed from CUDA more than a year prior (and deprecated long ago). Then I ran into a bug when converting a float array to a double array -- I had to declare the types three different times and it still did a naive byte-copy rather than a conversio…
Re: Unifying the CUDA Python Ecosystem
#54I have a RTX 2070 that's under-utilised, partly because I'm surprisingly finding it hard to understand C, C++ and CUDA by extension. I'm self-taught, and have been using web languages and some python, before learning Rust. I hope that NVIDIA can dedicate some resources to creating high-quality bindings to the C API for Rust, even if in the next 1-2 years. Perhaps being able to use a systems language that's been easy…
A nice thing of the proper ALGOL linage systems programming languages (which C only has basic influence), is that you can write nice high level code and only deal with pointers and raw pointer stuff when actually needed, think Ada, Modula-2, Object Pascal kind of languages. So something like CUDA Rust would be nice to have. By the way, D already supports CUDA, https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-nat…
Re: Unifying the CUDA Python Ecosystem
#55Re: Unifying the CUDA Python Ecosystem
#56Earlier quoted context omitted.
A nice thing of the proper ALGOL linage systems programming languages (which C only has basic influence), is that you can write nice high level code and only deal with pointers and raw pointer stuff when actually needed, think Ada, Modula-2, Object Pascal kind of languages. So something like CUDA Rust would be nice to have. By the way, D already supports CUDA, https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-nat…
CUDA Ada would be so, so nice. Especially with non-aliasing guarantees from SPARK...
Re: Unifying the CUDA Python Ecosystem
#57About 8 years ago an NVIDIA developer released a tool called Copperhead that let you write CUDA kernels in straight Python that were then compiled to C, no "C-in-a-string" like is shown here. I always thought it was so elegant and had great potential, and I introduced a lot of people in my circle to it, but then it seems NVIDIA buried it. This blog post is great, and we need these kind of tools for sure, but we also…
Re: Unifying the CUDA Python Ecosystem
#58About 8 years ago an NVIDIA developer released a tool called Copperhead that let you write CUDA kernels in straight Python that were then compiled to C, no "C-in-a-string" like is shown here. I always thought it was so elegant and had great potential, and I introduced a lot of people in my circle to it, but then it seems NVIDIA buried it. This blog post is great, and we need these kind of tools for sure, but we also…
I’m so glad you liked it. It was a labor of love and I was super proud of it. Means a lot to me that you would still remember it. I flatter myself to think that some ideas from that project have lived on in Tensorflow and PyTorch, etc. But the project itself wrapped up when I decided to focus on DL, and it would take a lot of work to bring it back to life.
Re: Unifying the CUDA Python Ecosystem
#59Earlier quoted context omitted.
In the IP world, there are some-hidden gems that disappear with no trace one day. I worked for a client that had this wonderful Python dsl that compiled to Verilog and VHDL. It was much easier to use than writing the stuff the old way. Much more composable too, not to mention tooling. They created that by forking an open source project dating back to Python 2.5 that I could never find again. Imagine if that stuff wou…
Sounds like nmigen might be a good open source successor to the project that you describe: https://github.com/nmigen/nmigen There are lots of open-source (n)migen components available through the litex framework: https://github.com/enjoy-digital/litex