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

61–70 of 222 posts

Re: The Great CPU Stagnation

#61

Post by phkahler »

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…

>> Maybe somebody has statistical survey of how much of the existing deployed CPU core count is typically used?

My guess is very few cores are used on average. I did some testing with Solvespace to see which build options contributed most to performance:

https://github.com/solvespace/solvespace/issues/972

Obviously using OpenMP for multi-core was the big win. But what's not shown is that in typical usage (not the test I ran) if you're dragging some geometry around it will use all cores (in my case 4 cores / 8 threads) at about 50 percent utilization. That percentage probably drops as more cores are thrown at it due to Amdahl's Law. In other words, throwing double the cores at it will give a good boost to a lot of code that is already taking less than half the time (wall clock time, not CPU time).

We added OpenMP to a number of functions for significant performance gains. And in fact, any remining single-thread operation that gets the parallel treatment is likely to have a significant impact on overall performance since that is where most of the time is spent now. At this point we're more focused on features and bugs.

Algorithmic improvements are possible and I'd like to do those in the future, but they are much harder to do than sprinkling some #pragmas around critical loops. That will improve the scalability though, where multithreading really did not.

Re: The Great CPU Stagnation

#62

Post by nickdothutton »

I found the single core SPECInt figures for the last couple of decades very interesting. The curve flattens. Apologies for link to the bird site, but I’m mobile and it’s the fastest way I can find it, I think some of your will enjoy the diagram.

https://twitter.com/nickdothutton/status/1194978743250538496...

Re: The Great CPU Stagnation

#63

Post by jandrewrogers »

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 scale software on large silicon for a long time, but as an industry we mostly can't be bothered (or lack the skills) to do it.

Re: The Great CPU Stagnation

#64

Post by capitalsigma »

huijzer wrote: post #39
cl0ckt0wer wrote: post #22

The cores/money comparison doesn't looks like it accounts for inflation.

Indeed. I was also wondering why people would buy newer chips if they don’t show performance increases per dollar.

There are overheads in server workloads that scale with the number of machines (network traffic, serializing/deserializing requests). There are also fixed costs per server that don't scale with core count, or at least scale sublinearly (storage, physical data center space, motherboard, ease of maintenance). So running 10 machines with 100 cores can be cheaper and more performant than running 1,000 machines with 1 core even if $/core is higher. And of course individual cores can be beefier: wider SIMD units, application-specific extensions like bfloat support for ML workloads, etc.

Of course Moore's law is slowing down, but cores/$ is an extremely silly metric to use

Re: The Great CPU Stagnation

#65

Post by phkahler »

jeffbee wrote: post #38
formerly_proven wrote: post #34

Earlier quoted context omitted.

It's the average IPC improvement from the AMD marketing slides - Zen 2 over Zen, 15%, Zen 3 over Zen 2, 19% and Zen 4 over Zen 3 at 13%, so Zen 3 over Zen is 37% and Zen 4 over Zen is 55% (maybe a typo in the article)

Zen 1 was terrible and is not a useful baseline. It was obsolete at launch. Nobody bought them except companies who were paid to take them and agree to be in a press release. It was literally half the speed of Skylake on server workloads.

>> Zen 1 was terrible and is not a useful baseline.

First off, it's a perfect baseline when comparing AMD chips since that time. Zen 1 was similar to Intel performance-wise, winning some benchmarks and losing some.

Second, the Raven Ridge (Zen 1+) APUs were IMHO excellent performance for the price at the time - even against Intel. I have not felt the need to build a new system since the Mellori_ITX:

https://github.com/phkahler/mellori_ITX

Re: The Great CPU Stagnation

#67

Post by duped »

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) that don't let the CPU wait around to do work.

Re: The Great CPU Stagnation

#68

Post by ahartmetz »

jeffbee wrote: post #38
formerly_proven wrote: post #34

Earlier quoted context omitted.

It's the average IPC improvement from the AMD marketing slides - Zen 2 over Zen, 15%, Zen 3 over Zen 2, 19% and Zen 4 over Zen 3 at 13%, so Zen 3 over Zen is 37% and Zen 4 over Zen is 55% (maybe a typo in the article)

Zen 1 was terrible and is not a useful baseline. It was obsolete at launch. Nobody bought them except companies who were paid to take them and agree to be in a press release. It was literally half the speed of Skylake on server workloads.

Zen 1 was slightly slower per core, but had twice the amount of cores that Intel was willing to sell for desktop platforms! Kind of a big deal for use cases such as compiling C++ code...

Re: The Great CPU Stagnation

#69

Post by e44858 »

Reason077 wrote: post #54
EscapeFromNY wrote: post #30

Earlier quoted context omitted.

Apple's chips are very power efficent, yes, but the article and parent are talking/asking about raw power. Despite all the Intel hate the past 5 years, I don't think there's been even a moment where another company's leading chip has outperformed Intel's in benchmarks. See for example https://www.cpubenchmark.net/compare/4922vs5022vs5008vs5189/...

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

Re: The Great CPU Stagnation

#70

Post by danielvaughn »

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.

More like a year - the performance rot runs deep.
Post reply on HN