5 ms·

John Mashey on RISC/CISC (1991)

41 points by goranmoomin 4y ago

KerrAvon 4y ago
Would love Mashey’s thoughts on RISC V, but AFAICT he left the business a couple of decades ago.
- zozbot234 4y 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.)
  - 33985868 4y ago
    MIPS did it too with the MIPS16 extension (https://en.wikipedia.org/wiki/MIPS_architecture#Application-specific_extensions 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 https://yarchive.net/comp/mips16.html Likewise for atomic operations: https://yarchive.net/comp/ll_sc.html https://yarchive.net/comp/ll_sc.html
  - Tuna-Fish 4y ago
    > 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.
dang 4y ago
Related: John Mashey on RISC/CISC - https://news.ycombinator.com/item?id=9811397 https://news.ycombinator.com/item?id=9811397 - July 2015 (4 comments) Others?
kjs3 4y ago
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".
- mhh__ 4y ago
  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)
  - kjs3 4y ago
    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.
    - xanathar 4y ago
      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)
    - mhh__ 4y ago
      Excel and word don't stress my machine, games do.
userbinator 4y ago
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.
- ajross 4y ago
  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.
  - skavi 4y ago
    AMD uses TSMC. Apple’s cores are still faster than AMD’s. Regardless, ARMv8 isn’t exactly RISC.
    - ajross 4y ago
      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.
33985868 4y ago
Here's a better link with the full content: https://yarchive.net/comp/risc_definition.html https://yarchive.net/comp/risc_definition.html More goodies: https://yarchive.net/comp/index.html https://yarchive.net/comp/index.html
pizlonator 4y ago
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.
- Gibbon1 4y ago
  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.

41 points by goranmoomin 4y ago

KerrAvon 4y ago

Would love Mashey’s thoughts on RISC V, but AFAICT he left the business a couple of decades ago.

zozbot234 4y 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.)
- 33985868 4y ago
  MIPS did it too with the MIPS16 extension (https://en.wikipedia.org/wiki/MIPS_architecture#Application-specific_extensions 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 https://yarchive.net/comp/mips16.html Likewise for atomic operations: https://yarchive.net/comp/ll_sc.html https://yarchive.net/comp/ll_sc.html
- Tuna-Fish 4y ago
  > 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.

dang 4y ago

Related: John Mashey on RISC/CISC - https://news.ycombinator.com/item?id=9811397 https://news.ycombinator.com/item?id=9811397 - July 2015 (4 comments) Others?

kjs3 4y ago

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".

mhh__ 4y ago
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)
- kjs3 4y ago
  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.
  - xanathar 4y ago
    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)
  - mhh__ 4y ago
    Excel and word don't stress my machine, games do.

userbinator 4y ago

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.

ajross 4y ago
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.
- skavi 4y ago
  AMD uses TSMC. Apple’s cores are still faster than AMD’s. Regardless, ARMv8 isn’t exactly RISC.
  - ajross 4y ago
    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.

33985868 4y ago

Here's a better link with the full content: https://yarchive.net/comp/risc_definition.html https://yarchive.net/comp/risc_definition.html More goodies: https://yarchive.net/comp/index.html https://yarchive.net/comp/index.html

pizlonator 4y ago

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.

Gibbon1 4y ago
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.