Nvidia adds native Python support to CUDA • Hacker News Board

Re: Nvidia adds native Python support to CUDA

#151

Post by wahnfrieden » Sat, Apr 05, 2025, 12:16 AM UTC

almostgotcaught wrote: post #144

dragonwriter wrote: post #113

Earlier quoted context omitted.

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

> 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. my guy what i am able to read, which you are not, is the source and release notes. i do not need to read tweets and press releases because i know what these things actually are. her…

[flagged]

Re: Nvidia adds native Python support to CUDA

#152

Post by no_wizard » Sat, Apr 05, 2025, 12:18 AM UTC

What makes Python such a target for these kind of things?

I've noticed alot of projects add Python support like this. Does the Python codebase allow for it to compile down to different targets easier than others?

Re: Nvidia adds native Python support to CUDA

#153

Post by no_wizard » Sat, Apr 05, 2025, 12:26 AM UTC

SJC_Hacker wrote: post #134

matt3210 wrote: post #88

We should find a new word since GPU is is from back when it was used for graphics.

General Processing Unit Greater Processing Unit Giant Processing Unit

Couple more thoughts:

Galloping Processing Unit

Grape Processing Unit

Gorge Processing Unit

Gaggle Processing Unit

Grand Processing Unit

Giraffe Processing Unit

Gaping Processing Unit

Re: Nvidia adds native Python support to CUDA

#154

Post by thegabriele » Sat, Apr 05, 2025, 12:40 AM UTC

system2 wrote: post #119

thegabriele wrote: post #59

Could pandas benefit from this integration?

What do you have in mind that Pandas will benefit from cuda cores?

I'm absolutely not a pro coder, i just crunch numbers and i would love to see some improvements speed-wise in dataframe operations.

Re: Nvidia adds native Python support to CUDA

#155

Post by thegabriele » Sat, Apr 05, 2025, 12:48 AM UTC

ashvardanian wrote: post #91

thegabriele wrote: post #59

Could pandas benefit from this integration?

Check out CuDF. I've mentioned them in another comment on this thread.

It seems already a mature and seamless solution. Thank you

Re: Nvidia adds native Python support to CUDA

#156

Post by jdeaton » Sat, Apr 05, 2025, 12:54 AM UTC

Pytorch???

Re: Nvidia adds native Python support to CUDA

#157

Post by bee_rider » Sat, Apr 05, 2025, 12:58 AM UTC

nickysielicki wrote: post #115

bee_rider wrote: post #114

Earlier quoted context omitted.

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

Sure, it’s easy to say “there are bigger problems.” There are always bigger problems.

But, there are like 50 years worth of Fortran numerical codes out there, lots of them just use RCIs… if I want to try CUDA in some existing library, I guess I will need the vector back before I can go back into the RCI.

Re: Nvidia adds native Python support to CUDA

#158

Post by cavisne » Sat, Apr 05, 2025, 1:01 AM UTC

skavi wrote: post #78

btown wrote: post #40

The GTC 2025 announcement session that's mentioned in this article has video here: https://www.nvidia.com/en-us/on-demand/session/gtc25-s72383/ It's a holistic approach to all levels of the stack, from high-level frameworks to low-level bindings, some of which is highlighting existing libraries, and some of which are completely newly announced. One of the big things seems to be a brand new Tile IR, at the level of PT…

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

#159

Post by greenavocado » Sat, Apr 05, 2025, 1:07 AM UTC

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…

If you are trying to do Ruby but fast you're supposed to use Crystal

Re: Nvidia adds native Python support to CUDA

#160

Post by alanfranz » Sat, Apr 05, 2025, 1:33 AM UTC

ImprobableTruth wrote: post #103

claytonjy wrote: post #79

Earlier quoted context omitted.

I’ve always thought it was weird GPU stuff in python doesn’t use asyncio, and mostly assumed it was because python-on-GPU predates asyncio. But I was hoping a new lib like this might right that wrong, but it doesn’t. Maybe for interop reasons? Do other languages surface the asynchronous nature of GPUs in language-level async, avoiding silly stuff like synchronize?

The reason is that the usage is completely different from coroutine based async. With GPUs you want to queue _as many async operations as possible_ and only then synchronize. That is, you would have a program like this (pseudocode): b = foo(a) c = bar(b) d = baz(c) synchronize() With coroutines/async await, something like this b = await foo(a) c = await bar(b) d = await baz(c) would synchronize after every step, bein…

Well you can and should create multiple coroutine/tasks and then gather them. If you replace cuda with network calls, it’s exactly the same problem. Nothing to do with asyncio.