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

211–220 of 222 posts

Re: The Great CPU Stagnation

#211

Post by thfuran »

moffkalast wrote: post #197
kayson wrote: post #135

Earlier quoted context omitted.

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

Ok but again, why do we need the resistors at all? That's what limits the speed at which the capacitor can discharge, so with theoretically 0 resistance you'd get immediate discharge and could go to infinite frequencies, or more realistically as far as the speed of electrons allows for consistent gate switching. To add a bit of troll physics here (but I'm told computers using this sort of principle actually exist), w…

There's no such thing as superconducting semiconductors.

Re: The Great CPU Stagnation

#212

Post by Kon-Peki »

moffkalast wrote: post #113
timerol wrote: post #101

Earlier quoted context omitted.

> Leakage should happen all the same Modern processors are very careful about this, and actively turn off the supply voltage to large parts of the die to prevent extra leakage current. The funny-but-appropriate name for this is "dark silicon" https://en.wikipedia.org/wiki/Dark_silicon

> at 8 nm technology nodes, the amount of dark silicon may reach up to 50–80% Damn TIL, I never would've expected that. But I guess it makes sense to use a few of the older, larger transistors that don't leak as much to power off a section of the smaller leaky ones while they're not performing any operations.

Hey, keep in mind that things like large caches, neural cores, SIMD units, DSP circuitry all count as dark silicon. The proliferation of these kind of components was predicted 15-20 years ago as a necessary response to the Dennard Scaling breakdown.

Re: The Great CPU Stagnation

#213

Post by bee_rider »

rbanffy wrote: post #50
bee_rider wrote: post #46

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?

I’m not sure really.

But anyway, I’m not sure if it makes sense to expect performance/$ to always increase anyway. I mean, I know this started out by talking about multicore, but think about single threaded performance. They’ve already grabbed all the low hanging fruit, the challenge now is finding increasingly hard to hunt down tweaks… a small improvement might require massive engineering effort.

Re: The Great CPU Stagnation

#214

Post by int_19h »

flenserboy wrote: post #163
NovaDudely wrote: post #151

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…

It's not as easy as it sounds. Making those apps work fast enough on hardware they were originally written on often involved highly convoluted optimized code, and sometimes even handwritten assembly. There is a valid point here, but I don't think reviving old codebases is a good starting point in many cases.

Re: The Great CPU Stagnation

#215

Post by int_19h »

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…

> GPU programs typically use the whole GPU at once

I don't think this is really true anymore? I mean, on a composited desktop, pretty much any UI app is a "GPU program". If you run a video game and it's not full screen, it's sharing the GPU (and it's increasingly common for "full screen" to actually mean a borderless window, too). Video players offload decoding. And then there's all the stuff that's using GPU to accelerate generic compute.

And once you have such sharing, it's just as adversarial as processes sharing CPU, when it comes to resource allocation, security etc.

Re: The Great CPU Stagnation

#216

Post by Dalewyn »

senttoschool wrote: post #210
Dalewyn wrote: post #201

Earlier quoted context omitted.

>It's a poor general purpose CPU benchmark that first favored Zen architecture (many slow cores) and now favors Intel's Raptor Lake. Would you advise the same if the colors were reversed? The majority of people here are AMD fanbois, so it's sometimes hard to discern whether something is rooted in objectivity or subjectivity.

If you're an AMD fanboy, you'd only care about Cinebench despite the fact that its results do not correlate with gaming or other common applications such as browsing, Excel, video editing, etc. There's a reason why x86 CPU users will only want to compare Apple Silicon using Cinebench. It's because Cinebench uses Intel Embree, which is hand optimized for x86 instructions. It's like testing Ryzen or Core CPUs on softwa…

Ideally you would run a suite of various benchmarks and workloads and pass judgment on the overall results, rather than basing it on just one specific test or another. They're all going to be biased one way or another.

You also didn't answer my question: Would you likewise advise against Cinebench if the colors were reversed? As it is, you're advising against Cinebench just because it favors Intel.

Re: The Great CPU Stagnation

#217

Post by flenserboy »

int_19h wrote: post #214
flenserboy wrote: post #163

Earlier quoted context omitted.

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…

It's not as easy as it sounds. Making those apps work fast enough on hardware they were originally written on often involved highly convoluted optimized code, and sometimes even handwritten assembly. There is a valid point here, but I don't think reviving old codebases is a good starting point in many cases.

You're right on the ease of porting code. It's a shame that so much has been made over the years, and well, and seems to just disappear into the ether.

Re: The Great CPU Stagnation

#218

Post by moosedev »

WaxProlix wrote: post #178
moosedev wrote: post #165

Earlier quoted context omitted.

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.

I’m sorry you went/are going through that.

I know you said it’s been ruled out, but I sometimes wonder if I should worry more about aging lithium batteries in older devices… the oldest ones (e.g. 2000s handhelds) are now old enough to be retro-cool and therefore worth keeping for nostalgia, but they’re also a bit scary.

Re: The Great CPU Stagnation

#219

Post by senttoschool »

Dalewyn wrote: post #216
senttoschool wrote: post #210

Earlier quoted context omitted.

If you're an AMD fanboy, you'd only care about Cinebench despite the fact that its results do not correlate with gaming or other common applications such as browsing, Excel, video editing, etc. There's a reason why x86 CPU users will only want to compare Apple Silicon using Cinebench. It's because Cinebench uses Intel Embree, which is hand optimized for x86 instructions. It's like testing Ryzen or Core CPUs on softwa…

Ideally you would run a suite of various benchmarks and workloads and pass judgment on the overall results, rather than basing it on just one specific test or another. They're all going to be biased one way or another. You also didn't answer my question: Would you likewise advise against Cinebench if the colors were reversed? As it is, you're advising against Cinebench just because it favors Intel.

I’m advising against cinebench for any general purpose CPU testing. Far too many people, YouTubers, and hardware websites draw conclusion about the speed of the CPU and perf per watt using only Cinebench.

Re: The Great CPU Stagnation

#220

Post by Dalewyn »

senttoschool wrote: post #219
Dalewyn wrote: post #216

Earlier quoted context omitted.

Ideally you would run a suite of various benchmarks and workloads and pass judgment on the overall results, rather than basing it on just one specific test or another. They're all going to be biased one way or another. You also didn't answer my question: Would you likewise advise against Cinebench if the colors were reversed? As it is, you're advising against Cinebench just because it favors Intel.

I’m advising against cinebench for any general purpose CPU testing. Far too many people, YouTubers, and hardware websites draw conclusion about the speed of the CPU and perf per watt using only Cinebench.

I can drink to that. No singular test is going to give a complete picture.
Post reply on HN