Live data from Hacker News

CUDA-oxide: Nvidia's official Rust to CUDA compiler

nvlabs.github.io

91–100 of 132 posts

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#91
post #86

> (em dash) no DSLs, no foreign language bindings, just Rust. Official CUDA port and they couldn't even bother with the introductory paragraph. Okay, I'll try to ignore it and read the docs. Hey a custom IR, this sounds interesti- > MLIR’s implementation, however, is C++ with a side of TableGen, a build system that requires you to compile all of LLVM, and debugging sessions that make you question your career choices.…

I think the whole codebase was more or less written by AI...

that ship has long sailed, "it no longer matters" saying a codebase, an article was written with AI doesn't mean much, it could be good, it could be bad. folks often say it to generate outrage, but that means nothing. is the codebase great, good, bad, terrible? that's the only thing that matters.

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#93
post #86

Earlier quoted context omitted.

I think the whole codebase was more or less written by AI...

that ship has long sailed, "it no longer matters" saying a codebase, an article was written with AI doesn't mean much, it could be good, it could be bad. folks often say it to generate outrage, but that means nothing. is the codebase great, good, bad, terrible? that's the only thing that matters.

And an LLM-written codebase is strongly correlated with a terrible codebase. So much so, that it's rarely worth your time to seriously evaluate it.

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#94
https://nvlabs.github.io/cuda-oxide/gpu-safety/the-safety-mo...

> A GPU kernel runs thousands of threads that all see the same memory at the same time. On a CPU, Rust prevents data races through ownership and borrowing – one mutable reference, no aliases, enforced at compile time. On a GPU, you have 2048 threads per SM, all launched from the same function, all pointing at the same output buffer. The borrow checker was not designed for this.

> cuda-oxide solves the problem in layers. The common case – one thread writes one element – is safe by construction, no unsafe required. The uncommon cases – shared memory, warp shuffles, hardware intrinsics – require unsafe with documented contracts. And the frontier cases – TMA, tensor cores, cluster-level communication – are fully manual, matching the complexity of the hardware they control.

That's.. not really Rusty. In Rust, we create new safe abstractions when the existing ones don't quite map to the problem at hand. See for example what's done in Rust for Linux

If it's not safe.. what's the point of Rust?

(it's okay to offer unsafe APIs for people that need to squeeze the last bit of performance, but this shouldn't be the baseline)

I compare this with userspace libs for APIs like io_uring and vulkan. designing safe APIs for them stuff is kind of hard (there's even some unsound attempts)

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#95
post #86

Earlier quoted context omitted.

I think the whole codebase was more or less written by AI...

that ship has long sailed, "it no longer matters" saying a codebase, an article was written with AI doesn't mean much, it could be good, it could be bad. folks often say it to generate outrage, but that means nothing. is the codebase great, good, bad, terrible? that's the only thing that matters.

Even as someone who uses a lot of AI, if you can't be bothered to at least give it a prompt like "Go through the documentation and comments in detail and remove any obvious AI shibboleths like emdashes, it's not x it's y, rule-of-three, 'delve', excessive grandiosity and flourishes, boldness, bullet points, etc", you should receive a brisk kick in the rear.

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#96
post #86

Earlier quoted context omitted.

I think the whole codebase was more or less written by AI...

that ship has long sailed, "it no longer matters" saying a codebase, an article was written with AI doesn't mean much, it could be good, it could be bad. folks often say it to generate outrage, but that means nothing. is the codebase great, good, bad, terrible? that's the only thing that matters.

Might be the only thing that matters to you. And, perhaps, the only thing that matters in a functional sense. But, whether it’s human-coded/written or not matters deeply to some.

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#98

Earlier quoted context omitted.

if they didnt use AI for their webpage people would say "why doesnt NVIDIA write its website and documentation with AI? don't they believe their own story about AI factories and employees managing thousands of agents doing the work for them?" this is exactly on brand dog-fooding I would expect from an AI hyper

Literally no one would ever say that simply for editing the LLMisms away.

why would you edit them away? they are a signal that you are an "AI first" company

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#100

Earlier quoted context omitted.

that ship has long sailed, "it no longer matters" saying a codebase, an article was written with AI doesn't mean much, it could be good, it could be bad. folks often say it to generate outrage, but that means nothing. is the codebase great, good, bad, terrible? that's the only thing that matters.

Even as someone who uses a lot of AI, if you can't be bothered to at least give it a prompt like "Go through the documentation and comments in detail and remove any obvious AI shibboleths like emdashes, it's not x it's y, rule-of-three, 'delve', excessive grandiosity and flourishes, boldness, bullet points, etc", you should receive a brisk kick in the rear.

I'd be curious to know if there is a list of these "AI shibboleths" somewhere
Post reply on HN