Live data from Hacker News

What every developer should know about GPU computing

codeconfessions.substack.com

171–180 of 186 posts

Re: What every developer should know about GPU computing

#171
post #28

Now I understand why ML uses floats for precision. It wasn't a choice, it was because graphics code uses them. Another piece in the "why is ML so inefficient" puzzle! I wonder what that memory copying overhead is IRL. If it's like normal stuff it'll be brutal. I mean, they offload tcp processing into hardware to avoid that. This is way more data, though it is done in bigger chunks.

Floats are bigger, and math with them is more difficult.

But really, I wondered why the cpu-bound LLMs do quantization, which from what I understand is the process of reducing the precision of the weights to use less memory.

Does the lack of precision make a difference? It's unclear. If that's the case, then why use FP at all? If precision doesn't matter, then the extra precision is just making the process use more resources for no real reason. And likely orders of magnitude more resources than required.

I mean, this field wasn't started by people who understood performance. They used tools and built something...but there's no 'why.' This is what the tools did, so they did that.

Here's why that might be important: on a normal CPU, accessing data one way can be orders of magnitude faster than another way...but you have to be aware. Would you like to reduce your LLM costs by orders of magnitude?

Re: What every developer should know about GPU computing

#172
post #44

Why are they still called GPU? PPU (Parallel Processing Unit) sounds like a better name.

Because everybody understands what you mean when you say GPU. Same with drone versus quad-copter, etc...

We still call smartphones phones but hardly use the phone functionality.

Re: What every developer should know about GPU computing

#173

Earlier quoted context omitted.

For anyone that needs to know how a CPU works for performance engineering similar to a GPU, the details of the microarchitecture matter a lot even within the same ISA. I am not aware of any formal CS program that teaches anyone the nuanced internals of various microarchitecture designs. Everyone I know with this knowledge appears to be self-taught regardless of where they went to school. I think the descriptor “intim…

I am really curious about what kind of optimizations are enabled when you know the microarchitectural design of various CPUs, but without writing assembly by hand. I only know the basics such as optimizing data structure for better cache locality, add some fast paths, manual unrolling, but have no idea about how to work around things like pipeline stalls. It would be really helpful if you can point to some materials…

The basic principle is that a CPU core is a complex distributed system with varying degrees of parallelism, concurrency, and latency as all of these components communicate with each other. The design of this distributed system varies across microarchitectures as do the available features. Analyzing the optimal codegen is similar to analyzing optimal algorithm design in higher level distributed systems with a fixed hardware specification.

Compilers are good at finding very local optimizations targeting specific microarchitectures. If you use godbolt and switch out the architecture flags you can see how the codegen changes.

However, as with higher level code, the compiler can’t rewrite your data structures or see patterns spread across too much code. As a simple example, modern cores have 4+ concurrent ALUs with different capabilities. Some of those ALUs are usually idle if there are not enough independent instructions or independent instructions are too far away from the current instruction. You can see large performance improvements simply by reorganizing your C code so that the compiler and CPU can see more opportunities to use more ALUs in parallel. Interestingly, a lot of these code changes are trivial no-ops at the code semantics level, but they bring the ALU concurrency opportunity within view of the CPU.

There is an active niche community on the Internet that studies how various instruction sequences interact with various microarchitectures. This is probably the best resource because a lot of detail is not well documented by the CPU companies themselves. It requires a fair amount of experimentation to develop an intuition for how code will run on a given CPU at this level of detail.

Re: What every developer should know about GPU computing

#174

Earlier quoted context omitted.

Completely true. The analogy to hydration holds, I think -- too much and too little can both be problematic. But I see seem to run into much more under-specialization than over-specialization. More than 90% of the wildest successes I know went really deep on something pretty narrow.

Specialization is like putting everything on one number in roulette. It's great if you win (i.e. your specialty is in demand), but you're more likely to lose everything you invested.

It is a risk, but not as bad as you suggest, because (1) in work you can get an incremental sense of what is worth specializing in, and (2) there's always some degree to which skills are transferrable and experience is impressive even to someone who doesn't need you to do what you did again.

