4 ms·

This article suggests that on a Haswell, decoders consumed between 3 and 10% of the power, depending on the workload tested: https://www.usenix.org/system/files

• paulmd 5y ago
  Haswell is a much narrower architecture than A14 though - 4-wide decode vs 8-wide for Firestorm. So it's 3-10% for an implementation that does significantly less than Apple's. And the problem is that x86 has geometric complexity as you go wider, so it consumes significantly more if you want to go as wide as Apple did. You're saying "nothing wrong with an n^2 algorithm, it works fine for us with n=1000", when you're comparing against someone who is showing results for n=1M. Obviously it would be better for someone in the latter situation to use an n-log-n algorithm. Not real numbers or transistor order-complexities, but you get the idea, x86 has asymptotically worse transistor complexity than ARM as you increase the decode width, and that is true. Also, that number is for a full-fat Performance Core. If the rest of the core shrinks, the decoder gets relatively bigger, unless you reduce its performance too. So the amount of decoder area (as a % of the overall core) is worse on efficiency cores than performance cores, because there's less "everything else" there. (likely you will reduce the decoder somewhat, Goldmont and Gracemont both use a 3-wide instead of 4-wide, but geometric scaling means that it's much more expensive to scale wider than you would save from scaling down. And the reliance on 'tricks' like instruction cache likely won't scale nearly as well - it's the same amount of "hot code" for many tasks, regardless of how many threads are running in it, because most of the work happens in certain hotspots. The increased overhead of decoding could, among other factors, be one of the reasons why Gracemont e-cores are not particularly appealing in perf/area. They are very solid on performance but the area scaling isn't all that great compared to hyperthreaded Golden Cove Performance Cores.) Also that's really just looking at one part of the processor in isolation. OK, so the decoder only consumes 3-10%, but that doesn't say anything about how it limits the ways the rest of the processor to scale. Everyone loves car analogies, it doesn't matter how big an engine you put in the car if it has a rinky-dink air intake that can't provide enough air to fully utilize its displacement. Looking at "the size of the air intake relative to the size of the engine bay" doesn't give you a realistic picture of how it affects the ability of the rest of the design to scale. A turbo might allow you to scale the rest of the engine up much larger than a naturally aspirated one. (or maybe the fuel system might be a better analogy...) As far as the instruction cache - those are tricks can be used on ARM architectures too (and I believe Apple does?), they aren't themselves a substitute for a scalable ISA, they're treating the symptom. They may do more on an architecture that is more bottlenecked in that area, but they do give you at least some speedup on everything. Treating the symptoms is really orthogonal to the topic of how much an ISA limits decoding width or reorder depth in itself. Anyway, x86 isn't Itanium and it isn't going anywhere, but it strongly looks to me like ARMv8 is on a solid foundation that solves some weaknesses of the x86 design. It's a clean-sheet "how would we do out-of-order/speculation if we could design our instructions over again" and it largely achieves that goal IMO. I don't see it as an inherent law of the universe that "there must exist enough tricks for x86 to match the performance of any competitor". There's always lots of metrics to look at, and in many cases Apple is designing for fundamentally different metrics than AMD/Intel, but I don't quite get the reluctance people have to admit that ARM is going to be better than x86 in some of those metrics, even on iso-node (like A15 vs Zen4). And this is like, the core metric that aarch64 was designed around.
  • userbinator 5y ago
    Comparing decoder width for x86 vs ARM is really apples-to-oranges. One x86 instruction may do the work of several ARM ones. All the OoO stuff happens at the uop level anyway.
    • hajile 5y ago
      This argues even more against x86 as it translates to an internal ISA. In effect, the argument becomes that decode-to-risc-cost + risc-execution-cost is always going to be bigger than risc-execution-cost. And this is before you consider the effects of things like looser memory ordering or more registers reducing unnecessary MOVs.
    • paulmd 5y ago
      That's true if you take the strict textbook definition of "RISC" and "CISC" but everyone has been saying for 10+ years that really isn't how things work anymore. ARM has pulled a lot of the "useful goodies" out of CISC ISAs and CISC ISAs have gone to RISC micro-ops internally on a lot of things. And x86-64 is really not all that dense anyway either. Also, a huge amount of instructions end up being used very little, there are a few "hotspot" instructions that make up a huge percent of actual instructions executed. https://arxiv.org/pdf/1607.02318.pdf https://arxiv.org/pdf/1607.02318.pdf Measured code density on SPEC2006, ARMv8 has geomean 6% more instructions, and geomean 12% higher code size. But Apple designs use 4x the decoders-per-thread in their Performance Cores compared to Intel (8 decoders for 1 thread for Apple, vs 4 decoders for 2 threads for Intel). Apple's designs are targeting much, much higher decode performance even considering the lower density of ARM (4/1.06 = 3.77x as much "normalized decode performance per thread"). Which shouldn't be surprising as their IPC is around 3x of modern x86 processors as well according to Anandtech's work on M1. They aren't magic, the code runs about the same on their processors too, they're just designed for much wider layouts than x86 and using super deep re-ordering to get that performance into a single thread.
  • jabl 5y ago
    > You're saying "nothing wrong with an n^2 algorithm Quadratic scaling is certainly not ideal, but in the grand scheme of things OoO processors have other components that consume more power as well as having quadratic or even worse scaling. For instance, the issue queue, the ROB, multiported register files, bypass networks. Hence, when you go to a wider and deeper OoO design I claim that the relative importance of the decoder will decrease. > If the rest of the core shrinks, the decoder gets relatively bigger, In the previous paragraph you're arguing that as the core gets beefier the decoder will get relatively bigger. Now you're arguing the exact opposite! So which is it? > As far as the instruction cache - those are tricks can be used on ARM architectures too (and I believe Apple does?), they aren't themselves a substitute for a scalable ISA, they're treating the symptom. They may do more on an architecture that is more bottlenecked in that area, but they do give you at least some speedup on everything. Treating the symptoms is really orthogonal to the topic of how much an ISA limits decoding width or reorder depth in itself. I'm quite sure pretty much any processor outside of some really tiny microcontroller will have an instruction cache. But maybe you're talking about micro-op caches. So yes, they are in a way treating the symptom that it can be more efficient to cache decoded instructions instead of decoding them over and over in a loop. But so what, if it works use it! Might as well claim that caching in general is cheating instead of just having faster memory. > looks to me like ARMv8 is on a solid foundation that solves some weaknesses of the x86 design. It's a clean-sheet "how would we do out-of-order/speculation if we could design our instructions over again" and it largely achieves that goal IMO. I fully agree, ARMv8 is certainly pretty much a 'best practice' general purpose ISA. I just don't think it's such a dominating factor. If ARM or RISC-V eventually take over the world I think it'll be more due to different licensing/business models/etc rather than the superiority of the ISA itself. > I don't see it as an inherent law of the universe that "there must exist enough tricks for x86 to match the performance of any competitor". Indeed there is no such inherent law, but so far looking at the history of microelectronics it seems that with a modest transistor budget penalty and some elbow grease you can make almost any ISA fly.