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

The Great CPU Stagnation

databasearchitects.blogspot.com

Post reply on HN
Print view View original

171–180 of 222 posts

Re: The Great CPU Stagnation

#171

Post by bluedino »

whynotmaybe wrote: post #133
didgetmaster wrote: post #129

Earlier quoted context omitted.

It would be nice if every developer had to run their latest build on 10 year old hardware while testing it out. Instead of their high-powered development machine with the latest CPU, tons of high speed memory, and the fastest SSD; they would get to experience what many of their customers have to endure on slower hardware with capacity constraints. Nothing spurs optimization like seeing first hand how your code creeps…

Don't say it too loud, friend of mine worked at a company where everyone had the same computer. I5 Gen 3, 500g HDD and 8gig of ram. Yes, outlook runs fine for the secretary, visual studio not so fine for debugging.

I worked at a place like that, brought in RAM and SSD from home

Re: The Great CPU Stagnation

#172

Post by bluedino »

didgetmaster wrote: post #129
lynx23 wrote: post #44

The perfect time to shed ourselves of the idea that "optimisation is a waste of dev-time". Mobile computing was the last godsent t actually rethink performance a little bit, but we still have a lot of relatively low-hanging fruit. I sometimes dream about a month-of-no-new-features, where everyone would just have a bit of time to clean up and improve on existing stuff.

It would be nice if every developer had to run their latest build on 10 year old hardware while testing it out. Instead of their high-powered development machine with the latest CPU, tons of high speed memory, and the fastest SSD; they would get to experience what many of their customers have to endure on slower hardware with capacity constraints. Nothing spurs optimization like seeing first hand how your code creeps…

Supposedly the Office for Mac team had to run their builds on the original 60MHz Power Mac

Re: The Great CPU Stagnation

#173

Post by tbrownaw »

vlovich123 wrote: post #49
timerol wrote: post #28

Earlier quoted context omitted.

tl;dr New materials can help, but "resistive losses" aren't really the driving factor. The energy is a mix of leakage current and active current. Leakage current can be thought of as resistance - it's how much current flows through a transistor that's off. This can be better based on the material, but gets harder with smaller transistors. (Thinking about quantum tunneling as a resistance is good to get intuition, but…

I think two major revolutions would be optical and reversible computing. The former would significantly shrink the heat generated which is a huge bottleneck but is very hard to build generic computing out of and expensive. The latter would basically result in computing obtaining a new theoretical lower bound on energy required but is purely research with no known approaches for actually building the things. Asynchron…

Reversible computing needs a place to store waste entropy, ie a rather large memory that's initialized to known values and filled with junk as the computation runs. Venting entropy out of a system is not reversible.

Clockless designs mean that you compute readiness information on the fly instead of having it precomputed at design time. This additional run-time computation is not free, and tooling for clocked designs is good enough that the extra slack they need is often cheaper.

Re: The Great CPU Stagnation

#174

Post by pornel »

nologic01 wrote: post #47

In fact the CPU stagnation is worse. In contrast to the shrinking chip size and higher frequencies of past scaling laws, CPU core count does not easily translate to performance gains. It needs specialized and careful designed software to tap the capability. In fact if CPU core count did translate more easily to performance gains I think already with the existing CPU's we'd have a fairly signficant one-time boost. May…

It does require software taking advantage, but this was a chicken-egg problem caused by Intel's stagnation. When most CPUs had only 4 cores, developers had an easy excuse: two of the cores were "fake" HT cores so they didn't count, they'd use one core, and the other core was for the OS or other apps, so there's basically no point complicating software for so little gain.

Only recently AMD has opened the floodgates and we got consumer systems with 16 cores, where finally it's really hard to find an excuse to leave 15 cores idle, and there's so much raw power that even suboptimal scaling can give a big performance boost.

Also Rust became a thing, and it makes much easier to write reliable multi-core software, so I'm optimistic about software catching up.

