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

How We Found 7 TiB of Memory Just Sitting Around

render.com

Post reply on HN
Print view View original

11–20 of 76 posts

Re: How We Found 7 TiB of Memory Just Sitting Around

#11

Post by avidiax »

javier2 wrote: post #9
Negitivefrags wrote: post #8

Earlier quoted context omitted.

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…

its also about cost. My game computer has 8 cores + 1 expensive gpu + 32GB ram for me alone. We dont have that per customer.

It's also about revenue.

Uber could run the complete global rider/driver flow from a single server.

It doesn't, in part because all of those individual trips earn $1 or more each, so it's perfectly acceptable to the business to be more more inefficient and use hundreds of servers for this task.

Similarly, a small website taking 150ms to render the page only matters if the lost productivity costs less than the engineering time to fix it, and even then, only makes sense if that engineering time isn't more productively used to add features or reliability.

Re: How We Found 7 TiB of Memory Just Sitting Around

#12

Post by jesse__ »

hinkley wrote: post #5
shanemhansen wrote: post #2

The unreasonable effectiveness of profiling and digging deep strikes again.

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 access…

Broadly agree.

I'm curious, what're the profilers you know of that tried to be better? I have a little homebrew game engine with an integrated profiler that I'm always looking for ideas to make more effective.

Re: How We Found 7 TiB of Memory Just Sitting Around

#13

Post by oivey »

javier2 wrote: post #9
Negitivefrags wrote: post #8

Earlier quoted context omitted.

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…

its also about cost. My game computer has 8 cores + 1 expensive gpu + 32GB ram for me alone. We dont have that per customer.

This is again a problem understanding that computers are fast. A toaster can run an old 3D game like Quake at hundreds of FPS. A website primarily displaying text should be way faster. The reasons websites often aren’t have nothing to do with the user’s computer.

Re: How We Found 7 TiB of Memory Just Sitting Around

#14

Post by Negitivefrags »

azornathogron wrote: post #10
Negitivefrags wrote: post #8

Earlier quoted context omitted.

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…

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.

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.

Re: How We Found 7 TiB of Memory Just Sitting Around

#15

Post by hinkley »

Negitivefrags wrote: post #8
hinkley wrote: post #5

Earlier quoted context omitted.

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 access…

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…

Lowered expectations are come in part from people giving up on theirs. Accepting versus pushing back.

Re: How We Found 7 TiB of Memory Just Sitting Around

#16

Post by hinkley »

zahlman wrote: post #7
hinkley wrote: post #5

Earlier quoted context omitted.

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 access…

> The biggest tool in the performance toolbox is stubbornness. Without it all the mechanical sympathy in the world will go unexploited. The sympathy is also needed. Problems aren't found when people don't care, or consider the current performance acceptable. > 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 coul…

Architecture, cache eviction, memory bandwidth, thermal throttling.

All of which have gotten perhaps an order of magnitude worse in the time since I started on this theory.

Re: How We Found 7 TiB of Memory Just Sitting Around

#17

Post by antonymoose »

hinkley wrote: post #15
Negitivefrags wrote: post #8

Earlier quoted context omitted.

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…

Lowered expectations are come in part from people giving up on theirs. Accepting versus pushing back.

I have high hopes and expectations, unfortunately my chain of command does not, and is often an immovable force.

Re: How We Found 7 TiB of Memory Just Sitting Around

#18

Post by hinkley »

jesse__ wrote: post #12
hinkley wrote: post #5

Earlier quoted context omitted.

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 access…

Broadly agree. I'm curious, what're the profilers you know of that tried to be better? I have a little homebrew game engine with an integrated profiler that I'm always looking for ideas to make more effective.

Clinic.js tried and lost steam. I have a recollection of a profiler called JProfiler that represented space and time as a graph, but also a recollection they went under. And there is a company selling a product of that name that has been around since that time, but doesn’t quite look how I recalled and so I don’t know if I was mistaken about their demise or I’ve swapped product names in my brain. It was 20 years ago which is a long time for mush to happen.

The common element between attempts is new visualizations. And like drawing a projection of an object in a mechanical engineering drawing, there is no one projection that contains the entire description of the problem. You need to present several and let brain synthesize the data missing in each individual projection into an accurate model.

Re: How We Found 7 TiB of Memory Just Sitting Around

#19

Post by paulryanrogers »

oivey wrote: post #13
javier2 wrote: post #9

Earlier quoted context omitted.

its also about cost. My game computer has 8 cores + 1 expensive gpu + 32GB ram for me alone. We dont have that per customer.

This is again a problem understanding that computers are fast. A toaster can run an old 3D game like Quake at hundreds of FPS. A website primarily displaying text should be way faster. The reasons websites often aren’t have nothing to do with the user’s computer.

That's a dedicated toaster serving only one client. Websites usually aren't backed by bare metal per visitor.

Re: How We Found 7 TiB of Memory Just Sitting Around

#20

Post by oivey »

paulryanrogers wrote: post #19
oivey wrote: post #13

Earlier quoted context omitted.

This is again a problem understanding that computers are fast. A toaster can run an old 3D game like Quake at hundreds of FPS. A website primarily displaying text should be way faster. The reasons websites often aren’t have nothing to do with the user’s computer.

That's a dedicated toaster serving only one client. Websites usually aren't backed by bare metal per visitor.

Right. I’m replying to someone talking about their personal computer.
Post reply on HN