4 ms·
RISC vs CISC made a big difference when we had 100k-200k transistors to play with. That was a long time ago. Today's machines aren't CISC or RISC internally -
by pjdesno 4y ago
RISC vs CISC made a big difference when we had 100k-200k transistors to play with. That was a long time ago.
Today's machines aren't CISC or RISC internally - they're ginormous out-of-order execution engines doing stuff that really can't be expressed in a linear machine language, and if there's an overhead for CISC, it's a tiny additional amount of real estate per core. Note that this is not a constant factor - as the rest of the CPU gets more complex, any CISC-related overhead becomes a smaller and smaller fraction of the whole. You can probably take the same set of execution units, forwarding paths, branch predictors, etc. and slap several different ISAs over it - I've seen CPU architects show experiments where (for x86 and ARM at least) two chips with the same number and type of these internal features will perform the same regardless of the instruction set.
There are a lot of factors involved other than the now-tiny technical advantage of RISC. There's a strong business incentive for the largest CPU design team in the world (i.e. Intel) to continue to produce x86 CPUs, rather than switching to another ISA. (for that matter, they tried once, with Itanic^H^H^HItanium, and it didn't work out so well)
Ecosystem effects mean that CPUs with non-dominant ISAs incur a bunch of various costs for their users, because everything from software through hardware just gets harder when you're not on the dominant commodity platform. (don't get me started on my experience with some POWER9 machines over the last few years...) A non-x86 CPU that's marginally faster/$ than an x86 isn't good enough - it needs to be substantially faster before it's worth the expense of switching, plus some more just to be sure that things won't swing the other way far enough to force you to switch back and pay that price all over again.
Most of the other observations in the post are spot-on, though...
- batman-farts 4y ago> You can probably take the same set of execution units, forwarding paths, branch predictors, etc. and slap several different ISAs over it - I've seen CPU architects show experiments where (for x86 and ARM at least) two chips with the same number and type of these internal features will perform the same regardless of the instruction set. Isn’t this what Transmeta was trying to do back in the day? I remember they famously employed Linus Torvalds for a while, but I never learned anything about the technical details of their ISA front-ends.
- batman-farts 4y agoForgive me, it looks like I had mis-remembered, and Transmeta’s translation layers were mainly software?
- FullyFunctional 4y agoIt was purely software, but future developments of the idea (like NVIDIA Denver) wasn't purely software. However, the backend is necessarily tried to the ISA you are emulating (true for all of them, including SoftMachine). You need the data types to match (eg. Transmeta supported x87-style FP) to have any hope of performance. The universal machine is neither possible nor desirable (it would be inefficient). These days the IMO most interesting ISA from a JIT point of view is WASM as it's the one that offers the most information (context) and the fewest constraints on the implementation.
- AnotherGoodName 4y agoThe AM29000 is probably what you're thinking of. AMD turned it into the more well known x86 processor the K5 among other things.
- gpderetta 4y agoExactly. These days, the only remaining difference between RISCs and CISCs are simpler fixed size encodings and a load-store architecture.