Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nvidia adds native Python support to CUDA

thenewstack.io

Post reply on HN
Print view View original

111–120 of 196 posts

Re: Nvidia adds native Python support to CUDA

#111

Post by IshKebab »

whycome wrote: post #52
chrisrodrigue wrote: post #47

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…

Would you say Python is a good language to learn as a beginner?

I would personally recommend Javascript/Typescript over Python, but Python is a reasonable option. Especially now that we have uv so you don't have to crawl through the bush of thorns that Python's terrible tooling (pip, venv etc) surrounds you with.

I would just encourage you to move on from Python fairly quickly. It's like... a balance bike. Easy to learn and teach you how to balance but you don't want to actually use it to get around.

Re: Nvidia adds native Python support to CUDA

#112

Post by nickysielicki »

bee_rider wrote: post #107
nickysielicki wrote: post #102

Earlier quoted context omitted.

I don’t mean to call you or your pseudocode out specifically, but I see this sort of thing all the time, and I just want to put it out there: PSA: if you ever see code trying to measure timing and it’s not using the CUDA event APIs, it’s fundamentally wrong and is lying to you. The simplest way to be sure you’re not measuring noise is to just ban the usage of any other timing source. Definitely don’t add unnecessary…

If I have a mostly CPU code and I want to time the scenario: “I have just a couple subroutines that I am willing to offload to the GPU,” what’s wrong with sprinkling my code with normal old python timing calls? If I don’t care what part of the CUDA ecosystem is taking time (from my point of view it is a black-box that does GEMMs) so why not measure “time until my normal code is running again?”

If you care enough to time it, you should care enough to time it correctly.

Re: Nvidia adds native Python support to CUDA

#113

Post by dragonwriter »

almostgotcaught wrote: post #100
dragonwriter wrote: post #77

Earlier quoted context omitted.

The mistake you seem to be making is confusing the existing product (which has been available for many years) with the upcoming new features for that product just announced at GTC, which are not addressed at all on the page for the existing product, but are addressed in the article about the GTC announcement.

> The mistake you seem to be making is confusing the existing product i'm not making any such mistake - i'm just able to actually read and comprehend what i'm reading rather than perform hype: > Over the last year, NVIDIA made CUDA Core, which Jones said is a “Pythonic reimagining of the CUDA runtime to be naturally and natively Python.” so the article is about cuda-core, not whatever you think it's about - so i'm re…

> i'm just able to actually read and comprehend what i'm reading rather than perform hype:

The evidence of that is lacking.

> so the article is about cuda-core, not whatever you think it's about

cuda.core (a relatively new, rapidly developing, library whose entire API is experimental) is one of several things (NVMath is another) mentioned in the article, but the newer and as yet unreleased piece mentioned in the article and the GTC announcement, and a key part of the “Native Python” in the headline, is the CuTile model [0]:

“The new programming model, called CuTile interface, is being developed first for Pythonic CUDA with an extension for C++ CUDA coming later.”

> this is bullshit/hype about Python's new JIT

No, as is is fairly explicit in the next line after the one you quote, it is about the Nvidia CUDA Python toolchain using in-process compilation rather than relying on shelling out to out-of-process command-line compilers for CUDA code.

[0] The article only has fairly vague qualitative description of what CuTile is, but (without having to watch the whole talk from GTC), one could look at this tweet for a preview of what the Python code using the model is expected to look like when it is released: https://x.com/blelbach/status/1902113767066103949?t=uihk0M8V...

Re: Nvidia adds native Python support to CUDA

#114

Post by bee_rider »

nickysielicki wrote: post #112
bee_rider wrote: post #107

Earlier quoted context omitted.

If I have a mostly CPU code and I want to time the scenario: “I have just a couple subroutines that I am willing to offload to the GPU,” what’s wrong with sprinkling my code with normal old python timing calls? If I don’t care what part of the CUDA ecosystem is taking time (from my point of view it is a black-box that does GEMMs) so why not measure “time until my normal code is running again?”

If you care enough to time it, you should care enough to time it correctly.

