Hmm wonder what vulnerabilities will now be available with this addition.
Nvidia adds native Python support to CUDA
141–150 of 196 posts
Re: Nvidia adds native Python support to CUDA
#142Earlier quoted context omitted.
CuPy has been available for years and has always worked great. The article is about the next wave of Python-oriented JIT toolchains, that will allow writing actual GPU kernels in a Pythonic-style instead of calling an existing precompiled GEMM implementation in CuPy (like in that snippet) or even JIT-ing CUDA C++ kernels from a Python source, that has also been available for years: https://docs.cupy.dev/en/stable/use…
it's funny - people around here really do not have a clue about the GPU ecosystem even though everyone is always talking about AI: > The article is about the next wave of Python-oriented JIT toolchains the article is content marketing (for whatever) but the actual product has literally has nothing to do with kernels or jitting or anything https://github.com/NVIDIA/cuda-python literally just cython bindings to CUDA ru…
The main release highlighted by the article is cuTile which is certainly about jitting kernels from Python code
Re: Nvidia adds native Python support to CUDA
#143Earlier quoted context omitted.
Isn't Rust still very seldomly used in the areas where CUDA shines (e.g. number crunching of any kind, let it be simulations or linear algebra)? Imo C++ or even Fortran are perfectly fine choices for those things, since the memory allocation pattern aren't that complicated.
Yes, and the new kid in town, slang has more chances of adoption.
sorry, could you link to the project? Seems there are quite a few languages called slang.
Re: Nvidia adds native Python support to CUDA
#144Earlier quoted context omitted.
> 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 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. here are the release notes
> Support Python 3.13
> Add bindings for nvJitLink (requires nvJitLink from CUDA 12.3 or above)
> Add optional dependencies on CUDA NVRTC and nvJitLink wheels
https://nvidia.github.io/cuda-python/latest/release/12.8.0-n...
do you understand what "bindings" and "optional dependencies on..." means? it means there's nothing happening in this library and these are... just bindings to existing libraries. specifically that means you cannot jit python using this thing (except via the python 3.13 jit interpreter) and can only do what you've always already been able to do with eg cupy (compile and run C/C++ CUDA code).
EDIT: y'all realize that
1. calling a compiler for your entire source file
2. loading and running that compiled code
is not at all a JIT? y'all understand that right?
Re: Nvidia adds native Python support to CUDA
#145Kind of late to the game, but can anyone recommend a good primer on GPU programming?
Re: Nvidia adds native Python support to CUDA
#146Earlier quoted context omitted.
it's funny - people around here really do not have a clue about the GPU ecosystem even though everyone is always talking about AI: > The article is about the next wave of Python-oriented JIT toolchains the article is content marketing (for whatever) but the actual product has literally has nothing to do with kernels or jitting or anything https://github.com/NVIDIA/cuda-python literally just cython bindings to CUDA ru…
The main release highlighted by the article is cuTile which is certainly about jitting kernels from Python code
> main release
there is no release of cutile (yet). so the only substantive thing that the article can be describing is cuda-core - which it does describe and is a recent/new addition to the ecosystem.
man i can't fathom glazing a random blog this hard just because it's tangentially related to some other thing (NV GPUs) that clearly people only vaguely understand.
Re: Nvidia adds native Python support to CUDA
#147Very curious how this compares to JAX [1]. JAX lets you write Python code that executes on Nvidia, but also GPUs of other brands (support varies). It similarly has drop-in replacements for NumPy functions. This only supports Nvidia. But can it do things JAX can't? It is easier to use? Is it less fixed-size-array-oriented? Is it worth locking yourself into one brand of GPU? [1] https://github.com/jax-ml/jax
Well, the idea is that you’d be writing low level CUDA kernels that implement operations not already implemented by JAX/CUDA and integrate them into existing projects. Numba[1] is probably the closest thing I can think of that currently exists. (In fact, looking at it right now, it seems this effort from Nvidia is actually based on Numba)
[1]: https://numba.readthedocs.io/en/stable/cuda/overview.html
Re: Nvidia adds native Python support to CUDA
#148Earlier quoted context omitted.
Yes, and the new kid in town, slang has more chances of adoption.
sorry, could you link to the project? Seems there are quite a few languages called slang.
I guess he might mean this one https://shader-slang.org/ though at first glance at least it looks more graphics than GPGPU oriented.
Edit: Hmm, this part of the same project looks general purpose-y and apparently integrates with PyTorch https://slangpy.shader-slang.org/en/latest/
Re: Nvidia adds native Python support to CUDA
#149Earlier 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…
> 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. here are the release notes
Those aren't the release notes for the native python thing being announced. CuTile has not been publicly released yet. Based on what the devs are saying on Twitter it probably won't be released before the SciPy 2025 conference in July.
Re: Nvidia adds native Python support to CUDA
#150Earlier quoted context omitted.
Isn't Rust still very seldomly used in the areas where CUDA shines (e.g. number crunching of any kind, let it be simulations or linear algebra)? Imo C++ or even Fortran are perfectly fine choices for those things, since the memory allocation pattern aren't that complicated.
Mainly because number crunching code tends to be very long-lived (hence why FORTRAN is still in use).
Not only that. Fortran is very good for writing number-crunching code. Modern Fortran is a pretty ergonomic language, it gives you a really easy way to auto-parallelize things in many ways, and new Fortran code is being produce unironically. Of course it normally uses the treasure trove of existing numerical Fortran code. (Source: a friend who worked at CERN.)