Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What every developer should know about GPU computing

codeconfessions.substack.com

Post reply on HN
Print view View original

91–100 of 186 posts

Re: What every developer should know about GPU computing

#91

Post by eropple »

yieldcrv wrote: post #39
softfalcon wrote: post #32

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…

> I was coming up under a senior at my work one day > It really threw me for a loop as to what a software engineer needs to know to succeed at very high levels professionally he is arguably more successful while you have prematurely optimized do things that make money, since that’s clearly the priority and context here

> he is arguably more successful while you have prematurely optimized

Sure--until he isn't. And that happens north of "senior".

I've had a lot of I-shaped people reporting to and taking direction from me in my career, and I'm not as deep at any one thing as many of them. But I'm deeper at a lot of things than most of those folks, and I can synthesize solutions to more complex problems because of them. Heck, things I learned writing games in my teens still come up on occasion twenty years later.

Re: What every developer should know about GPU computing

#93

Post by kylebarron »

qwertox wrote: post #80

Let's assume I have an array of 10.000 lat/lng-pairs. I want to compute the length of the track. I duplicate the array and remove the first item in the duplicated array, append the last entry of the original array to the duplicate in order for them to be equal in length. Then I use a vectorized haversine algorithm on these arrays to obtain a third one with the distances between each "row" of the two arrays. With NumP…

10,000 coordinates are certainly not enough to see the difference, but at some scale this would be faster on the GPU.

This is implemented in an nvidia geospatial library call cuspatial: https://docs.rapids.ai/api/cuspatial/legacy/api_docs/spatial...

Re: What every developer should know about GPU computing

#94

Post by galangalalgol »

crooked-v wrote: post #84
galangalalgol wrote: post #79

Earlier quoted context omitted.

Are most programmers self trained now? I can see if someone self trains for fe or even full stack with an eye on compensation, they wouldn't understand program counters and the like. But so many people seem motivated by video games to get into the industry that I'd expect them to be reading about things like the fast inverse square root or similar.

A lot of game dev now happens in high-level engines, often with their own extra layer of scripting engine. Even working on the nitty-gritty of spatial logic rather than using engine-based colliders/detection would be pretty rare.

So are we really losing knowledge or just specializing ever more down the fractal?

Re: What every developer should know about GPU computing

#95

Post by nine_k »

01100011 wrote: post #45

> Copying Data from Host to Device Surprised there's no mention of async copies here. If you want to get the most out of the GPU, you don't want it idle when copying data between the host and the GPU. Many frameworks provide for a mechanism to schedule async copies which can execute along side async work submission. The post is sort of GPU 101 but there's a whole world of tricks and techniques beyond that once you st…

Since you likely use 64-bit (double) floats, not every GPU would help much, especially compared to a beefy CPU.

But if you use a GPU with a large number of FP64 units, it may speed things up a lot. These are generally not gaming GPUs, but if you have a 4060 sitting around anyway, it has about 300 GFLOPS FP64 performance, likely more than your CPU. Modern CPUs are mighty in this regard though, able to issue many FP64 operations per clock per core.

Re: What every developer should know about GPU computing

#96

Post by ghosty141 »

yieldcrv wrote: post #39
softfalcon wrote: post #32

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…

> I was coming up under a senior at my work one day > It really threw me for a loop as to what a software engineer needs to know to succeed at very high levels professionally he is arguably more successful while you have prematurely optimized do things that make money, since that’s clearly the priority and context here

Senior seems to be lacking knowledge that OP has and acts like it. No matter his backstory he shouldve acknowledged his defieceny. Since OP seems to be newer in the industry comparing success isnt really fair, he might make it out on top in the future, we dont know.

Re: What every developer should know about GPU computing

#97

Post by fancyfredbot »

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 has run out of GPUs. It's finally time for GPU development to stop meaning CUDA, but I guess it's going to take the world a while to realise this.

Re: What every developer should know about GPU computing

#98

Post by c2lsZW50 »

galangalalgol wrote: post #94
crooked-v wrote: post #84

Earlier quoted context omitted.

A lot of game dev now happens in high-level engines, often with their own extra layer of scripting engine. Even working on the nitty-gritty of spatial logic rather than using engine-based colliders/detection would be pretty rare.

So are we really losing knowledge or just specializing ever more down the fractal?

I believe the answer is depends, but there were some interesting discussions today under an article which relates to this.

https://news.ycombinator.com/item?id=37965142

Re: What every developer should know about GPU computing

#99

Post by diimdeep »

Also check out this talk and slides from few years ago about CPU and GPU nitpicks

Alexander Titov — Know your hardware: CPU memory hierarchy https://youtu.be/QOJ2hsop6hM

https://github.com/alexander-titov/public/blob/master/confer...

Know Your Hardware - CPU Memory Hierarchy -- Alexander Titov -- C%2B%2B Moscow Meetup March 2019.pdf

https://github.com/alexander-titov/public/blob/master/confer...

GPGPU - what it is and why you should care -- Alexander Titov -- CoreHard 2019.pdf

Re: What every developer should know about GPU computing

#100

Post by hombre_fatal »

galangalalgol wrote: post #94
crooked-v wrote: post #84

Earlier quoted context omitted.

A lot of game dev now happens in high-level engines, often with their own extra layer of scripting engine. Even working on the nitty-gritty of spatial logic rather than using engine-based colliders/detection would be pretty rare.

So are we really losing knowledge or just specializing ever more down the fractal?

I think it's just that you don't need to be intimate with lower level details to deliver more value at higher levels like game and application dev.

If your day to day involves "intimate knowledge with the CPU" and bumping program counters, I can rule out a lot of things that you probably aren't building, like a compelling iOS app or forum HTTP server, for example.

Maybe you're doing impressive work on emulators or something though. But it's nothing to get pompous about just because other people don't share that interest.

We too easily go off careening into a circlejerk.

Post reply on HN