I described the correct way to time it when using the card as a black-box accelerator.

Re: Nvidia adds native Python support to CUDA

#115

Post by nickysielicki »

bee_rider wrote: post #114
nickysielicki wrote: post #112

Earlier quoted context omitted.

If you care enough to time it, you should care enough to time it correctly.

I described the correct way to time it when using the card as a black-box accelerator.

You can create metrics for whatever you want! Go ahead!

But cuda is not a black box math accelerator. You can stupidly treat it as such, but that doesn’t make it that. It’s an entire ecosystem with drivers and contexts and lifecycles. If everything you’re doing is synchronous and/or you don’t mind if your metrics include totally unrelated costs, then time.time() is fine, sure. But if that’s the case, you’ve got bigger problems.

Re: Nvidia adds native Python support to CUDA

#116

Post by squeaky-clean »

almostgotcaught wrote: post #100
dragonwriter wrote: post #77

Earlier quoted context omitted.

The mistake you seem to be making is confusing the existing product (which has been available for many years) with the upcoming new features for that product just announced at GTC, which are not addressed at all on the page for the existing product, but are addressed in the article about the GTC announcement.

> The mistake you seem to be making is confusing the existing product i'm not making any such mistake - i'm just able to actually read and comprehend what i'm reading rather than perform hype: > Over the last year, NVIDIA made CUDA Core, which Jones said is a “Pythonic reimagining of the CUDA runtime to be naturally and natively Python.” so the article is about cuda-core, not whatever you think it's about - so i'm re…

Isn't the main announcement of the article CuTile? Which has not been released yet.

Also the cuda-core JIT stuff has nothing to do with Python's new JIT, it's referring to integrating nvJitLink with python, which you can see an example of in cuda_core/examples/jit_lto_fractal.py

Re: Nvidia adds native Python support to CUDA

#117

Post by EnergyAmy »

lenerdenator wrote: post #33
DeathArrow wrote: post #18

>In 2024, Python became the most popular programming language in the world — overtaking JavaScript — according to GitHub’s 2024 open source survey. I wonder why Python take over the world? Of course, it's easy to learn, it might be easy to read and understand. But it also has a few downsides: low performance, single threaded, lack of static typing.

I do backend web server development using FastAPI/Starlette and Django. If I were a Ruby developer, I'd be using Rails, and I'd also be describing 90% of Ruby development. However, I do Python. What I'm describing is a tiny fraction of Python development. If you want to do something with computer code - data analysis, ML, web development, duct-taping together parts of a #NIX system, even some game development - you c…

There's the pithy saying that "Python is the second-best language for anything", and that's kind of its superpower.

Re: Nvidia adds native Python support to CUDA

#118

Post by system2 »

airstrike wrote: post #76
whycome wrote: post #52

Earlier quoted context omitted.

Would you say Python is a good language to learn as a beginner?

As someone who spent nearly a decade with Python, I'd say 90% of people will answer "yes", so I'd like to offer a different perspective. IMHO if you want to pick it up for a couple toy projects just to get a feel of what coding is like, then by all means try it out. But eventually you'll benefit tremendously from exploring other languages. Python will teach you a lot of bad habits. You will feel like you know what yo…

With the help of GPT, I think the bad habit part is non-existent anymore. Learning it from GPT really helps people nowadays. Ask ChatGPT 4.0 some questions, and you will be shocked by how well it describes the code.

Just don't ask to fix indentations because it will do it line by line for hours. But it finds mistakes quickly and points you in the right direction.

And of course, it comes up with random non-existent modules once in a while which is cute to me.

Re: Nvidia adds native Python support to CUDA

#120

Post by system2 »

WhereIsTheTruth wrote: post #73

python is the winner, turning pseudo code into interesting stuff it's only the beginning, there is no need to create new programming languages anymore

I heard the same thing about Ruby, Go, TypeScript, and Rust. (Even JS at one point when NodeJS was super popular a few years ago).

There will be new shiny things, but of course, my choice is Python too.

Post reply on HN