Live data from Hacker News

The Great CPU Stagnation

databasearchitects.blogspot.com

1–10 of 222 posts

Re: The Great CPU Stagnation

#2
We've known about this for a long time. Everyone expected it to happen. There are some key upcoming technologies that have the potential to cause a step in scaling (CFETs, backside power delivery) but it's still not going to be anywhere near Moore's law levels. I think this is part of why GPU power is skyrocketing and why Apple, Qualcomm, and the like are trying to shift towards services.

Re: The Great CPU Stagnation

#5
post #2

We've known about this for a long time. Everyone expected it to happen. There are some key upcoming technologies that have the potential to cause a step in scaling (CFETs, backside power delivery) but it's still not going to be anywhere near Moore's law levels. I think this is part of why GPU power is skyrocketing and why Apple, Qualcomm, and the like are trying to shift towards services.

It helps that those services are a great recurring revenue stream, too.

Re: The Great CPU Stagnation

#6

The Great x86 CPU Stagnation? ARM seems to have made some great leaps forward in recent years.

I don't have a feeling ARM offerings are significantly cheaper than x86. There really isn't much magic, a transistor costs the same to manufacture under a given process, regardless of the ISA.

In that, RISC-V might get some edge, because ARM licensing is expensive, but I don't think licensing is a significant cost for the x86 crowd.

OTOH, the server ARM people are really pushing it: https://www.semianalysis.com/p/sound-the-siyrn-ampereone-192...

But Altra's ain't cheap.

Re: The Great CPU Stagnation

#8

At least now people will start to focus on how bloated and slow software has become in the meantime. And stop referring to it as “tech”.

I (unfortunately) doubt it. I think the reality with our current situation is that only hobbyists and open source people care enough about that to do anything about it. Everyone else is doing Scrum so hard that they can't think of much outside the current sprint, and any "pre-mature optimization" is evil and must be avoided. The result will be more of the same bloat. Competition won't help because everybody is using the same bloated foundations and nobody will invest more than a few days in the foundation because it's not "product work."

The best we can hope for I think is that open source will create frameworks/foundations on top of which people can then try to build. Elixir Phoenix has been that to some extent, basically taking the rails philosophy but making it super light and fast (my Phoenix APIs run with 40MiB of memory and response times ~1ms). Maybe those sorts of advancements can save us, but I can't think of a way to address the browser that way and realistically right now the browser is a huge area of the bloat. A ton of code that runs in the browser is terribly optimized, but even the base is quite big.

Re: The Great CPU Stagnation

#9

The Great x86 CPU Stagnation? ARM seems to have made some great leaps forward in recent years.

not really, there have been some systems built on top of ARM chips that have been impressive, but the chip hardware tech hasn't changed much differently than their x86 counterparts

Re: The Great CPU Stagnation

#10
The answer to this might be more application specific accelerators and 3D stacking. You can't afford to have all of a chip switched on at once because of the power consumption and dissipation, so you build more optimised accelerators and keep flipping between them as you encounter different pieces of code that may benefit from each accelerator. Only a fraction of the device is ever in use at once. You 3D stack the chips to get more transistors in the same space. NAND flash chips are already 3D stacked, often with 100 layers or more.
Post reply on HN