[onikolas]

"The speed of light limit had been reached. Signals could not propagate across the surface of the chip fast enough to allow higher speeds."

Sorry, this is blatantly wrong. The 'wires are too long' problem was solved a couple of decades ago by adding pipeline stages.

Processors can easily get faster, today, by increasing the clock speed. Problem is, the generated heat fries them. Heat is a function of voltage and frequency. You can only lower voltage so much before switching states becomes unreliable. After that the only option is to lower frequency.

[js8]

I am not an expert, but I heard differently. IBM z13 CPU had to decrease the frequency compared to its predecessor, because they had a rule that the CPU should be able to operate on contents of L1 cache in one cycle, and they decided to expand L1 cache a bit. So I think "wires are too long" problem is alive and well when it comes to L1 cache size.

[randcraw]

Of course, long circuit lines will limit further increase in clock frequency. But in practice, heat is the lower bound. In CMOS, heat arises from charge dissipation, or voltage times clock frequency. Unless we can switch to transistor fabric that does NOT dump charge with every state change, heat will remain the dominant problem for future CPU speedup.

Despite what some claim, multicore is no solution to speedup. Coarse or fine grain parallelism is useful only when data parallelism is possible, which applies to less than 5% of today's software (graphics, speech, deep learning, et al). Functional programming may free code from explicitly addressing variables, but FP's implicit addressing does not magically eliminate sequential dependencies.

The vast majority of processes in mainstream software are inherently sequential. Simply implementing them in an FP won't make them parallel, so adding threads won't increase speed.

[kazinator]

Moreover, signals already propagated across the surface of the Intel 4004 chip at close to the speed of light.