4 ms·

I'm surprised nobody here is talking about the instruction set architecture aspect of this. CISC won the first round of RISC vs. CISC saga. X86 is bloated, leg

by mustpax 16y ago

I'm surprised nobody here is talking about the instruction set architecture aspect of this. CISC won the first round of RISC vs. CISC saga. X86 is bloated, legacy mess. It has been riding on the coattails of Intel's success in marketing ("Intel Inside"), silicon wafer production process (a couple generations ahead of AMD), and Microsoft's desktop platform (which only runs on X86). RISC is a better architecture that should have won, and it's finally going to get its time in the sun.

ergo98 16y ago
_Checks Watch_ Is it 1989 again? We've had these horribly boring CISC versus RISC arguments since back in the late 80s/early 90s. Your arguments for why x86 keeps winning are ridiculous. As to RISC versus CISC, in some ways the former is like "native code" and the latter is like "VM byte code" (ala Java byte code, .NET byte code). The former is heavily optimized, but can't adapt well to different hardware/environments, while the latter isn't as fast out of the gate, but it can be heavily optimized. Which is exactly what every modern processor does. X86 to a Xeon is just like Java byte-code, and gets interpreted into something very different in the magical internals of the processor.
- mustpax 16y ago
  Your analogy to native vs. byte code is apt, but the question is not whether we can JIT-compile byte code to run as fast as native code (we can). The question is, what instruction set allows us to write the best compilers. I would argue that the answer is RISC. Every time Intel adds yet another instruction for doing the same thing, it makes every compiler's job harder. Intel's C compiler is faster than most others because they know their overly convoluted instruction set best. Simpler instruction set means more resources to focus on the few instructions that exist both for the chip manufacturer and the compiler vendors. On a somewhat related note, Java byte code uses a very-Reduced ISC, a simple stack machine.
- bad_user 16y ago
  > X86 to a Xeon is just like Java byte-code, and gets interpreted into something very different in the magical internals of the processor. Err, no, the interpretation mechanism is actually pretty similar, kind of being shared between microprocessors, with special optimizations here and there but nothing magical ;)
hga 16y ago
I've been studying this for a while and it seems to me that the RISC day in the sun was most especially dependent on memory getting faster (than core) and a lot less expensive and gates becoming extremely precious due to the premium on putting a whole CPU on a single die. Now we don't know what to do with all the gates we can put on a die and once again memory is pretty slow compared to CPU speeds, so the CISC model of minimizing the size of the instruction stream is again a win due to the speed and latency from main memory and the limits on cache memory on the die.

by mustpax 16y ago

ergo98 16y ago

_Checks Watch_ Is it 1989 again? We've had these horribly boring CISC versus RISC arguments since back in the late 80s/early 90s. Your arguments for why x86 keeps winning are ridiculous. As to RISC versus CISC, in some ways the former is like "native code" and the latter is like "VM byte code" (ala Java byte code, .NET byte code). The former is heavily optimized, but can't adapt well to different hardware/environments, while the latter isn't as fast out of the gate, but it can be heavily optimized. Which is exactly what every modern processor does. X86 to a Xeon is just like Java byte-code, and gets interpreted into something very different in the magical internals of the processor.

mustpax 16y ago
Your analogy to native vs. byte code is apt, but the question is not whether we can JIT-compile byte code to run as fast as native code (we can). The question is, what instruction set allows us to write the best compilers. I would argue that the answer is RISC. Every time Intel adds yet another instruction for doing the same thing, it makes every compiler's job harder. Intel's C compiler is faster than most others because they know their overly convoluted instruction set best. Simpler instruction set means more resources to focus on the few instructions that exist both for the chip manufacturer and the compiler vendors. On a somewhat related note, Java byte code uses a very-Reduced ISC, a simple stack machine.
bad_user 16y ago
> X86 to a Xeon is just like Java byte-code, and gets interpreted into something very different in the magical internals of the processor. Err, no, the interpretation mechanism is actually pretty similar, kind of being shared between microprocessors, with special optimizations here and there but nothing magical ;)

hga 16y ago

I've been studying this for a while and it seems to me that the RISC day in the sun was most especially dependent on memory getting faster (than core) and a lot less expensive and gates becoming extremely precious due to the premium on putting a whole CPU on a single die. Now we don't know what to do with all the gates we can put on a die and once again memory is pretty slow compared to CPU speeds, so the CISC model of minimizing the size of the instruction stream is again a win due to the speed and latency from main memory and the limits on cache memory on the die.