5 ms·

> It seems like we ought to have switched from CISC to RISC. If you ever have a question about computer architecture, ask two questions: 1) where does the memo

> It seems like we ought to have switched from CISC to RISC. If you ever have a question about computer architecture, ask two questions: 1) where does the memory bandwidth go, and 2) where does the die area go. All else follows from this. RISC only made sense when CPU clock speeds were at rough parity with central memory speed, on-chip I-caches were limited, pipelines were short, and compilers were only good at modest optimizations. If you look at functionality per instruction byte, RISC is fairly low. In today's world, CPU clocks are hugely faster than memory speeds, on-chip I-Caches are huge, pipelines are very very deep, branch prediction hardware is very good, and compiler back-ends are much much smarter than the peak days of RISC. CISC wins because the amount of functionality that you can move into the I-Cache per clock is higher and the amount of functionality you can keep in a given amount of I-Cache die area is higher, and compilers are good enough to target specialized instructions efficiently. Is what Intel has crammed into X86 impressive? Yes, very. And it was damn hard work. I can tell you that walking all the way out to byte 15 of an instruction to look at the MOD R/M byte to decide if you have to raise an illegal instruction exception is a painful long path to squeeze under the clock constraint. But breaking backwards compatibility is just not something customers will put up with. So logic and circuit designers get to ply their trade in it's most convoluted form with the X86. Perhaps these days I should amend my question list and add a third: 3) where does the power go? This is where ARM has an advantage over X86. The equations that you have to resolve to issue an X86 instruction are simply more complex than for ARM, and all that bit-flipping consumes power.

gaius 10y ago
If this were entirely true, VLIW would have been a clear win, but in practice it wasn't. ARM conditional execution is very clever.
- gpderetta 10y ago
  > ARM conditional execution is very clever. also mostly dead in 64bit armv8
  - Symmetry 10y ago
    They have a special instruction now to predicate the next N instructions or not. In out of order implementations you want each instruction to have as few inputs as possible and my understanding was that the implicit input in the form of the branch information was causing problems. I've heard conflicting things about whether ARM processors split predicated instructions into two ops during decode.
    - gpderetta 10y ago
      I'm way out of my depth as I know next to nothing about the ARM ISA, but as far as I know, there is no special instruction to predicate the next N instructions; conditional jumps don't count of course [1]. ARM v8 does have a predicated select instruction, but some form of it are available on many modern instruction sets. [1] interestingly, POWER8 is capable of converting unpredictable conditional jumps over a small number of instructions to conditional execution.
- legulere 10y ago
  VLIW is pretty much the same as a superscalar processor, except that the compiler has to do most of the work. Almost all high performance CPUs nowadays are superscalar.
  - soulbadguy 10y ago
    Not quite, VLIW is basically a lock-step architecture. VLIW is much closer to a SIMD/GPU architecture then to a superscalar CPU
- Symmetry 10y ago
  They work great in some situations, like playing back an MP3. If you're working with some problem where the memory accesses are either local or predictable enough that the prefetcher can guess right than a VLIW should be able to extract just as much parallelism as an OoO core and with less power. It's when you start suffering regular cache misses and the careful choreography of your VLIW instruction stream is thrown off that they start to lose. Which is most GUI programs, classical AI, web browsers and basically most things people do on desktops and servers so it's no surprise they lost there. But there are still lots of places in embedded computing where they're ubiquitous for good reason and your phone might very well have one in it too to offload some tasks to.
Altay- 10y ago
>But breaking backwards compatibility is just not something customers will put up with. There's no reason to believe this to be an immutable law going forward for much longer. With more and more going into the browser & cloud, how much is really left on the client side to be backwards compatable with these days? The first thing I do when I reformat is install chrome, login, and sync my Google Account. I have all my important documents on Google Drive, a full office suite in Google Docs, all my bookmarks, account logins, etc.
- pjmlp 10y ago
  Many of us don't live in the browser. Personally for me the web is HTML + CSS, for everything else there is a native application, even though I have done my share of web application projects. I also don't put my private data in the hands of strangers. Also do know lots of people that think like I do.
- krylon 10y ago
  > With more and more going into the browser & cloud, how much is really left on the client side to be backwards compatable with these days? For desktops/laptops and mobile phones, this may be true. For embedded device (where a lot of ARM chips end up) it is not an option, usually. Likewise, on Windows, there is a huge amount of third-party software that is, for better or worse, tied to the CPU architecture. And for a fair amount of that software, vendors are either unwilling to port it to a new CPU or have stopped supporting the software altogether (or have gone out of business). Consider the sad fate of Windows RT. Windows on low-end ARM devices might have been sweet (as far as Windows goes), but if the only piece of software it runs is IE/Edge and Office, it is not terribly useful.
legulere 10y ago
> If you look at functionality per instruction byte, RISC is fairly low. You should watch this video: https://www.youtube.com/watch?v=Ii_pEXKKYUg https://www.youtube.com/watch?v=Ii_pEXKKYUg The most important information therein is that the difference in code density is minuscule between x86, ARM and RISC-V. The differences between GCC versions is even bigger. > The equations that you have to resolve to issue an X86 instruction are simply more complex than for ARM, and all that bit-flipping consumes power. It's actually just 3-10% of power consumption [1] and I even heard it claimed that the instruction decoding on ARM is larger than x86 [1] https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool...
- microcolonel 10y ago
  Adding to your point; I don't think we can even consider ARM to be a RISC, as Chris Celio is quick to point out in that presentation. It has instructions which are very nearly as complex as x86s, and each year they come closer to having as many as x86 has as well.
  - renox 10y ago
    > I don't think we can even consider ARM to be a RISC, ARMv7 OK, is-it still true with ARMv8? It seems to be a much more 'reduced' ISA.
    - microcolonel 10y ago
      Every ARMv8 is also an ARMv7; since ARMv8 includes AArch32 in addition to AArch64. It still has Jazelle traps. It also has an 8-byte (though they brag that they only have 4-byte opcodes now) AES round instruction, and a SHA-256 permutation instruction. Admittedly some of AArch64 is much cleaner, it involves fewer new conditional instructions than you would expect for an ARM architecture; however it sure as hell ain't RISC.
