Live data from Hacker News

Nvidia announces native GPU programming in Rust

developer.nvidia.com

361–370 of 383 posts

Re: Nvidia announces native GPU programming in Rust

#361
post #245
post #236

Earlier quoted context omitted.

> I've found sorta the opposite - in any area, it can just do everything for you, or it can be an incredible teacher. Please don't. I've had all of Codex, Claude and Gemini convincingly tell me absolutely wrong stuff, pointing it out with easily verifiable example they come up with more and more weird reasons. Things don't become correct simply because most sources are again - easily and logically verifiable - wrong.…

> Please don't. I will. Can these be wrong? Certainly. So can humans. Many of your examples are of humans being wrong. That doesn't make LLMs - or humans - useless. The fact that they are not infallible is not a reason to avoid using them and I'm not going to throw out a tool that has been incredibly valuable to me because someone on the internet got some bad CORS advice.

There is another option. Going to the source of information (eg. the official project site or code), trying stuff yourself.

Re: Nvidia announces native GPU programming in Rust

#362

Earlier quoted context omitted.

You could also use Mojo, one language for all targets.

Or julia if you want a much more mature ecosystem.

I fell in love with MATLAB (or GNU Octave for free since you really pay for toolboxes/packages) back around 2004, despite it warts. So I second Julia, which is similar, but is a more modern functional language instead of imperative.

I asked Google's Gemini if Julia can run on GPU unmodified without annotations, pragmas, intrinsics or similar manually-managed friction, and it said yes, but that data types must be swapped out for GPU-backed types:

If your code is written using vector/matrix operations, broadcasting, or standard linear algebra functions, it can run on the GPU entirely unmodified. You only need to change the input data type to a GPU-backed array (e.g., swapping a CPU Array for a CuArray from CUDA.jl).

  # A standard Julia function — completely agnostic to hardware
  function custom_math!(C, A, B)
      @. C = sin(A) + 2 * B  # Normal broadcasted operation
  end
  
  # Running on the CPU:
  A_cpu = rand(1000)
  B_cpu = rand(1000)
  C_cpu = similar(A_cpu)
  custom_math!(C_cpu, A_cpu, B_cpu)
  
  # Running on the GPU (Unmodified function!):
  using CUDA
  A_gpu = CuArray(A_cpu)
  B_gpu = CuArray(B_cpu)
  C_gpu = similar(A_gpu)
  
  custom_math!(C_gpu, A_gpu, B_gpu) # Automatically compiles to native PTX!
https://cuda.juliagpu.org/stable/

This is the direction we should be going. So while Nvidia's Rust port is an important first step, it's an evolutionary rather than revolutionary achievement. But that's all Nvidia can really do now, since it's locked into its own paradigm like Intel/Microsoft and has gotten too big to think outside the box.

Edit: PTX in its example stands for Parallel Thread Execution, the Virtual Machine (VM) Instruction Set Architecture (ISA) created by NVIDIA for its GPUs, which works similarly to Java byte code.

Edit 2: Broadcasting is a feature in Julia that allows you to apply a function or mathematical operation element-by-element across arrays of different shapes and sizes, without writing manual loops. In Julia, broadcasting is syntactically indicated by a dot (.) placed before an operator or function name (e.g., sin.(x) or .+). <- I was today years old when I learned the term for this

Re: Nvidia announces native GPU programming in Rust

#363
post #176
post #151

Earlier quoted context omitted.

I don't really have any opinion on your tone; I just still don't agree with your framing. A lack of evidence would be neutral like "there's no evidence to indicate either possibility is more likely", but your phrasing conveyed that one possibility was more likely than the other. I pushed back against your follow-up because it seemed like you were arguing for a higher threshold of evidence than you provided.

Well, to be fair, you're correct. I am asking for a higher threshold of evidence. It's a stronger claim. I feel a stronger claim deserves stronger evidence.

I guess that's where we disagree. I feel like either claim is equally hard to falsify from the outside (partially because I've never had much confidence in my ability to spot whether text is from an LLM outside of the most glaringly obvious cases, and likewise don't have any clue whether people who have high confidence are accurate or deluding themselves).

Re: Nvidia announces native GPU programming in Rust

#364
post #281

Earlier quoted context omitted.

> If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection. Not even close to being true. You can invoke syscalls directly, just needs a bit of reverse engineering. I wrote a bare metal libc library, with (not a whole lot of) effort I'm fully able to interface with…

