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.
Nvidia announces native GPU programming in Rust
361–370 of 379 posts
Re: Nvidia announces native GPU programming in Rust
#362Earlier quoted context omitted.
You could also use Mojo, one language for all targets.
Or julia if you want a much more mature ecosystem.
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
#363Earlier 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.
Re: Nvidia announces native GPU programming in Rust
#364Earlier 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…
Re: Nvidia announces native GPU programming in Rust
#365Earlier 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…
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
#366Re: Nvidia announces native GPU programming in Rust
#367Okay, 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.
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
#368Okay, 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…
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
#369Okay, 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.
Re: Nvidia announces native GPU programming in Rust
#370Earlier 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…
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.