stevefolta 10y ago
> RISC only made sense when CPU clock speeds were at rough parity with central memory speed, on-chip I-caches were limited, pipelines were short, and compilers were only good at modest optimizations. No, RISC was a response to CPUs becoming faster relative to memory access. Smaller decode logic meant more die space for registers and cache.

gaius 10y ago

If this were entirely true, VLIW would have been a clear win, but in practice it wasn't. ARM conditional execution is very clever.

gpderetta 10y ago
> ARM conditional execution is very clever. also mostly dead in 64bit armv8
- Symmetry 10y ago
  They have a special instruction now to predicate the next N instructions or not. In out of order implementations you want each instruction to have as few inputs as possible and my understanding was that the implicit input in the form of the branch information was causing problems. I've heard conflicting things about whether ARM processors split predicated instructions into two ops during decode.
  - gpderetta 10y ago
    I'm way out of my depth as I know next to nothing about the ARM ISA, but as far as I know, there is no special instruction to predicate the next N instructions; conditional jumps don't count of course [1]. ARM v8 does have a predicated select instruction, but some form of it are available on many modern instruction sets. [1] interestingly, POWER8 is capable of converting unpredictable conditional jumps over a small number of instructions to conditional execution.
legulere 10y ago
VLIW is pretty much the same as a superscalar processor, except that the compiler has to do most of the work. Almost all high performance CPUs nowadays are superscalar.
- soulbadguy 10y ago
  Not quite, VLIW is basically a lock-step architecture. VLIW is much closer to a SIMD/GPU architecture then to a superscalar CPU
Symmetry 10y ago
They work great in some situations, like playing back an MP3. If you're working with some problem where the memory accesses are either local or predictable enough that the prefetcher can guess right than a VLIW should be able to extract just as much parallelism as an OoO core and with less power. It's when you start suffering regular cache misses and the careful choreography of your VLIW instruction stream is thrown off that they start to lose. Which is most GUI programs, classical AI, web browsers and basically most things people do on desktops and servers so it's no surprise they lost there. But there are still lots of places in embedded computing where they're ubiquitous for good reason and your phone might very well have one in it too to offload some tasks to.

Altay- 10y ago

>But breaking backwards compatibility is just not something customers will put up with. There's no reason to believe this to be an immutable law going forward for much longer. With more and more going into the browser & cloud, how much is really left on the client side to be backwards compatable with these days? The first thing I do when I reformat is install chrome, login, and sync my Google Account. I have all my important documents on Google Drive, a full office suite in Google Docs, all my bookmarks, account logins, etc.

pjmlp 10y ago
Many of us don't live in the browser. Personally for me the web is HTML + CSS, for everything else there is a native application, even though I have done my share of web application projects. I also don't put my private data in the hands of strangers. Also do know lots of people that think like I do.
krylon 10y ago
> With more and more going into the browser & cloud, how much is really left on the client side to be backwards compatable with these days? For desktops/laptops and mobile phones, this may be true. For embedded device (where a lot of ARM chips end up) it is not an option, usually. Likewise, on Windows, there is a huge amount of third-party software that is, for better or worse, tied to the CPU architecture. And for a fair amount of that software, vendors are either unwilling to port it to a new CPU or have stopped supporting the software altogether (or have gone out of business). Consider the sad fate of Windows RT. Windows on low-end ARM devices might have been sweet (as far as Windows goes), but if the only piece of software it runs is IE/Edge and Office, it is not terribly useful.

legulere 10y ago

> If you look at functionality per instruction byte, RISC is fairly low. You should watch this video: https://www.youtube.com/watch?v=Ii_pEXKKYUg https://www.youtube.com/watch?v=Ii_pEXKKYUg The most important information therein is that the difference in code density is minuscule between x86, ARM and RISC-V. The differences between GCC versions is even bigger. > The equations that you have to resolve to issue an X86 instruction are simply more complex than for ARM, and all that bit-flipping consumes power. It's actually just 3-10% of power consumption [1] and I even heard it claimed that the instruction decoding on ARM is larger than x86 [1] https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool...

microcolonel 10y ago
Adding to your point; I don't think we can even consider ARM to be a RISC, as Chris Celio is quick to point out in that presentation. It has instructions which are very nearly as complex as x86s, and each year they come closer to having as many as x86 has as well.
- renox 10y ago
  > I don't think we can even consider ARM to be a RISC, ARMv7 OK, is-it still true with ARMv8? It seems to be a much more 'reduced' ISA.
  - microcolonel 10y ago
    Every ARMv8 is also an ARMv7; since ARMv8 includes AArch32 in addition to AArch64. It still has Jazelle traps. It also has an 8-byte (though they brag that they only have 4-byte opcodes now) AES round instruction, and a SHA-256 permutation instruction. Admittedly some of AArch64 is much cleaner, it involves fewer new conditional instructions than you would expect for an ARM architecture; however it sure as hell ain't RISC.

stevefolta 10y ago

> RISC only made sense when CPU clock speeds were at rough parity with central memory speed, on-chip I-caches were limited, pipelines were short, and compilers were only good at modest optimizations. No, RISC was a response to CPUs becoming faster relative to memory access. Smaller decode logic meant more die space for registers and cache.