The problem is much deeper than that. Most OSes' syscall ABIs are not stable and could change without warning. What is stable is the dynamically-loaded libraries, shipped as part of the system. Linux is the notable exception here; the Linux kernel project doesn't ship a libc, and Linus is very famously opposed to "breaking userspace." There's nothing that can stop you from using syscalls in theory, but if you want yo…

https://blog.hiler.eu/win32-the-only-stable-abi/

Re: Nvidia announces native GPU programming in Rust

#365

Earlier quoted context omitted.

I certainly dislike how everyone on YouTube is saying “SA” and “unalive” and “corn”. It’s one thing if it’s some funny commentary channel avoiding those words, but what bothers me is the true crime YouTubers. In the subject of true crime, rape and murder are just things that are probably going to come up, and when they refuse to use the appropriate language, it comes off as infantilizing, which is weird considering t…

I don't think those filters are even real, I think it's just mass-hysteria. I call these kinds of behaviours "traditions", but I'm not sure if there's a better term for it. Basically someone comes up with something which is nonsensical, but plausible. Like believing that their videos are unpopular because they said the word "rape" and the algorithm magically got them, rather than because their videos suck. Then someo…

No it isn't mass hysteria. YouTube has a set advertiser friendly guideline. It will scan uploads and streams automatically.

YouTube used to demonetise profanity unless it was mild. YouTube would demonetise profanity in the first X number of seconds of the video. These rules change and have been relaxed of April last year, but generally these rules still exist.

There isn't a hard filter if you say "suicide" you automatically get it. However it increases the likely hood of demonetisation. So people avoid it to be safe. So you end up with people using stupid euphemisms all the time.

Re: Nvidia announces native GPU programming in Rust

#367
post #359

Okay, so, GPUs are taking one more step towards being general purpose massively parallel machines. That's cool. What would be even cooler though would be for GPU vendors to start giving us the user manual. An I mean the real user manual, that explains how to use their piece of metal when all you have is that piece of metal . That means a precise description of the wire protocols, the data format of the buffers we sen…

They don't release it because exposing a stable instruction set would kill their ability to quickly iterate, to release silicon with bugs that can be papered over with software fixes, as fixing bugs in chips is very expensive in terms of time to market, and undoubtedly to charge more for what looks like a hardware feature but actually is a software feature. It's been this way for 25 years and I don't see it changing.

A stable instruction set would be nice.

But hi, if I spent $10,000 on a piece of hardware, let me program the metal, thanks.

Re: Nvidia announces native GPU programming in Rust

#368

Okay, so, GPUs are taking one more step towards being general purpose massively parallel machines. That's cool. What would be even cooler though would be for GPU vendors to start giving us the user manual. An I mean the real user manual, that explains how to use their piece of metal when all you have is that piece of metal . That means a precise description of the wire protocols, the data format of the buffers we sen…

> GPUs are taking one more step towards being general purpose massively parallel machines

this has nothing to do with becoming more general purpose (GPUs will never be general purpose - it's literally physically impossible).

Re: Nvidia announces native GPU programming in Rust

#369
post #359

Okay, so, GPUs are taking one more step towards being general purpose massively parallel machines. That's cool. What would be even cooler though would be for GPU vendors to start giving us the user manual. An I mean the real user manual, that explains how to use their piece of metal when all you have is that piece of metal . That means a precise description of the wire protocols, the data format of the buffers we sen…

They don't release it because exposing a stable instruction set would kill their ability to quickly iterate, to release silicon with bugs that can be papered over with software fixes, as fixing bugs in chips is very expensive in terms of time to market, and undoubtedly to charge more for what looks like a hardware feature but actually is a software feature. It's been this way for 25 years and I don't see it changing.

How is this different than CPUs? I suppose in the last 5 years the architecture and tape has changed a lot as they move to make more LLM capable?

Re: Nvidia announces native GPU programming in Rust

#370
post #281

Earlier quoted context omitted.

If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection.

> If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection. Not even close to being true. You can invoke syscalls directly, just needs a bit of reverse engineering. I wrote a bare metal libc library, with (not a whole lot of) effort I'm fully able to interface with…

That’s insane. Windows does not have a stable syscall ABI. The way you’re supposed to interact with the kernel is through the userspace library. Of course the kernel team refuses to cooperate.

Do you want to keep reverse engineering the syscall ABI for every Windows edition and update ever? Do you want to ask your users to disable Windows Update?

Regardless, I don’t even understand how that’s relevant, since you’re still introducing a dependency on a proprietary ABI.

Post reply on HN