Re: The Great CPU Stagnation

#175

Post by k0k0r0 »

crote wrote: post #170
lynx23 wrote: post #44

The perfect time to shed ourselves of the idea that "optimisation is a waste of dev-time". Mobile computing was the last godsent t actually rethink performance a little bit, but we still have a lot of relatively low-hanging fruit. I sometimes dream about a month-of-no-new-features, where everyone would just have a bit of time to clean up and improve on existing stuff.

That's still the case, though. Like it or not, computation is cheap and developers are expensive. Code isn't worth optimizing until it either becomes a bottleneck, or you are running it on thousands of machines.

Exactly this bothers me a lot. I do bare metal performance optimizations, but I worry to never find a job outside of academia in that field. as I don't want to do high-frequency trading nor develop games.

Re: The Great CPU Stagnation

#176

Post by lostmsu »

eppsilon wrote: post #126
lostmsu wrote: post #90

Earlier quoted context omitted.

> That's why Apple silicon kicks everyone's ass. ??? But it doesn't: https://browser.geekbench.com/processor-benchmarks https://browser.geekbench.com/mac-benchmarks

*kicks ass per-watt

The parent was talking about unified memory.

Re: The Great CPU Stagnation

#177

Post by lostmsu »

owenmarshall wrote: post #127
lostmsu wrote: post #90

Earlier quoted context omitted.

> That's why Apple silicon kicks everyone's ass. ??? But it doesn't: https://browser.geekbench.com/processor-benchmarks https://browser.geekbench.com/mac-benchmarks

Doesn’t Geekbench overwhelmingly measure raw CPU performance, whereas GP was talking about overall system performance? Isn’t this chalk and cheese?

Well, what other benchmark results say otherwise?

Re: The Great CPU Stagnation

#178

Post by WaxProlix »

moosedev wrote: post #165
WaxProlix wrote: post #155

Earlier quoted context omitted.

Did something similar a bit ago with the 5900X and a 6900XT. Wonderful setup, low wattage, quiet, performant. Just lost it to a fire and not sure what to replace it with, alas. Too busy in the aftermath to justify building and parting stuff independently, so that probably leaves me with an off the shelf or a workstation + GPU combo.

Yikes. What started the fire?

Still under investigation, alas. First guess was a popped lithium battery downstairs but the fire dept has ruled that out now.

Re: The Great CPU Stagnation

#179

Post by emrah »

lynx23 wrote: post #44

The perfect time to shed ourselves of the idea that "optimisation is a waste of dev-time". Mobile computing was the last godsent t actually rethink performance a little bit, but we still have a lot of relatively low-hanging fruit. I sometimes dream about a month-of-no-new-features, where everyone would just have a bit of time to clean up and improve on existing stuff.

Rather than a one-month focused effort, i think this should be an ongoing practice, much like security

Re: The Great CPU Stagnation

#180

Post by re-thc »

crote wrote: post #170
lynx23 wrote: post #44

The perfect time to shed ourselves of the idea that "optimisation is a waste of dev-time". Mobile computing was the last godsent t actually rethink performance a little bit, but we still have a lot of relatively low-hanging fruit. I sometimes dream about a month-of-no-new-features, where everyone would just have a bit of time to clean up and improve on existing stuff.

That's still the case, though. Like it or not, computation is cheap and developers are expensive. Code isn't worth optimizing until it either becomes a bottleneck, or you are running it on thousands of machines.

Depends on how you look at it. It’s the mindset. The way you worded it sounds like you default to writing poor code and then have to reach a certain bar before it requires optimization.

Can’t you write closer to optimal code to begin with? With experience can’t you start with learnings of the past? A lot of things are easy and convenient to do now but people like you just parrot about not needing to optimize so as to not do it at all.

Maybe instead of thinking if it’s expensive or cheap think about actually wanting to do something decent? Or is everything fake and just a transaction?

Post reply on HN