9 ms·

CISC vs RISC is almost completely irrelevant these days. They both borrowed so many ideas from each other that the architectures are nearly identical these day

• userbinator 8y ago
  That's got to waste transistor and power budgets. In comparison, when an ARM CPU is in A64 mode, all instructions are the same length, making decoding multiple instructions per cycle trivial. On the other hand, that wastes cache memory and fetch bandwidth. Instruction density is very important especially since caches are big and consume a lot of power too. I believe that if it weren't for the brief period in the 80s where memory speeds were higher than core speeds, what we know as "RISC" today would've never appeared.
  • voidlogic 8y ago
    "On the other hand, that wastes cache memory and fetch bandwidth..." This. One of the reasons why modern x86 processors have such strong performance is their external facing CISC interface effectively acts as memory compression while they are RISC on the inside. In many ways its a best of both worlds that was achieved through incremental evolution.
    • 0815test 8y ago
      Nope, you don't need anything like the complexity of x86 decode in order to reach good instruction density. RISC-V matches x86 with a simple "compressed" extension involving 16-bit forms for some of the most common instructions (but still quite straightforward to decode in hardware).
      • voidlogic 8y ago
        I agree. Its almost always more performant to intentionally build a system that to have characteristics that another system incrementally evolved to have. This is why rewritten software (if actually delivered) often performs better than the original, its usually this and not new framework X or new language Y that resulted in the win.
    • phkahler 8y ago
      And RISC-V encodes programs into fewer bytes than X86, so it wins in that regard. But there are still no implementation that have all the other features needed for top performance. There are many factors that affect performance.
      • voidlogic 8y ago
        "There are many factors that affect performance." Not only man different features contribute to performance but also that put performance depends so much on use-case. Two CPUs implementing the same arch might each win a benchmark that has a different instruction mix or memory access pattern, etc.
    • AnIdiotOnTheNet 8y ago
      Not being any kind of expert in processor microarchitecture, I wonder if there is potential in just actually compressing instructions, as in with a huffman table. Could hardware decoding be made fast enough that the cache and fetch savings would make up for it?
      • BeeOnRope 8y ago
  • xxs 8y ago
    Indeed, usually optimizing for size is optimizing for speed (less cache pressure, deeper pipelines, etc.)
    • rbanffy 8y ago
      OTOH, if you can move a couple billion transistors from instruction decode and reordering to the L1 cache and execution pipelines, you'll get less cache pressure and deeper pipelines. There is no magic - down at the back-end, x86's and ARMs are doing the same thing and getting the same performance will cost about the same chip area and power. Where they differ, however, is on the front-end, the pieces that decode instructions, issue micro operations and schedule them through to the execution units. In that space ARM64 seems more promising. Unless, of course, Intel decides to throw away a lot of the backwards compatibility and goes very low-transistor-budget for legacy instructions (maybe software traps), freeing a ton of chip area to implement the ones they care about in a fast and power efficient way. That x86 would be unable to run DOS, but I don't think many of us would care.
      • StrangeDoctor 8y ago
        OTOOH, you can't just add a couple of MB of L1 cache without increasing delays and even trying to add to other layers would result in much more complicated lookups.
        • rbanffy 8y ago
          You may be unable to significantly enlarge the caches, but you could assign a larger cache to each core or privilege level, a larger, less shared, L2 or L3 or even go like the IBM z and implement an L4 cache.
  • renox 8y ago
    Except that nearly all the RISCs have a 16-bit instruction extension which brings their instruction density nearly equal to the CISCs' one. And the decoding remain much simpler than the CISC's one. That said ForwardCom blur the bondary between CISC and RISC..
    • 0815test 8y ago
      > Except that nearly all the RISCs have a 16-bit instruction extension Notably, ARM64 is one RISC ISA that doesn't have that sort of extension.
    • gok 8y ago
      ARM64 doesn't have a 16-bit instruction mode any more
      • Symmetry 8y ago
        I'm actually sort of surprised that ARM doesn't do that. Given that they have Thumb sitting there for them to use and given that i-cache pressure is an important consideration sometimes I would tend to assume it would be a no-brainer. Given that ARM's architects know more about this than I do I have to conclude that there are more disadvantages to even simple variable length instruction encodings than I would assume. Has anyone made a R64GC out of order core yet?
        • monocasa 8y ago
          https://github.com/riscv-boom/riscv-boom https://github.com/riscv-boom/riscv-boom Open source, and taped out.
          • Symmetry 8y ago
            Oh, nice! I'd last seen the original presentation when BOOM was still going to use just 32 bit instructions. Section 2.2 from here[1] goes into some details on the challenges of using compressed instructions and how they deal with them. https://docs.boom-core.org/en/latest/sections/instruction-fetch-stage.html https://docs.boom-core.org/en/latest/sections/instruction-fe...
  • BeeOnRope 8y ago
    This is true in an abstract comparison between fixed and variable length encodings, but not really true in the specific comparison of AArch64 and x86: the latter is far from an ideal fixed-length encoding, largely because of path dependent development of the current ISA. A significant amount of space is wasted on old rarely used instructions, and the x86-64 encoding was chosen mostly based on similarly with the earlier 32-bit ISA, which uses decades old instruction frequencies. The addition of many ISA extensions has become progressively more difficult: the newest AVX-512 instructions which use the EVEX encoding have 4 (!!) prefix bytes before the instruction even starts. So just the prefix is as long as any AArch64 instruction. The net result is that AAarch64 binary sizes are largely comparable with x86, and there is still a bit of juice to squeeze out as well as the ARM compiler backends haven't had the same decades of heavy optimization compared to x86.
    • Symmetry 8y ago
      Also, ARM is one of the densest RISC-style ISAs. A64 less so than A32 but it still has things like conditional execution of some of the most common instructions, loading two registers in one instruction, etc.
    • pcwalton 8y ago
      Yup. Not to mention all the REX prefixes which add a byte to nearly every instruction.
  • pcwalton 8y ago
    > Instruction density is very important especially since caches are big and consume a lot of power too. Which hurts x86 a lot, because x86-64 is very space inefficient for a variable length ISA. The REX prefixes add up to make x86-64 just as space-inefficient as AArch64.
