←back to thread

837 points turrini | 1 comments | | HN request time: 0.352s | source
Show context
busterarm ◴[] No.43971959[source]
Let's keep the CPU efficiency golf to Zachtronics games, please.

I/O is almost always the main bottleneck. I swear to god 99% of developers out there only know how to measure cpu cycles of their code so that's the only thing they optimize for. Call me after you've seen your jobs on your k8s clusters get slow because all of your jobs are inefficiently using local disk and wasting cycles waiting in queue for reads/writes. Or your DB replication slows down to the point that you have to choose between breaking the mirror and stop making money.

And older hardware consumes more power. That's the main driving factor between server hardware upgrades because you can fit more compute into your datacenter.

I agree with Carmack's assessment here, but most people reading are taking the wrong message away with them.

replies(3): >>43972051 #>>43972077 #>>43972235 #
wtetzner ◴[] No.43972051[source]
> I/O is almost always the main bottleneck.

People say this all the time, and usually it's just an excuse not to optimize anything.

First, I/O can be optimized. It's very likely that most servers are either wasteful in the number of requests they make, or are shuffling more data around than necessary.

Beyond that though, adding slow logic on top of I/O latency only makes things worse.

Also, what does I/O being a bottleneck have to do with my browser consuming all of my RAM and using 120% of my CPU? Most people who say "I/O is the bottleneck" as a reason to not optimize only care about servers, and ignore the end users.

replies(1): >>43972124 #
1. busterarm ◴[] No.43972124[source]
I/O _can_ be optimized. I know someone who had this as their fulltime job at Meta. Outside of that nobody is investing in it though.

I'm a platform engineer for a company with thousands of microservices. I'm not thinking on your desktop scale. Our jobs are all memory hogs and I/O bound messes. Across all of the hardware we're buying we're using maybe 10% CPU. Peers I talk to at other companies are almost universally in the same situation.

I'm not saying don't care about CPU efficiency, but I encounter dumb shit all the time like engineers asking us to run exotic new databases with bad licensing and no enterprise features just because it's 10% faster when we're nowhere near experiencing those kinds of efficiency problems. I almost never encounter engineers who truly understand or care about things like resource contention/utilization. Everything is still treated like an infinite pool with perfect 100% uptime, despite (at least) 20 years of the industry knowing better.