Personally I really don't want new GPU languages that do not have AD as a first class citizen. I mean rust is an improvement over C++ CUDA but still.
CUDA-oxide: Nvidia's official Rust to CUDA compiler
41–50 of 132 posts
Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler
#42Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler
#43Re: Rust (and "safe" programming languages). Does anyone have more details on NVIDIAs use of Spark/Ada? All I can find is what's listed below: https://www.adacore.com/case-studies/nvidia-adoption-of-spar...
Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler
#44Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler
#45Earlier quoted context omitted.
But also the majority of programmers?
In AI-focused fields like business analytics and data science, yeah.
Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler
#46All software can come on three editions. Stainless drivers that were never rusty, oxidized drivers that used Rust on existing code, and Iron editions which is where someone converted the Rust back to C using the new phosphoric tool...
Diversity can be our strength.
Making Iron C/c++ code can be called acid washing if it was rusted.
Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler
#47Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler
#48Personally I really don't want new GPU languages that do not have AD as a first class citizen. I mean rust is an improvement over C++ CUDA but still.
This isn't a new GPU language; it's a lib which might replace FFI and third party libs.
Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler
#49I'm quite interested in how they dealt with Rust's memory model, which might not neatly map to CUDA's semantics. Curious what the differences are compared to CUDA C++, and if the Rust's type system can actually bring more safety to CUDA (I do think writing GPU kernels is inherently unsafe, it's just too hard to create a safe language because of how the hardware works, and because of the fact that you're hyper-optimiz…
1. use-after-free, drop semantics vs manual cudaFree
2. kernel args enforced using `cuda_launch!` whereas CPP void* args is just an array of pointers, validating count only
3. alias mutable writes. e.g. CPP can have more than one thread writing out[i] with same i and this will compile. but DisjointSlice with ThreadIndex doesnt have any public constructor (see: https://github.com/NVlabs/cuda-oxide/blob/2a03dfd9d5f3ecba52...) and only using API of `index_1d` `index_2d` and `index_2d_runtime`
4. im pretty sure you can cuda memcpy a std::string and literally any other POD and "corrupt" its state making it unusable. here it ONLY accepts DisjointSlice, scalars, and closures (https://nvlabs.github.io/cuda-oxide/gpu-programming/memory-a...)
but most of the nitty gritty is in these sections
* https://nvlabs.github.io/cuda-oxide/gpu-safety/the-safety-mo...
* https://nvlabs.github.io/cuda-oxide/gpu-programming/memory-a...
edit: that being said, not like this catch everything, just looks to give much more guardrails against UB with raw .cu files
Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler
#50So, we have stainless, which means Linux code that never rusted. Now we need someone to make phosphorus so that we can turn rusty code into old iron. Then GPL fans can run Rust boxes, Stainless machines, or future proofed iron work horses. All software can come on three editions. Stainless drivers that were never rusty, oxidized drivers that used Rust on existing code, and Iron editions which is where someone convert…
> Then GPL fans can
Checks out