• DSingularity 8y ago
  It makes a difference. X86 decode is difficult. Trace cache helps decode, but with diminishing returns. As for consistency, it makes things difficult. Increases complexity of speculation and coherence. But honestly, the way forward is quite obvious. Cores with self managed caches and ideally without coherence.
• ajross 8y ago
  > Still, there are a few areas where the A64 architecture is theoretically "better" than x64, due to the lack of legacy. Every extant A64 processor needs to deal with ARMv8 instructions, thumb instructions, thumb2 instructions, shift encoding, microcoded multiple load/store instructions... It's true that the subset of the ISA that makes up the overwhelming bulk of instructions actually executed is very simple. But frankly that's true of x86 as well. > when an ARM CPU is in A64 mode That's... not the way hardware works. Those transistors are still there, it's not like you can make them go away by switching "modes". They still are ready to switch every cycle, and in any case having transistors that "aren't needed" doesn't make anything faster, because they all execute in parallel (or at worst in an extra pipeline stage or two) anyway. Either you have a simple architecture or you don't. A64 is a simple ISA. Real CPUs have complicated legacy architectures.
  • twtw 8y ago
    > That's... not the way hardware works. Regarding transistor / area budget, sure. Regarding power budget, that absolutely could be the way hardware works. Modern chips can and do power off pieces of silicon when they are not needed. Whether that would be worth it for instruction decoding, I don't know, but it could be.
    • arghwhat 8y ago
      Powering off pieces of silicon when they are not needed is done through "clock gating", where you stop feeding a clock to a block that is not needed. That is only possible when you deal with isolated parts. You cannot, for example, power down an instruction decoders ability to understand different syntaxes, but only power down the entire instruction decoder. Trying to design it so that sub-features of a block like that can be powered down would not be productive. A realistic clock-gating would be something like powering down the actual execution units ("We don't need AVX-512, so lets not waste power on the execution units"), but that doesn't help in saving power wasted on legacy.
      • twtw 8y ago
        Thus >> Whether that would be worth it for instruction decoding, I don't know There would be significant overhead to design a decoder such that it could switch between legacy and aarch64 only, but it could conceivably be done. fyi clock gating isn't the same as power gating.
