←back to thread

How We Found 7 TiB of Memory Just Sitting Around

(render.com)
205 points anurag | 4 comments | 30 Oct 25 18:25 UTC | HN request time: 0s | source
Show context
shanemhansen ◴[30 Oct 25 21:05 UTC] No.45765342[source]▶
The unreasonable effectiveness of profiling and digging deep strikes again.
replies(1): >>45776616 #
hinkley ◴[31 Oct 25 20:58 UTC] No.45776616[source]▶
The biggest tool in the performance toolbox is stubbornness. Without it all the mechanical sympathy in the world will go unexploited.

There’s about a factor of 3 improvement that can be made to most code after the profiler has given up. That probably means there are better profilers than could be written, but in 20 years of having them I’ve only seen 2 that tried. Sadly I think flame graphs made profiling more accessible to the unmotivated but didn’t actually improve overall results.

replies(4): >>45777180 #>>45777265 #>>45777691 #>>45783146 #
Negitivefrags ◴[31 Oct 25 22:11 UTC] No.45777265[source]▶
I think the biggest tool is higher expectations. Most programmers really haven't come to grips with the idea that computers are fast.

If you see a database query that takes 1 hour to run, and only touches a few gb of data, you should be thinking "Well nvme bandwidth is multiple gigabytes per second, why can't it run in 1 second or less?"

The idea that anyone would accept a request to a website taking longer than 30ms, (the time it takes for a game to render it's entire world including both the CPU and GPU parts at 60fps) is insane, and nobody should really accept it, but we commonly do.

replies(4): >>45777574 #>>45777649 #>>45777878 #>>45779600 #
azornathogron ◴[31 Oct 25 23:00 UTC] No.45777649[source]▶
Pedantic nit: At 60 fps the per frame time is 16.66... ms, not 30 ms. Having said that a lot of games run at 30 fps, or run different parts of their logic at different frequencies, or do other tricks that mean there isn't exactly one FPS rate that the thing is running at.
replies(1): >>45777794 #
1. Negitivefrags ◴[31 Oct 25 23:20 UTC] No.45777794[source]▶
The CPU part happens on one frame, the GPU part happens on the next frame. If you want to talk about the total time for a game to render a frame, it needs to count two frames.
replies(2): >>45778223 #>>45780533 #
2. wizzwizz4 ◴[01 Nov 25 00:34 UTC] No.45778223[source]▶
Computers are fast. Why do you accept a frame of lag? The average game for a PC from the 1980s ran with less lag than that. Super Mario Bros had less than a frame between controller input and character movement on the screen. (Technically, it could be more than a frame, but only if there were enough objects in play that the processor couldn't handle all the physics updates in time and missed the v-blank interval.)
replies(1): >>45778353 #
3. Negitivefrags ◴[01 Nov 25 00:58 UTC] No.45778353[source]▶
If Vsync is on which was my assumption from my previous comment, then if your computer is fast enough, you might be able to run CPU and GPU work entirely in a single frame if you use Reflex to delay when simulation starts to lower latency, but regardless, you still have a total time budget of 1/30th of a second to do all your combined CPU and GPU work to get to 60fps.
4. azornathogron ◴[01 Nov 25 10:12 UTC] No.45780533[source]▶
If latency of input->visible effect is what you're talking about, then yes, that's a great point!