3 ms·

While mostly missing the mark, and just rehashing the old discussions. AKA the micro architecture concepts of both "RISC" designs and "CISC" designs is so simil

While mostly missing the mark, and just rehashing the old discussions. AKA the micro architecture concepts of both "RISC" designs and "CISC" designs is so similar across product lines as to be mostly meaningless. As mentioned you have RISC designs using "micro ops" and microcode, and you have CISC designs doing 1:1 instruction micro op mapping. Both are doing various forms of cracking and fusing depending on the instruction. All have the same problems with branch prediction, speculative execution, and solve problems with OoO in similar ways. Maybe the largest remaining difference is around the strength of the memory model, as the size of the architectural register file, and the complexity of addressing modes and other traditional RISC/CISC arguments are mostly pointless in the face of deep OoO superscaler machines doing register renaming/etc from mop caches, etc. Even then, like variable length instructions (which yes exist on many RISCs in limited forms) this differentiation is more about when the ISA was designed rather than anything fundamental in the philosophy.

socialdemocrat 6y ago
The key difference between RISC and CISC is the ISA, which is still true. x86 have instructions which can in theory be infinitely long. RISC instructions are typically fixed length. Yes there are exceptions but that is how most instructions are designed. RISC ISA is still designed around Load/Store, while e.g. x86 has a variety of address modes. All these differences in the ISAs has some impact on what makes sense to do in the micro-architecture and how well you can do it. Sure you can pipeline ANY CPU, but it will be easier to do so when you deal with mostly fixed width instructions, of quite similar complexity. On x86 there will be much more variety in the complexity each instruction and you will be more prone to get gaps in the pipeline. As far as I understand anyway.
- FullyFunctional 6y ago
  I don't know why this was downvoted as it's exactly right. The ISA does matter, especially for the frontend. Intel overcame the tax through essentially brute-force, but it's taken until now for the playing field to be level enough that the differences show up. There will never be an 8-wide decode x86 (issuing from a trace- or uop-cache doesn't count). (edited for clairity)
deleted 6y ago
[deleted]
dragontamer 6y ago
> Maybe the largest remaining difference is around the strength of the memory model If it weren't for the following project... I'd agree with you. https://github.com/saagarjha/TSOEnabler https://github.com/saagarjha/TSOEnabler > A kernel extension that enables total store ordering on Apple silicon, with semantics similar to x86_64's memory model. This is normally done by the kernel through modifications to a special register upon exit from the kernel for programs running under Rosetta 2; however, it is possible to enable this for arbitrary processes (on a per-thread basis, technically) as well by modifying the flag for this feature and letting the kernel enable it for us on. Setting this flag on certain processors can only be done on high-performance cores, so as a side effect of enabling TSO the kernel extension will also migrate your code off the efficiency cores permanently. -------- Its clear that Apple has implemented total-store ordering on its chips (including the M1).
- StillBored 6y ago
  That is way cool, the question is can someone compare the perf on a normal mac/arm application with it on/off? Presumably its a hit, otherwise they would have just left it on. I guess its more a question of whether its a .5% hit or a 10% hit.
  - dragontamer 6y ago
    It would be hard to benchmark. Any single-threaded program wouldn't care at all, because you're just plucking values out of store-buffers (aka: store-to-load forwarding) anyway. There needs to be some kind of multithreaded benchmark, maybe a mutex ping-pong or spin lock ping-pong, to really see the difference. Well... hypothetically anyway. It seems like something that's very hard to actually test for.

socialdemocrat 6y ago

The key difference between RISC and CISC is the ISA, which is still true. x86 have instructions which can in theory be infinitely long. RISC instructions are typically fixed length. Yes there are exceptions but that is how most instructions are designed. RISC ISA is still designed around Load/Store, while e.g. x86 has a variety of address modes. All these differences in the ISAs has some impact on what makes sense to do in the micro-architecture and how well you can do it. Sure you can pipeline ANY CPU, but it will be easier to do so when you deal with mostly fixed width instructions, of quite similar complexity. On x86 there will be much more variety in the complexity each instruction and you will be more prone to get gaps in the pipeline. As far as I understand anyway.

FullyFunctional 6y ago
I don't know why this was downvoted as it's exactly right. The ISA does matter, especially for the frontend. Intel overcame the tax through essentially brute-force, but it's taken until now for the playing field to be level enough that the differences show up. There will never be an 8-wide decode x86 (issuing from a trace- or uop-cache doesn't count). (edited for clairity)

deleted 6y ago

[deleted]

dragontamer 6y ago

> Maybe the largest remaining difference is around the strength of the memory model If it weren't for the following project... I'd agree with you. https://github.com/saagarjha/TSOEnabler https://github.com/saagarjha/TSOEnabler > A kernel extension that enables total store ordering on Apple silicon, with semantics similar to x86_64's memory model. This is normally done by the kernel through modifications to a special register upon exit from the kernel for programs running under Rosetta 2; however, it is possible to enable this for arbitrary processes (on a per-thread basis, technically) as well by modifying the flag for this feature and letting the kernel enable it for us on. Setting this flag on certain processors can only be done on high-performance cores, so as a side effect of enabling TSO the kernel extension will also migrate your code off the efficiency cores permanently. -------- Its clear that Apple has implemented total-store ordering on its chips (including the M1).

StillBored 6y ago
That is way cool, the question is can someone compare the perf on a normal mac/arm application with it on/off? Presumably its a hit, otherwise they would have just left it on. I guess its more a question of whether its a .5% hit or a 10% hit.
- dragontamer 6y ago
  It would be hard to benchmark. Any single-threaded program wouldn't care at all, because you're just plucking values out of store-buffers (aka: store-to-load forwarding) anyway. There needs to be some kind of multithreaded benchmark, maybe a mutex ping-pong or spin lock ping-pong, to really see the difference. Well... hypothetically anyway. It seems like something that's very hard to actually test for.