Live data from Hacker News

The Great CPU Stagnation

databasearchitects.blogspot.com

181–190 of 222 posts

Re: The Great CPU Stagnation

#181

This "stagnation" is nothing like the stagnation during AMD's poorly performing Bulldozer era (the post Athlon era) where they were consistently beat by Intel's offerings and there was a general lack of innovation in the prosumer space. During that era for the most part Intel's i7 prosumer CPUs started with 4 cores with the Bloomfield Nehalem chips in 2008 (which at the time were awesome and a game changer) and ended…

Not saying you're wrong, because intel stagnation was very real, but please don't use userbenchmark as a source of numbers for anything. They're a terrible source with biased benchmarks and reporting. Just look at the dribble they write for basically any AMD product on their site ( https://cpu.userbenchmark.com/SpeedTest/1817839/AMD-Ryzen-7-... , or this https://cpu.userbenchmark.com/SpeedTest/2081998/AMD-Ryzen-7-...…

Or when AMD started adding more cores to desktop chips and they changed the "overall score" calculation from 30% single, 60% quad, 10% multi to 40% single, 58% quad, 2% multi.

Not only was that the opposite of computing trends, and just there to spite AMD, the new system had results like an i3-9350KF being overall faster than an i9-9980XE.

Re: The Great CPU Stagnation

#182
post #170
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.

You're not describing the real problem there. It's perfectly fine for a company to throw a hundred servers at something to save dev time.

The problem is programs that are running on thousands or millions of machines but don't get optimized, because the customer runs the program and pays the costs and it's hard for them to blame any program in particular.

Re: The Great CPU Stagnation

#183
post #99

Earlier quoted context omitted.

OS and device manufacturers don't necessarily want to optimize. Optimization would reduce the hardware replacement cycle, cutting into their profits. Microsoft gets pressure from their hardware partners to keep up the hardware replacement cycle, and they themselves of course get a cut of that via OS licenses. Phone manufacturers seemingly invented "Always On Displays" to also cause people to start to think they neede…

Huh, the always on display on my S23 non-plus was only a 10% battery hit over a day or so. Still disabled it, of course. Also nice that they've finally added an option on Samsung phones to only charge to 85%, but it would be nice if it had smarter options like on iOS. Eg, an option to charge up to 100% just before you expect to wake up, so you have the full charge but it doesn't sit at 100% all night degrading the ba…

I could be wrong on the model. It's one of the big ones with a pen. There's so many Samsung models...

Re: The Great CPU Stagnation

#184

Earlier quoted context omitted.

> Isn't it fair to characterize the cmos/fet switching losses as resistance to moving the charges around? Not really. It makes more sense to think about it as filling and emptying capacitors. You are charging the gate capacitance up to the supply voltage, then dumping that charge to discharge the gate to 0 again. The energy of each capacitance that gets charged and dumped is CV^2/2, which happens for each logic trans…

So the charge is work and the discharge is waste? I guess I am entertaining the idea of an idealized Maxwell-demon CMOS circuit, if we could bounce the charge between gates with very little work to just pump the charge back and forth.

They're both waste. Charging a capacitor to 1 volt means your average input voltage is .5 and half your energy goes to heat. Discharging to a ground line wastes the other half.

As the sibling comment says, you would need voltage converters running both ways to avoid this waste.

Re: The Great CPU Stagnation

#185
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.

Ask your boss for that! Float the idea at a team standup or something a couple of times. Advocate for having engineering roadmap to address tech debt and increase performance. Many times you'll get it if you can articulate the need for it well enough.

Re: The Great CPU Stagnation

#186
post #174

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

I mean Microsoft did just brag about cutting the Teams launch time to 9 seconds. Progress, baby!

Re: The Great CPU Stagnation

#187
post #104

This analysis is wrong because it is focusing on a limited number of high end chips. You can buy CPUs that cost a fraction of any of those listed that will absolutely demolish even the best chips from 6 years ago today. All while consuming drastically less power for that performance as well. Even mobile chips over 2 years old are within margin of error performance distance to those entry level Naples chips listed, at…

Thanks, I was hoping someone would comment as to why the article might be wrong. I also wonder what the trends look like in terms of performance per watt?

It's hard to say without actually testing the hardware with a power meter, since throttling plays such a big role and power budgets advertised are often just a single figure approximation of a much more complicated formula.

I run a home server powered by a Ryzen 5800H, nominally a 45W part, but I've seen it maintain a power draw far higher than that for hours under sustained load.

Re: The Great CPU Stagnation

#188

Earlier quoted context omitted.

I am always more than happy to see Permacomputing mentioned. I really think it is a wave of the future that will not be fully realized for another decade or so. Similar to Solar punk, it is still trying to find its feet and a lot of the most optimistic propositions will look silly in retrospect but the potential is there. It also kind of drives me up the wall when you see what was being done on computers in the 80's…

2+ decade-old word processors were fantastic at their jobs, and did 98+% of whatever needs to be done today. It would be great if old codebases could be liberated, cleaned-up, and turned into all-but-perfect tools for the job. Older spreadsheets, databases, etc., could also be renewed this way — but I doubt the corporations holding the rights to them would be interested in making this sort of thing happen. Too little…

Absolutely. This is why I feel like projects Libre office are disappointing to both optimists and pessimists. They are free and open but the performance and some capabilities are not so stellar.

Maybe there is the possibility to trim down a package like that into something akin to what we had in the 90's but, funnily enough, there is a lot of that 90's legacy that was stacked onto, it looks like there is just too much legacy in it to make that a viable path.

Re: The Great CPU Stagnation

#189
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.

There is that moment in video game development when the feature set is locked down and it basically turns into speed and stability optimization. Some people love it, others hate it. I guess you would get a similar state in some embedded systems. The folks at NASA working on the Mars Rovers have a set target and are usually targeting mid 90's MIPS or PPC processor so they have to be fixated on speed and performance.

Smart contracts get there too. There is a huge monetary incentive for optimization and correctness at launch.

Re: The Great CPU Stagnation

#190
post #50

Earlier quoted context omitted.

I think the main reason people get a new CPU, regardless of the performance, is because the device that it came in has gotten too old (wear-and tear: screen, batteries, etc).

I'm pretty sure that when you adjust for inflation, you get more performance per dollar, but I'd need to do math and I don't have the numbers from my head. Does Google Sheets provide a "inflation-adjusted dollar" function?

Performace/$ is still going down when adjusting for inflation. Performance/W goes down even more.
Post reply on HN