John Mashey on RISC/CISC (1991)(userpages.umbc.edu)
userpages.umbc.edu
John Mashey on RISC/CISC (1991)
https://userpages.umbc.edu/~vijay/mashey.on.risc.html
6 comments
Comp.arch from the '80s thru the '00s is full of gems from actual CPU architects and other folks who deeply understood what they were talking about. Even (maybe especially) when you had two pros who had very different philosophies, they brought so much fact and experience to their posts you could really see how and why the other side saw things. Now it seems like virtually all processor comparison is some variation on "who runs $HOTGAMESOFTHEMOMENT one FPS faster...that must be the best one".
Reading Mash's posts on comp.arch led me to drop my resume off at reception at the office on Arques Ave in the hope of finding a job there. Probably 1989. Didn't get a call back. Good times though.
Games are a reasonably good stress of a CPU in real life. Most modern bench's are really unrealistic unless you're buying CPUs for raw compute (e.g. 100% util 24/7)
Games are a reasonably good stress of a CPU in real life.
No they aren't. In 'real life', games, especially high resource games, are inconsequential compared to, say, performance of Excel, Word or web browsing for the overwhelmingly majority of users.
No they aren't. In 'real life', games, especially high resource games, are inconsequential compared to, say, performance of Excel, Word or web browsing for the overwhelmingly majority of users.
Excel and word don't stress my machine, games do.
That criteria would just say "every CPU is ok" because ultimately only potatoes are unfit to run those problems. And nobody wants a review website posting "just buy a Celeron or whatever costs less and be happy" for 15 years straight.
On the other hand, measuring on, say, protein folding isn't likely to gather a lot of interest because most people are not buying laptops to run HPC research.
So, ultimately the reason videogames (and video encoding, compression, image processing and a few other workloads) are chosen is because they are workloads where the CPU really makes a difference and is interesting to the average reader if not because it's their problem, at least because they are close enough to be understandable.
(A separate 10 page post would be required to dig into the GPU role and impact of those tests)
On the other hand, measuring on, say, protein folding isn't likely to gather a lot of interest because most people are not buying laptops to run HPC research.
So, ultimately the reason videogames (and video encoding, compression, image processing and a few other workloads) are chosen is because they are workloads where the CPU really makes a difference and is interesting to the average reader if not because it's their problem, at least because they are close enough to be understandable.
(A separate 10 page post would be required to dig into the GPU role and impact of those tests)
It's important to note that a few years later, Intel came out with the P6 microarchitecture which was a huge surprise in the whole RISC/CISC debate.
And one that largely obviates almost every point made. In point of fact, in the 31 years (!) since this was posted the "clearly most successful/performant/useful/best" processor at any moment has almost always been an implementation of one particular CISC ISA that violates almost every rule Mashey posits.
This happened to look right in 1991 because SPARC and MIPS were riding high at that moment in history. Both would fall behind x86 a few years later.
And more to the point: this only looks right at this particular moment because Intel fell off the edge and Apple jumped ahead with a TSMC-manufactured part. But that's almost entirely down to process technology. If Intel was using TSMC's process then it's likely that the M1 switchover never would have happened.
This happened to look right in 1991 because SPARC and MIPS were riding high at that moment in history. Both would fall behind x86 a few years later.
And more to the point: this only looks right at this particular moment because Intel fell off the edge and Apple jumped ahead with a TSMC-manufactured part. But that's almost entirely down to process technology. If Intel was using TSMC's process then it's likely that the M1 switchover never would have happened.
AMD uses TSMC. Apple’s cores are still faster than AMD’s. Regardless, ARMv8 isn’t exactly RISC.
One example over three decades doesn't prove much. As pointed out, in 1992 the best CPU in the world was a SuperSPARC, with the MIPS R4000 about to leapfrog it. It didn't stick. I didn't say x86 offerings were uniformly and always better than RISC ISAs. I said it was almost always better, which sort of demolishes Mashey's arguments about the inherent superiority of the ISA design.
And in any case you're wrong on the facts. The M2 and Zen 3 cores are not being fabbed on the same process; AMD is still on 7nm for its CPU products vs. 5nm for Apple. Their use of 5nm is exclusively for GPUs so far.
And in any case you're wrong on the facts. The M2 and Zen 3 cores are not being fabbed on the same process; AMD is still on 7nm for its CPU products vs. 5nm for Apple. Their use of 5nm is exclusively for GPUs so far.
Would love Mashey’s thoughts on RISC V, but AFAICT he left the business a couple of decades ago.
Yes but RISC-V is very risc-y by the criteria Mashey proposes here. The one thing that arguably doesn't completely fit is the multiple insn sizes, and even then real-world RISC-V implementations have only two, at 2 or 4 bytes. That's still very low compared to historical CISC. And I think the atomic instructions do RMW to memory, but they carefully avoid complicated address modes; they even dispense with register+immediate offset.
(The E variety of RISC-V is also a bit strange in having only 16 integer registers, but the rationale for that was supporting smaller chips and easier extensibility; it's still very clearly a load-store architecture where compute happens within registers. Arguably, compilers have also gotten better at staying within fewer registers and not spilling to memory. So "number of registers" as a criteria might have shifted a little bit.)
(The E variety of RISC-V is also a bit strange in having only 16 integer registers, but the rationale for that was supporting smaller chips and easier extensibility; it's still very clearly a load-store architecture where compute happens within registers. Arguably, compilers have also gotten better at staying within fewer registers and not spilling to memory. So "number of registers" as a criteria might have shifted a little bit.)
MIPS did it too with the MIPS16 extension (https://en.wikipedia.org/wiki/MIPS_architecture#Application-...)
Makes sense as a hardware designer to be able to pick a power- and space-efficient chip.
Mashey also had thoughts about that: https://yarchive.net/comp/mips16.html
Likewise for atomic operations: https://yarchive.net/comp/ll_sc.html
Makes sense as a hardware designer to be able to pick a power- and space-efficient chip.
Mashey also had thoughts about that: https://yarchive.net/comp/mips16.html
Likewise for atomic operations: https://yarchive.net/comp/ll_sc.html
> The one thing that arguably doesn't completely fit is the multiple insn sizes, and even then real-world RISC-V implementations have only two, at 2 or 4 bytes.
They will have a third very soon. The encoding space for 4-byte instructions is almost spent.
They will have a third very soon. The encoding space for 4-byte instructions is almost spent.
Related:
John Mashey on RISC/CISC - https://news.ycombinator.com/item?id=9811397 - July 2015 (4 comments)
Others?
John Mashey on RISC/CISC - https://news.ycombinator.com/item?id=9811397 - July 2015 (4 comments)
Others?
It’s amazing how much of this is still valid.
One thing isn’t - 5a, unaligned access. Some modern RISCs allow this, probably because there’s enough code out there that does it.
One thing isn’t - 5a, unaligned access. Some modern RISCs allow this, probably because there’s enough code out there that does it.
I think the issue is due to the way modern memory architectures work alignment restrictions don't buy you much. In particular because memory accesses suck in a whole cache line. As long as all the data is in the cache line it's easy enough to swap bytes around on the fly.
More goodies: https://yarchive.net/comp/index.html