Live data from Hacker News

What every developer should know about GPU computing

codeconfessions.substack.com

101–110 of 186 posts

Re: What every developer should know about GPU computing

#101

Earlier quoted context omitted.

Yup, I was coming up under a senior at my work one day and he tried to very incorrectly hand wave how a browser uses a GPU to accelerate draw calls. I had done work in the C/C++ code modifying Chromium directly and went, “that’s not how the browser talks to the OS to use the GPU for acceleration”. They immediately tried to argue I was wrong and made some more nonsense up. This person is a very competent coder, but we…

> 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.

Re: What every developer should know about GPU computing

#102
post #70

Earlier quoted context omitted.

The Ur subject of philosophy is not the writing and reading of philosophy, but to exercise the mind in coming to grips with that which we have no conception of yet. Language is it's medium, and the IO is those texts. However the nugget at the center is figuring out that magic blackbox that lets you take all the dead ends in those texts and divine a reasonable guiding principle or recognition of an end to the space of…

The Tao Te Ching opens with almost exactly that subject... though, of course, it also makes you think about it a while first to understand what it's getting at.

Aha, nice connection! I'm a fan of the Tao Te Ching but never would've caught that one my own. Thx!

Re: What every developer should know about GPU computing

#103
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...

To be pedantic, a quadcopter is a drone, but a drone is not necessarily a quadcopter.

Re: What every developer should know about GPU computing

#104
post #47

>Most programmers have an intimate understanding of CPUs maybe this article is brilliant, but when the first line is something so blatantly untrue it really makes it hard to take the rest seriously

Definitely not true about most programmers, but maybe the author meant CS educated engineers. Going through a formal CS program will give you an intimate understanding of CPUs, especially when compared to the very light coverage of GPUs.

"Going through a formal CS program will give you an intimate understanding of CPUs

and 101 other hilarious jokes you can tell yourself!"

Re: What every developer should know about GPU computing

#105

This article is pretty good but, looking at comments so far, nobody seems to have made the obvious/predictable point that it's terribly Nvidia specific. That would be understandable perhaps a few years ago. But the era where there was no reasonable alternative is over. Sycl is a good language which performs well across multiple hardware vendors. Sapphire rapids is very good hardware. AMD's MI300 looks amazing. Nvidia…

At this point the massive investment in software is what drives this, hardware differences may no longer be dominant but the only way to unseat NV at this point is drop in replacements and/or drop in replacement libraries. And that's getting there. Which is good because GPUs are too expensive and have too little memory, some competition might help move things along rather than to give NV more time to milk their precious digital cows.

Re: What every developer should know about GPU computing

#106

>> Most programmers have an intimate understanding of CPUs I'd say the mental model for most programmers is: lines of text, in their language of choice, zipping by really fast.

By the time you're looking at using GPUs my assumption would be that you've left that particular mental model behind long ago.

Re: What every developer should know about GPU computing

#107

I think GPU computing should not be done in application layer. It's way too low-level.

That's the only layer where it makes sense because that's where you know what it is that you are trying to achieve. The overhead in GPU programming is such that if you make one small assumption that doesn't hold true in practice you may end up sinking your performance in a terrible way. So you need a lot of control over where and how things are laid out. For more generic stuff there are libraries, but those too run at the behest of your application. As this technology matures you'll see more and more abstraction and automation of the parts that squeeze out the most performance. But for now that's where you can make the biggest gains, just like any other kind of special purpose co-processor.

Re: What every developer should know about GPU computing

#108

I thought I'd share something with my experience with HPC that applies to many areas, especially in the rise of GPUs. The main bottleneck isn't compute, it is memory. If you go to talks you're gonna see lots of figures like this one[0] (typically also showing disk speeds, which are crazy small). Compute is increasing so fast that at this point we finish our operations long faster than it takes to save those simulatio…

Agreed, the memory bottle-neck is the biggest restriction. But even there there is quite a bit of progress. NV in particular is milking that for as much and as long as they can though. I'd be happy with a slower GPU able to address far more memory.

Re: What every developer should know about GPU computing

#110

Earlier quoted context omitted.

Vector Processing Unit would be more appropriate.

Why stop there? Matrix Processing Unit or Tensor Processing Unit if you want to trigger the physicists or are a fan of the google cloud.

Those are a different thing (which may be part of a GPU, e.g., Nvidia's Tensor Cores, or separate, e.g., Apple Neural Engine.)
Post reply on HN