Common knowledge is that going wider quickly hits diminishing returns so generally there hasn't been a lot of pressure for x86 to go wider.
It seems to be working for Apple though possibly because they are targeting differen trade offs (lower clock speed for example); but maybe their secret is a better modelling of common workloads revealing this common knowledge to be outdated.
I'd like to see this explored more. I think AMD/Intel might be historically looking at C++/compiled workloads more than JS/Java/python interpreted workloads. JITs very well could take better advantage of wider cores than compiled code.
Diminishing returns with increasing cache sizes and going wider doesn't seem to hold back the M1.
Maybe. JITs and runtimes in general might add some "overhead" code that does book-keeping and verifies assumptions (to rollback conditional optimistic optimizations). Maybe wider engines allow running this overhead without impacting actual runtime.
It probably also help hide the cost of type checks and bound checks.
It might just be the combination of better branch prediction, TSMC 5nm, 8-channel memory, 16k pages, along with 8-wide cores+larger structures especially cache are enough to account for the more perf/watt of the M1.
It seems to be working for Apple though possibly because they are targeting differen trade offs (lower clock speed for example); but maybe their secret is a better modelling of common workloads revealing this common knowledge to be outdated.