Re: What every developer should know about GPU computing

#175
post #101

Earlier quoted context omitted.

> and they were not from some rich family that could have paid their way through schooling Huh? If they'd got private tutoring, that wouldn't make them understand things any less?

The suggestion is that they got there on merit, intelligence, hard work. Not family influence, money, low key corruption in support of the academic career of an idiot.

It just seems like a very low resolution view of the world. Getting through on family influence is vanishingly rare, to my understanding.

Re: What every developer should know about GPU computing

#176

SIMD programming is f---ing wild. Want to run a calculation for every pixel on your screen? No problem. Want to have a branching condition? Ouchie.

To be fair, this makes sense: making a smart decision is "harder" than scaling a simple calculation out to a bunch of workers.

Re: What every developer should know about GPU computing

#177
post #151

Earlier quoted context omitted.

As of Volta, they have independent PCs with a warp optimizer that dynamically groups threads with the same program counter, so branches aren’t nearly as bad as they used to be.

Can you cite a reference explaining this ability to re-form new warps from existing threads? I ask because I’ve seen posts from NVIDIA support saying that divergence is still very expensive and I’ve also seen benchmarks that force divergence in each warp by evenly splitting the warp, and the benchmarks result in 2x runtime when that happens vs. when the control-flow is dynamically uniform. One thing to keep in mind i…

"Divergence is still very expensive" is quite compatible with "Divergence is less expensive than before".

Here's evidence (not proof) that Nvidia would remove the hard limit of warp divergence (or perhaps more "precisely", *a warp is always synchronous across its 32 threads with divergence"): https://developer.nvidia.com/blog/cooperative-groups/

I don't think it's misleading to talk about a "CUDA core" as a warp-wide processor, although it seems that Nvidia doubles the number (at least for gaming GPUs), presumably because of having both FP and INT pathways.

Re: What every developer should know about GPU computing

#178

One thing I don’t understand is how the architecture of Apple Silicon is different from NVidia’s. Looking at this quote: > the Nvidia H100 GPU has 132 SMs with 64 cores per SM, totalling a whopping 8448 cores. 8448 cores sure sounds impressive. But the Apple M2 Ultra only has 76 cores?! How can the NVidia H100 GPU have over 110x more cores? Clearly it doesn’t have 110x more performance over the M2 Ultra, so what is g…

For one thing you can use the H100 to heat a room - it uses more than 10x the power of an M2 Ultra.

Consider AMD Epyc 7742 vs an A100 -- 225W vs 400W (according to some TDP numbers). That's 1.8x-2.0x increase in energy, but something like 10x-100x more integer operations per second (depending on size of integers, depending on if you count the tensor cores or not).

Re: What every developer should know about GPU computing

#179
post #101

Earlier quoted context omitted.

The suggestion is that they got there on merit, intelligence, hard work. Not family influence, money, low key corruption in support of the academic career of an idiot.

It just seems like a very low resolution view of the world. Getting through on family influence is vanishingly rare, to my understanding.

George W. Bush. Hilary Clinton.

Legacy admissions exist.

There are of course a million other ways people fail upwards.

Re: What every developer should know about GPU computing

#180

Earlier quoted context omitted.

Can you cite a reference explaining this ability to re-form new warps from existing threads? I ask because I’ve seen posts from NVIDIA support saying that divergence is still very expensive and I’ve also seen benchmarks that force divergence in each warp by evenly splitting the warp, and the benchmarks result in 2x runtime when that happens vs. when the control-flow is dynamically uniform. One thing to keep in mind i…

"Divergence is still very expensive" is quite compatible with "Divergence is less expensive than before". Here's evidence (not proof) that Nvidia would remove the hard limit of warp divergence (or perhaps more "precisely", *a warp is always synchronous across its 32 threads with divergence"): https://developer.nvidia.com/blog/cooperative-groups/ I don't think it's misleading to talk about a "CUDA core" as a warp-wide…

Their “CUDA core” is not warp-wide, it’s a single lane.

If you’re talking about FP32 rates, they double it because of FMA (floating-point multiply-accumulate). Everyone does that.

Post reply on HN