By: Ricardo B (ricardo.b.delete@this.xxxxx.xx), April 10, 2017 2:17 am
Room: Moderated Discussions
anon (abc.delete@this.def.com) on April 9, 2017 11:07 pm wrote:
> Agree on (a). However, the promise of RISC wasn't to do mickey-mouse cores, it was high
> performance. Just that in 1985, high performance looked a lot like Cortex-M, and x86 needed
> a larger transistor budget to match the performance, and thus expensive. I've stated earlier
> that for a window of time (roughly a decade), RISC had a strong case.
Not just transistor budget, but also R&D.
It took intel up to 1991 to fully pipeline x86 in the 80486.
And even then, it came with the caveat that extracting maximum performance meant using RISC-style code.
It wasn't until the Pentium4 that complex instructions like LOAD+OP could be used without significant restrictions.
>
> That said, re. (b), 1 datapoint is sufficient to disprove the rule. And it's a massive datapoint.
> x86 had to stick around long enough for OoO to be viable. In OoO machines, the advantages of RISC
> diminish. It demonstrates that the CISC isn't a limiter to high performance: intel and AMD have
> no problems implementing rep movsl in their current machines, and the instruction is still used
> in memcpy (faster than a software loop on Intel). What could be CISC-ier than that? The x86 tax
Oh, things like: add [reg1 + 8 * reg2 + 0x123], ah
And AFAIK, x86 is a puppy compared to somethings VAX could do.
RISC vs CISC isn't some religious issue.
The core issue is: how hard it is to make (and exploit) a pipelined implementation?
Having a memcpy() microcoded instruction in the mix was hardly a practical problem.
> is paid in a longer, more power-hungry decode stages and yet x86 is more efficient than SPARC
> or POWER implementations (they design for a different market but the fact remains).
>
> My point isn't that RISC made no sense (it made fine sense in 1985). However, in 2017, ISA
> is largely irrelevant for performance, and x86 didn't succeed by implementing RISC 'underneath'
> (that's assigning undue credit). Meanwhile, RISCs started moving in the opposite direction:
> ARM is a complex RISC (oxymoron?), as is POWER. For excellent reasons too.
RISC vs CISC is irrelevant for the performance... of OoO CPUs.
Now, realize that the world is full of in-order CPUs.
Eg, most low/mid range smartphones run on in-order ARM cores and even most of the high-end/tablets run on a mix of in-order and OoO (big.LITTLE).
Your statement that RISC vs CISC is irrelevant for performance is not a general truth in 2017.
> Agree on (a). However, the promise of RISC wasn't to do mickey-mouse cores, it was high
> performance. Just that in 1985, high performance looked a lot like Cortex-M, and x86 needed
> a larger transistor budget to match the performance, and thus expensive. I've stated earlier
> that for a window of time (roughly a decade), RISC had a strong case.
Not just transistor budget, but also R&D.
It took intel up to 1991 to fully pipeline x86 in the 80486.
And even then, it came with the caveat that extracting maximum performance meant using RISC-style code.
It wasn't until the Pentium4 that complex instructions like LOAD+OP could be used without significant restrictions.
>
> That said, re. (b), 1 datapoint is sufficient to disprove the rule. And it's a massive datapoint.
> x86 had to stick around long enough for OoO to be viable. In OoO machines, the advantages of RISC
> diminish. It demonstrates that the CISC isn't a limiter to high performance: intel and AMD have
> no problems implementing rep movsl in their current machines, and the instruction is still used
> in memcpy (faster than a software loop on Intel). What could be CISC-ier than that? The x86 tax
Oh, things like: add [reg1 + 8 * reg2 + 0x123], ah
And AFAIK, x86 is a puppy compared to somethings VAX could do.
RISC vs CISC isn't some religious issue.
The core issue is: how hard it is to make (and exploit) a pipelined implementation?
Having a memcpy() microcoded instruction in the mix was hardly a practical problem.
> is paid in a longer, more power-hungry decode stages and yet x86 is more efficient than SPARC
> or POWER implementations (they design for a different market but the fact remains).
>
> My point isn't that RISC made no sense (it made fine sense in 1985). However, in 2017, ISA
> is largely irrelevant for performance, and x86 didn't succeed by implementing RISC 'underneath'
> (that's assigning undue credit). Meanwhile, RISCs started moving in the opposite direction:
> ARM is a complex RISC (oxymoron?), as is POWER. For excellent reasons too.
RISC vs CISC is irrelevant for the performance... of OoO CPUs.
Now, realize that the world is full of in-order CPUs.
Eg, most low/mid range smartphones run on in-order ARM cores and even most of the high-end/tablets run on a mix of in-order and OoO (big.LITTLE).
Your statement that RISC vs CISC is irrelevant for performance is not a general truth in 2017.
