[slver]

> The M1 processor is a direct result of the death of Moore's law.

I know most people misunderstand Moore's law, but this is HN, so I expect better:

https://en.wikipedia.org/wiki/Moore%27s_law#/media/File:Moor...

Moore's law is quite alive and showing no signs of problems.

> The performance gains from Moore's law have typically come from shrinking die size.

Moore's Law is about number of transistors. Not about their size, and not about performance.

And it's ESPECIALLY not about linear core performance.

> That has ended, you can't juice more performance from general purpose CPUs.

You don't need to, they're fast enough. Performance is expanding in other areas like GPU and ML.

> The death of Moore's law has many consequences, the rise of ASICs and custom co-processor chips is just one of them.

No, Moore's law is the very thing supporting them... You need extra transistors for those co-processors.

[CivBase]

> You don't need to, they're fast enough.

You had me with everything except this. Any time someone claims the current state of computing hardware is "enough" I'm reminded of that fake 640K quote. There is no indication we are running out of applications for more compute power.

[slver]

I'm not saying we're running out of applications for more compute power.

We're specifically running out of reasons to want faster linear (per core) general-purpose performance (in fact I'd say this happened some time ago). Everything else we get from here on in terms of smaller process etc. is just a bonus. We don't fundamentally need it to keep evolving our hardware for our ever-growing computation needs.

And that's because as our problems multiply and grow, parallel execution and heterogenous cores tend to solve our problems much more efficiently on the watt, than asking for "more of the same, but faster".

There's this Ford quote "if I had asked what people want, they'd have said faster horses". Fake or not, it reflects our tendency to stare at the wrong variables and miss the forest for the trees. The industry is full of languages utilizing parallel/heterogenous execution and you don't need a PhD to use one anymore.

CPUs are effectively turning into "controllers" that prepare command queues for various other types of processing units. As we keep evolving our GPU/ML/etc. processing units, CPUs will have less to do, not more. In fact, I expect CPUs will get simpler and slower as our bottlenecks move to the specialized vector units.

[fulafel]

Production quality multiplatform software is much much harder and less fun to make for GPUs due to inferior DX, rampant driver stack bugs unique for each (gpu vendor, os) combination, sorry state of GPU programming languages, poor os integration, endemic security problems (eg memory safety not even recognised as a problem yet in gpu languages), fragmentation of proprietary sw stacks and APIs, etc. Creation of performance oriented software is often bottlenecked by sw engineering complexity, effort and cost, and targeting GPUs multiplies these problems.

tldr; we are not running out of reasons for wanting faster CPUs. GPUs are a crap, faustian bargain substitute for them.

[maerF0x0]

https://scicomp.stackexchange.com/a/1395

Explains it better than I could in a HN reply.

Assuming our desired work to be done continues to grow, faster core speed* will eventually matter.

* technically, net instructions per second after prediction/compute ahead etc

[slver]

Honestly that's a bit too abstract to make sense of.

As a programmer to another, I'd rather ask... what's one example of a problem we have today that needs faster linear performance than our best chips (not in a nice-to-have way but in a must-have way).

I'd rule out all casual computing like home PCs, smartphones, and so on, because honestly we've been there for years already.

Also due to decades of bias we have serialized code in our programs that doesn't have to be serial, just because that's "normal" and because it's deemed easier. Also we have a huge untapped potential of better performance by being more data-oriented. None of this requires faster hardware. It doesn't even require new hardware.

But anyway, I'm open to examples.

[dilippkumar]

> I'd rule out all casual computing like home PCs, smartphones, and so on, because honestly we've been there for years already.

Casual computing can definitely be a lot better than where we are today[0][1].

The software business has moved to a place where it’s not really practical to program bare metal silicon in assembly to get screaming fast performance. We write software on several layers of abstraction, each of which consumes a ton of compute capacity.

We have resigned to live with 100ms latencies in our daily computing. This is us giving up on the idea of fast computers. It should not be confused with actually having a computer where all interactions are sub 10ms (less than 1 frame refresh period at 90fps).

[0]. https://danluu.com/input-lag/

[1]. https://www.extremetech.com/computing/261148-modern-computer...

[CivBase]

Linear compute is the ideal solution. Parallelization is a useful tool when we run up against the limitations of linear compute, but it is not ideal. Parallelization is simply not an option for some tasks. Nine mothers cannot make a baby in a month. It also adds overhead, regardless of the context.

Take businesses for example. Businesses don't want to hire employees to get the job done. They want as few workers as possible because each one comes with overhead. There's a good reason why startups can accomplish many tasks at a fraction of what it would cost a megacorp. Hiring, management, training, HR, etc... they are all costs a business has to swallow in order to hire more employees (ie parallelize).

This is not to say parallelization is bad. Given our current technological limitations, adding more cores and embracing parallelization where possible is the most economical solution. That doesn't faster linear compute is a "nice to have".

[pshc]

Virtual reality, being so latency-sensitive, is always going to be hungry for faster raw serial execution. It seems like something that ought to parallelize alright (one GPU per eye!) but my understanding is that there are many non-linearities in lighting, physics, rendering passes, and so on that create bottlenecks.

[pcurve]

Maybe this is a bit cheating, but there's chip with 2.5 trillion transistors. https://www.businesswire.com/news/home/20210420005955/en/Cer...

https://wccftech.com/cerebras-unveils-7nm-wafe-scale-engine-...