4 ms·
I really think people put more focus in the RISC vs CISC dichotomy than it deserves. ARMv8 CPUs have microcode, a mixture of instruction sizes, instructions whi
by ch_123 8y ago
I really think people put more focus in the RISC vs CISC dichotomy than it deserves. ARMv8 CPUs have microcode, a mixture of instruction sizes, instructions which take more than one clock cycle to complete, and a very large number of instructions overall - i.e. probably doesn't fit into most traditional definitions of RISC.
The challenges that ARM face while competing with x86 are software maturity, and moving away from low-cost low-power designs towards larger and more performant design (which will consume more power and cost more than traditional ARM designs)
- baybal2 8y agoI am frequently asked about that. This is what I tell: ARM feels free to do a complete ISA revision from ground up once or twice a decade, x86 on other hand is still bound to incremental improvement on a frail foundation laid in seventies. X86 only had three major revisions 16 bit to 32 bit and to 64 bit (the last one wasn't even done by Intel itself.) x86 biggest weakness is its dependence on wintel that precludes them from the very needed major isa revisions. If you look at atom dies, the overcomplicated decoder and other x86 vestiges take more area than the rest of the core. A12x is remarkable in that it gets close to 15 watt Intel CPUs with LESS die area and lower power consumption. And if you remove the useless things like NPU, DRM stuff, security coprocessor, and other useless peripherals from calculation, the comparison will really begin to look dire for Intel. Adding to that, even if we take into consideration that Intel is still on 14nm and A12x is a 7nm part, A12x still wins even if Intel will make a die shrink on 7nm. And you also have to consider that Intel has squeezed all and everything in terms of power efficiency from 14nm node after 5 years of active development on it, while Apple really went for the very first baseline revision of TSMC 7nm. Moreover, what I hear from the scene here in Shenzhen is that in A12x Apple did not really put much into power saving: A12x has nothing comparable to Intel's complex runtime power management, power and clock gating, separate power domains, and on-package smart dc-dc converters. If Apple will commit itself to squeezing more power efficiency from their chips with equal zeal, I believe they add additional 25-35% to their power advantage.
- userbinator 8y agoIf you look at atom dies, the overcomplicated decoder and other x86 vestiges take more area than the rest of the core. The Atom is a bit of an edge-case since it has barely any cache (and the performance is exactly what you'd expect from that), yet it still takes up a significant amount of the die; in all other CPUs, the caches are far bigger.
- Symmetry 8y agoThe difficulty of decoding multiple x86 instructions in a single clock cycle is a small issue in the context of a big out-of-order core. But it's a millstone around Intel's neck when they try to make a simple superscalar in-order core like the Atom.
- writepub 8y agoAt this point, most performance gains stem from: 1. L1, L2, L3 cache sizes. Since these are implemented as S-RAM, they can drastically increase chip area, and hence cost. 2. ISA Acceleration of certain types of algorithms - like encryption, codecs and AI. There's absolutely nothing inherently lacking in the ARM ISA or architecture to impact #1, and ARM has consistently been adding instructions for #2, including SIMD support. Apple chips perform so well as Apple can afford more cache for the same $ cost, as they make their own chips. Android phone manufacturers need to pay more for Qualcomm to make their profits
- baybal2 8y agoYou have to add more context... A12x advantage comes not only from gigantic caches, but in how efficient is the core in using them. Anybody well versed in microarchitecture design will tell that at some point increasing cache size will actually begin to slow you down. Both cache topology, address lookup logic, prefetch, and the dark magic like smart cache invalidation circuits matter a lot. The goal is to flush as few bits on cache miss as possible, find stored values in cache faster, and do prefetch efficiently. Only once you can do that, the cache size/core complexity tradeoff begins to work. Any normal CPU benchmark will be measuring a non accelerated workload. So, the measurements of A12x having a true lead thanks to wider pipeline, bigger caches, and smarter cache management are something very well expected.
- writepub 8y agoAgree. But the presumption is that eventually, cache management algorithms will reach parity with the competition/bleeding edge. Any and all parameters that can be tweaked will be. All top CPU arch companies hire from the same pool of PhDs/M.S' from top schools, after-all. Performance commoditization is truly upon us. ARM v.s. x86 is quite literally a battle of existing software binary support. Things like WASM and JIT will further obviate the need to worry about ISAs when making product design choices. As of 2019, you can't go wrong picking an ARM based design, given you picked a SOC with sufficient cache, etc. that your use case demands.
- 8y ago
- Symmetry 8y agoThe biggest difference between x86 and ARM for a big out-of-order machine is probably the much stronger memory ordering guarantees that x86 provides. There are good points to be made on either side of that but it's clearly a very important consideration. The second biggest difference is that, in a big OoO core, the cost of decoding the instruction stream is trivial on ARM as opposed to merely small on x86. Something like 5% of the cores power budget on a modern x86, I think? One upshot of that is that on Intel chips the decode stage is balanced with the overall execution width so that they are only seldom decode limited. Whereas the attitude on high end ARM chips is that you might as well just throw in more decoders than you think you need so you can stop worrying about it. But overall ARM has traditionally been the CISCiest of the RISC architectures and x86 has been the RISCiest of the CISC architectures,[1] making me think they might have both ended up successful by being at a sort of happy medium. [1]https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html
- userbinator 8y agox86 has been the RISCiest of the CISC architectures I agree completely if you mean "RISCiest" as in the complexity of decoding instructions. Look at the opcode map of a VAX, for example --- instructions were simply added where they fit, so there's no easily discernable pattern in the bits of the first opcode byte. x86 has an octal structure to its instructions[1] and the first quarter of the opcode map (000 through 077 octal) contains nearly all the commonly used ALU operations. The 8086 along with the Z80 and its predecessors had to be implemented on a single chip, which put constraints on how complex its instruction encoding could be, which could explain why a regular structure (but not fixed length) was adopted instead of a more "true CISC" way of making every instruction opcode arbitrarily increasing and microcoding everything. [1] https://news.ycombinator.com/item?id=9322723 https://news.ycombinator.com/item?id=9322723