My take on the CISC/RISC "fight" is that the RISC was based on the assumption that the CPU clock was the limiting factor, so making a simpler CPU (RISC) would a

My take on the CISC/RISC "fight" is that the RISC was based on the assumption that the CPU clock was the limiting factor, so making a simpler CPU (RISC) would allow the CPU to be clocked faster than CISC and thus it would run faster. This was the case briefly when RISC came out (e.g. Alpha), but x86 fought back with improved fab technology and also threw more power at the problem. Lots of power. What blindsided RISC was that the CPU clock speed is not as much a limitation as memory access speed[1]. The voracious appetite of RISC instruction fetching[2] through the memory subsystem slowed it down more than it could speed up the CPU clock. (Yeah, yeah, broad generalizations.) Oh man, my point in a great graphic! https://www.cs.virginia.edu/stream/ https://www.cs.virginia.edu/stream/ [1] If you run the numbers, todays DDRn SDRAM latency is maybe half the latency of the original IBM-AT even though the advertised when streaming bandwidth is several orders of magnitude faster. In other words, if you are not streaming the memory accesses, your memories are not much more than 2x faster than the IBM-AT. Caching enables streaming. Branches break the stream. That is why both caches and branch prediction logic is huge. My numbers are out of date, but when I ran the numbers for the DDR2(?) memory in my hardware, the worst case latency was 56 clock cycles (e.g. if you had to close a page, open a new page, CAS latency, etc.). [2] RISC takes 1.5-2x more instructions than CISC in my experience. YMMV.