• ComputerGuru 8y ago
  x64's changes to memory ordering guarantees that would theoretically give it more room for optimization as compared to x86 are purely hypothetical. In practice, so much real-world code was written for and battle-tested on x86's extremely generous ordering, and Intel does not avail itself of performance gains it could do at the risk of completely breaking traditional software (even when not running in x86_64 mode).
• gok 8y ago
  Load/store vs. register–memory can still be relevant. Moreover, x86 still generally allows sloppier code to perform better, which practically means that a lot of non-x86 relative performance depends on the compiler. The rise of better compilers has changed the calculus here substantially.
• bitwize 8y ago
  No one is developing new CISC architectures. The ones that are out there are extant mainly because of inertia. I think it's safe.to say that RISC architecture has already changed everything.
  • deleted 8y ago
    [deleted]
• snvzz 8y ago
  >CISC vs RISC is almost completely irrelevant these days. This nonsense keeps coming up. No, it's not irrelevant. It matters. A lot. A CISC design is complex, but it doesn't stop there. This complexity spreads down the chain. Implementations get complex, bugs happen. Making formal proofs of an implementation's correctness becomes impossible. Writing a compiler back end will be complex. Debugging it will be complex. Writing a proof that the machine code meets both the ISA specification and implements the same thing the higher level language does is also complex. Now, where's the advantage of CISC to justify this complexity? Yeah, right.
  • aseipp 8y ago
    If we're talking about desktop processors, it's still irrelevant, honestly; any desktop processor that can compete in a modern world is extraordinarily complex in implementation at every level. POWER, ARM, RISC-V, x86 -- they all try to extract high performance using similar techniques in their execution engines. Out of order execution, pipelined decoding etc are architecture design aspects and have little to do with the ISA. Front-end decoding, etc traditionally takes an extremely small amount of area and space in the overall system, though it's still complex (it's kind of hard to talk about raw "area" metrics when cache is what dominates and is most important.) But the CPUs themselves are incredibly complex, no matter what way you cut it. If you're talking about embedded CPUs or whatnot, such as picorv32, the frontend is a relatively bigger piece of the "pie" so having a simpler ISA is nice. But really, verifying any CPU design is complex as hell and the decoders/frontends are not the biggest problem (even in RISC-V a source of bugs I've seen float around and even fell into myself, for my own emulator, is the semantics of JALR clearing low bits, for instance -- but that's not a decoding problem, it's a semantics one, flat out. Also, let's be real here, the whole memory-model approach in RISC-V where there's a spectrum of extensions adding TSO on top of weak memory ordering etc is nice and cool but I'd hardly call it fitting in the form of what people think of as a "simple" RISC CPU. That's not even getting into the array of other extensions that will crop up -- bitmanip, a crypto extension will almost certainly pop up, the vector extension, etc etc...) Programmers love speculating and talking about the ISA and attaching words like "RISC" and "CISC" to everything. Everyone says x86 is a RISC not a CISC because "microcode" or whatever, but honestly who cares? Maybe it is, maybe it isn't, but ultimately it's just a superficial moniker for what you're fundamentally interacting with, and nobody who designs CPUs thinks this way anymore. It's an descriptive moniker from a bygone era, when today most systems have converged very closely in many of their core design decisions, and most of the differentiating features are things like various security extensions, interconnect support (because the interconnect is king), and software support. For things like designing CPUs or formal verification it's a small part of the overall job and you have about 9,000,000 other problems on your plate.
• temac 8y ago
  > The second area is memory consistency guarantees. x64 has relatively strong guarantees, allowing simpler assembly code but at the cost of more complex memory subsystem between cores. A64 has much weaker ordering guarantees, which saves on hardware complexity, but required the programmer (and/or compiler) to insert memory fences whenever stricter ordering is required. I'm not a fan at all of weak memory models. Especially when it results (is it caused by that? probably?) in atomics being crazy slow compared to those of state of the art x86. Especially since multicore is crucially important and will continue to become even more, and there is no SW solution to a HW providing slow atomics.