Live data from Hacker News

Nvidia adds native Python support to CUDA

thenewstack.io

191–196 of 196 posts

Re: Nvidia adds native Python support to CUDA

#191

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.

I’m mainly interested in the performance implications. The less shit between me and the hardware, theoretically the better the performance. In a world where these companies want to build nuclear power plants just to power NVIDIA GPU data centers, I feel like we need to be optimizing the code where possible.

Re: Nvidia adds native Python support to CUDA

#192

Python 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 haven’t run into anything where Python either couldn’t be used or shouldn’t be used, except for the browser of course.

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

#193
post #78

Earlier 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.

if i were to lean into cynicism, i might suggest this choice was meant to increase the effort required to reimplement cuda for other cards.

Re: Nvidia adds native Python support to CUDA

#194
post #179
post #127

Earlier 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.

I think you replied to the wrong person.

Re: Nvidia adds native Python support to CUDA

#196

Earlier 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…

Except it's not imperceptibly slower, it's orders of magnitude slower.
Post reply on HN