[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.