4 ms·
_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
by 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 agoYour 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 ;)