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

131–140 of 222 posts

Re: The Great CPU Stagnation

#131

Post by tedsanders »

crabbone wrote: post #81

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

Indeed, GPUs are not much better. For example, the NVIDIA H100 SXM has roughly the same price per transistor as the A100 SXM. The gains between generations were roughly equally split between (1) better chip design, (2) higher clock speed / power consumption, and (3) more transistors. Cost per transistor did not meaningfully improve.

Re: The Great CPU Stagnation

#132

Post by nabakin »

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…

I was looking for this comment and I think you're exactly right.

Over the years, Moore's Law became a household term for computer performance doubling every couple of years. Under that definition, Moore's Law died in 2005 with Dennard Scaling so for most intents and purposes, Moore's Law has been dead for a long time.

It only held under the more restrictive definition of performance for tasks that were able to be parallelized perfectly, but even that has now been broken.

You could also argue that Moore's Law died in 2005 because the term CPU used to refer to what we now know as a CPU 'core' and the term was redefined.

Ultimately, what matters is that the performance the end user experiences hasn't been doubling every 2 years since 2005.

Re: The Great CPU Stagnation

#133

Post by whynotmaybe »

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…

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.

Re: The Great CPU Stagnation

#134

Post by ketralnis »

duped wrote: post #130
ketralnis wrote: post #119

Earlier quoted context omitted.

> In practice, the limit is (and has always been) memory and i/o Absolutely not. In practise the limit is (1) how many cores are actually _used_ by programs and (2) how much work is put into making anything fast at all, ever. We're using web frontends powered by python backends over a network. The vast majority of programs use nowhere near the resoures available to them.

Those backends are spending most of their time waiting to do work, which is my point.

But even the amount of time they're doing "work" they're mostly managing refcounts and walking MRO chains and formatting strings and doing hashtable lookups to find local variables at runtime. Python code is 20-40x slower than C code. That other 19/20ths of the time is the bottleneck, not the memory bandwidth of the actual work. Same with your electron frontend.

Re: The Great CPU Stagnation

#135

Post by kayson »

moffkalast wrote: post #86
thfuran wrote: post #74

Earlier quoted context omitted.

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

You're right that the resistance is where the heat is dissipated, but lowering the resistance does not actually change the amount of heat. Transistor switching can be modeled as a step input to an RC circuit [1]. If you integrate the power through the resistor to infinity, you'll see that the value of the resistor drops out.

Intuitively, you might think of it like this: to charge a capacitor (or transistor) up to a certain voltage, you need a fixed number of electrons. That number of electrons will always pass through the resistor and generate heat based on their energy. Even if you change the resistor value, its still the same number of electrons, and the same amount of energy.

What does change with resistance, though, is the time over which the power is dissipated. In practice, you have to make sure the resistors are small enough such that you can achieve your desired clock speed.

There are actual resistive losses too, but they're mainly related to power delivery.

[1] https://en.wikipedia.org/wiki/RC_circuit#Time-domain_conside...

Re: The Great CPU Stagnation

#136

Post by timerol »

saltcured wrote: post #106
timerol wrote: post #100

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.

That's a reasonable way to think about it - you take energy from the supply voltage to charge the gate capacitor when the logic line goes high, then dump it when the logic line goes low.

If you had a lossless bidirectional voltage converter circuit for each gate capacitance, then you could charge the capacitor from the supply and discharge it back into the supply, removing any switching losses.

Re: The Great CPU Stagnation

#137

Post by didgetmaster »

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 wasn't suggesting that all the developers have to develop and compile their code on antiquated hardware. They should still have fast development machines.

What I was saying that if the developers ONLY run their software on their high-powered computers and never try it on slow hardware, they generally resort to the 'it runs fine on my machine' response when customers start complaining about performance.

Re: The Great CPU Stagnation

#138

Post by danielvaughn »

Arrath wrote: post #120
MichaelZuo wrote: post #94

Earlier quoted context omitted.

Considering that the NeXTStep OS ran on a 1120 × 832, 12 bit, display in 1990 with 12 MB of archaic memory and 1.5 MB of VRAM, I'd say more then a year. Judging by modern app memory usage. Even with the latest and greatest 4k, HDR, wide colour, display, no app should ideally use more then 256 MB of memory by those standards, unless it's even more complex.

Recently watching a Gamer's Nexus video where they tested a new built Voodoo 6 5000, I was impressed watching them install some ancient edition of Windows in which to do the testing, and how snappy and responsive the interface was.

My first computer was a 95 Packard Bell. I was 12 years old at the time, so I might be misremembering, but I swear the interface responsiveness felt immediate.

Re: The Great CPU Stagnation

#139

Post by danielvaughn »

MichaelZuo wrote: post #94
danielvaughn wrote: post #70

Earlier quoted context omitted.

More like a year - the performance rot runs deep.

Considering that the NeXTStep OS ran on a 1120 × 832, 12 bit, display in 1990 with 12 MB of archaic memory and 1.5 MB of VRAM, I'd say more then a year. Judging by modern app memory usage. Even with the latest and greatest 4k, HDR, wide colour, display, no app should ideally use more then 256 MB of memory by those standards, unless it's even more complex.

We might need to block all software features for the next decade so we can figure out what's going on.

Re: The Great CPU Stagnation

#140

Post by nologic01 »

sangnoir wrote: post #108
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 needs specialized and careful designed software to tap the capability. I wouldn't exactly call Golang[1] "specialized", but it does make multiprocessing easier than most languages. 1.Or Erlang or Elixir

I only use go through hugo but its fast enough I never checked how many cores it uses :-)
Post reply on HN