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

81–90 of 222 posts

Re: The Great CPU Stagnation

#81

Post by crabbone »

There were multiple mentions in this thread contrasting GPU with CPU... I think, there's some conceptual gap here. GPUs are made of the same thing as CPUs, they have all the same problems CPUs have. They emphasize vectorized operations, and some less important (for this thread) stuff, like video encoding / decoding, but, by and large, the "PU" part is not accidentally the same in both acronyms.

The difference comes from usage. CPUs are shared by processes and threads that are designed to be unaware of each other, or to be even hostile. At the same time, a lot of programs are built in such a way that they don't exploit the parallelism available to them through CPU, or, even if they do, they do it in a very clumsy way (through a bunch of wrappers with their own limitations).

To contrast this, GPU programs typically use the whole GPU at once, and are written with parallelism in mind, with little to no wrappers.

Similarly, because the basic unit of CPU usage is a process, and the model of using CPUs is that processes aren't allowed to know about each other by default, the memory use becomes more involved, inter-process communication becomes more involved, permissions, access to network etc. -- all this complicates and slows down programs which want to use CPUs.

But, if, somehow, there was an OS that could use GPU to run processes on it, use VRAM for code / data of those processes etc. -- we'd have the same problems.

Re: The Great CPU Stagnation

#82

Post by mcguire »

paulddraper wrote: post #71

"When you can't scale up, scale out." GPUs have strong potential for improvement, and moving workloads to them helps on multiple fronts: performance, cost, power consumption.

If your workload is the embarrassingly parallel type that GPUs are designed for.

Re: The Great CPU Stagnation

#83

Post by bhouston »

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 with 4 cores with the Kaby Lake-S in 2017. It really only changed in 2017 with AMD Ryzen forcing Intel to actually increase core count.

2008 Nehalem benchmark: https://cpu.userbenchmark.com/SpeedTest/778/IntelR-CoreTM-i7...

2017 Kaby Lake-S benchmark: https://cpu.userbenchmark.com/Intel-Core-i7-7700/Rating/3887

When I compare the two, it shows an effective 20% speed increase, although microbenchmarks show a 50% increase. That is a stagnation.

During that era it felt like a lost decade. I don't miss it.

Re: The Great CPU Stagnation

#84

Post by wmf »

Rafuino wrote: post #73
wmf wrote: post #51

Earlier quoted context omitted.

Coincidentally Ampere One was announced today and it looks pretty mediocre.

What looks mediocre about it? They're making BIG claims about density and power usage at scale

If they doubled performance and doubled power that's not good.

Re: The Great CPU Stagnation

#85

Post by Reason077 »

e44858 wrote: post #69
Reason077 wrote: post #54

Earlier quoted context omitted.

The M2 Pro isn't doing too bad when you consider you're comparing a laptop chip with 14+ hour battery life against Intel's latest and greatest, high-TDP desktop CPU with twice as many cores. On a performance-per-core basis it's not even far behind.

If the TDP is an accurate measure, then the M1 appears to be about as efficient as 12th gen Intel: https://www.cpubenchmark.net/power_performance.html#all-cpu

I wonder if there's some shenanigans going on there. Max TDP in an M1 is surely far lower than the max TDP of an i7-1255U, which it outperforms. Most M1 systems don't even have fans but can perform at max performance for extended times. U-series i7s can also be run fan-less, but performance will be compromised?

Re: The Great CPU Stagnation

#86

Post by moffkalast »

thfuran wrote: post #74
moffkalast wrote: post #41

Earlier quoted context omitted.

From what I understand while these two do contribute a lot to power usage, they don't really contribute that much to heating by themselves? Leakage should happen all the same in a processor that's completely idle and those typically don't heat up much. For higher clock speeds specifically I still don't see how lower resistance isn't key.

>while these two do contribute a lot to power usage, they don't really contribute that much to heating Those are the same thing. Or at least close enough as makes no practical difference. Only an extremely tiny fraction of the power used but a CPU is becoming anything other than heat.

Then we actually agree? You don't get heating without resistance, ergo resistance is the main problem. MRIs don't have any problems sending a thousand amps through their coils.

Re: The Great CPU Stagnation

#87

Post by pjmlp »

jandrewrogers wrote: post #63
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…

CPU core count does translate to performance gains but the popular software architecture idioms most people use are incapable of taking advantage of large numbers of cores. The gap between the performance you typically see and what is possible with proper software architecture and performance engineering is orders of magnitude in scale. A lot of performance and scalability is left on the table. We've known how to sca…

It will hardly change as long as scripting languages keep being used for full blown applications.

Re: The Great CPU Stagnation

#88

Post by pklausler »

pixl97 wrote: post #57
qayxc wrote: post #43

Earlier quoted context omitted.

> I think this is part of why GPU power is skyrocketing and why Apple, Qualcomm, and the like are trying to shift towards services. IMHO it's only a very small part of why GPU power consumption is going up. The main reason is the completely unnecessary chase for the performance crown. From personal testing: my GPU manages to get 95% of its peak performance while being power limited to 80%. So the in order to squeeze…

I would also think that GPU workloads have something to do with it. Almost none are serial workflows, and instead highly parallel work. GPU workloads will eventually run into the same scaling limits. That is we will be unable to speed up each execution unit any further, or the primary work we give the GPU will not be able to be split into more threads and accomplish useful work.

Multi-GPU nodes with fast coherent interconnects exist.

Re: The Great CPU Stagnation

#89

Post by orbital-decay »

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…

Clockless designs did find their use, just not for the entire chips. Certain parts of modern CPUs are asynchronous.

Re: The Great CPU Stagnation

#90

Post by lostmsu »

duped wrote: post #67
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…

> CPU core count does not easily translate to performance gains. In theory, performance scales logistically with the number of parallel processors (Amdahl's law). In practice, the limit is (and has always been) memory and i/o. That's why Apple silicon kicks everyone's ass. If we want faster computers, the biggest gains are not to be found in making processors do more work. It's in designing systems (not just CPUs) th…

> 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

Post reply on HN