3 ms·

> It seems like we ought to have switched from CISC to RISC. From a purely technical perspective at least Uh, no. CISC is far more efficient than RISC. You

> It seems like we ought to have switched from CISC to RISC. From a purely technical perspective at least Uh, no. CISC is far more efficient than RISC. You can do much more with fewer bytes, increasing your cache efficiency. Also, the fastest instructions are just as quickly decoded as RISC, if not faster. And any complex instructions we can leave for microcode. The fact that early microprocessors are CISC shows you how much they could do with just a few thousand transistors. RISC architectures never took off until they could pack millions of transistors in, which should hint at how inefficient they were. This inefficiency manifests itself in modern times through power consumption. DEC Alphas & Power CPUS were already power consumption beasts, which is why Apple had to switch from Power to x86 for Macs. Right now there is nothing intrinsically better about RISC architectures. Like VLIW, RISC is a nice theoretical computer-engineering experiment, nothing more.

gvb 10y ago
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.
- rayiner 10y ago
  CAS latency is about 13ns for DDR3/4. Back in the day 100ns RAM was typical.
baobrien 10y ago
This isn't always the case. Check out the RISC-V compressed extension. It turns out that RV64GC usually beats x86_64 on dynamic code size. See slide 31: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fusion-finalV2.pdf https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu...

gvb 10y ago

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.

rayiner 10y ago
CAS latency is about 13ns for DDR3/4. Back in the day 100ns RAM was typical.

baobrien 10y ago

This isn't always the case. Check out the RISC-V compressed extension. It turns out that RV64GC usually beats x86_64 on dynamic code size. See slide 31: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fusion-finalV2.pdf https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu...