Earlier quoted context omitted.
OpenCL and OpenGL are basically already scripting languages that you happen to type into a C compiler. The CUDA advantage was actually having meaningful types and compilation errors, without the intense boilerplate of Vulkan. But this is 100% a python-for-CUDA-C replacement on the GPU, for people who prefer a slightly different bracketing syntax.
> But this is 100% a python-for-CUDA-C replacement on the GPU Ish. It's a Python maths library made by Nvidia, an eDSL and a collection of curated libraries. It's not significantly different than stuff like Numpy, Triton, etc..., apart from being made by Nvidia and bundled with their tools.
Nvidia adds native Python support to CUDA
191–196 of 196 posts
Re: Nvidia adds native Python support to CUDA
#192Python is really shaping up to be the lingua franca of programming languages. Its adoption is soaring in this FOSS renaissance and I think it's the closest thing to a golden hammer that we've ever had. The PEP model is a good vehicle for self-improvement and standardization. Packaging and deployment will soon be solved problems thanks to projects such as uv and BeeWare, and I'm confident that we're going to see conti…
I think software engineers with any significant amount of experience recognize you can build an application that does X in just about any language. To me, the largest difference, the greatest factor in which language to choose, is the existing packages. Simple example- there are several packages in Python for extracting text from PDFs (using tesseract or not). C# has maybe one tesseract wrapper? I recall working with PDFs in .NET being a nightmare. I think we had to buy a license to some software because there wasn’t a free offering. Python has several.
This is VERY important because we as software engineers, even if we wanted to reinvent the wheel sometimes, have very limited time. It takes an obscene number of man hours to develop a SalesForce or a Facebook or even something smaller like a Linux distro.
Re: Nvidia adds native Python support to CUDA
#193Earlier quoted context omitted.
i’m curious what advantage is derived from this existing independently of the PTX stack? i.e. why doesn’t cuTile produce PTX via a bundled compiler like Triton or (iirc) Warp? Even if there is some impedance mismatch, could PTX itself not have been updated?
In the presentation they said eventually kernels can share SIMT (PTX) and TileIR but not at launch. It seems pretty mysterious why they don't just emit PTX, I would guess they are either taking the opportunity to clean things up for ML tensorcore workloads or there is some HW specific features coming that they only want to enable through TileIR.
Re: Nvidia adds native Python support to CUDA
#194Earlier quoted context omitted.
I want to write C code, not C++ code. Even if I try to write C style C++, it is more verbose and less readable, because of various C++isms. For example, having to specify extern “C” to get sane ABI names for the Nvidia CUDA driver API: https://docs.nvidia.com/cuda/cuda-driver-api/index.html Not to mention that C++ does not support neat features like variable sized arrays on the stack.
A neat feature that is so neat Google paid to get it irradicated from Linux kernel, and became optional after C11.
Re: Nvidia adds native Python support to CUDA
#195Re: Nvidia adds native Python support to CUDA
#196Earlier quoted context omitted.
The bad habits I was thinking about were more in the line of not understanding how memory is being used (even something as simple as stack vs. heap allocation), not having a type system that forces you to think about the types of data structure you have in your system, and overall just being forced to design before coding
Respectfully, many of those things aren't a concern from Python's point of view. And why should they be? If your program runs imperceptibly slower, or using an insignificant amount of extra memory, any attempts to fix this are considered a premature optimization that gets in the way of what is more important to pythonistas - developer experience and high level abstractions. Frankly, the comparison with Rust doesn't e…