4 ms·

> Some huge portion of the x86 power budget is just the instruction decoder. This is a widely held meme, but the internet at large doesn't have any evidence t

> Some huge portion of the x86 power budget is just the instruction decoder. This is a widely held meme, but the internet at large doesn't have any evidence to back it up. A couple of publicly visible engineers that do have experience are on record as saying that cell-phone-class competitive x86 was absolutely possible. Intel and AMD chose not to pursue those markets. The expensive parts of a high-end CPU aren't normally in the instruction decode part. They are in the branch prediction, branch mispredict recovery, forwarding networks, memory re-ordering, and so on. Anything short of a dataflow ISA has little impact on those structures.

MrBuddyCasino 6y ago
> A couple of publicly visible engineers that do have experience are on record as saying that cell-phone-class competitive x86 was absolutely possible. Weren't there Windows Phone devices with x86 SoC, but they weren't competitive?
- toast0 6y ago
  Public Windows Phone 7, 8, and Windows Mobile 10 devices were all arm. Intel cancelled further development on Atom for phones at roughly the same time Microsoft announced Windows Mobile 10's desktop convergence feature (plug phone into monitor and get a desktop-like experience, I think there was a wireless option as well). It's pretty simple to speculate this would have been way more nifty on an x86 chip, because Windows Mobile 10 was more or less Windows 10, so you would have a bigger software library, instead of only UWP applications. Commercially made x86 Android phones exist, the most popular to my knowledge were some of the Asus ZenPhone models.
- ThrowawayR2 6y ago
  There never were any. Intel cancelled their Broxton phone SoC in 2016: https://www.anandtech.com/show/10288/intel-broxton-sofia-smartphone-socs-cancelled https://www.anandtech.com/show/10288/intel-broxton-sofia-sma... (A major mistake on their part IMO.) There was some speculation back then that Microsoft might have been interested in x86 phones but no proof ever emerged.
- hajile 6y ago
  It existed, but why bother? When Atom was released in 2008, the A9 had already been announced (a year before). A9 was around 10-15% faster per clock and were often multicore meaning a 1.5GHz chip was faster in all metrics over the 1.6GHz Atom. A few articles came out June/July of this year with Analysts saying that Intel had spent over 10 Billion dollars trying to break into the mobile market with no success. ARM's current R&D budget (according to Nvidia a month or so ago) is 0.5B. If they spent that much every year since 2000, they would barely match Intel, but their entire market cap in stayed under 4B all the way until 2009. Remember, that R&D includes their high-end ARM cores, but also GPU, midrange designs, various microcontroller designs, a realtime OS, ARM tooling, NPUs, various kernel support, etc If that much money can't fix up x86 to keep up with a budget a fraction of the size, I take that as proof that the ISA really does matter.
arcticbull 6y ago
By large I mean up to 10%, and I have a study for you. [1] [1] https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool...
- brandmeyer 6y ago
  I skimmed the paper. They reported that the difference in total power spent in two(!) microbenchmarks when switching between L1I and the decode cache is 10% for one, and 3% for the other. The attribution of power was done entirely using a linear regression model on some core perf counters, and the core's own internal estimate for power consumption over the whole package. I don't think you can generalize from that result to much of anything.
  - reitzensteinm 6y ago
    I don't have a source, but back when ARM Zen was going to be a thing (hopefully it still will), AMD was claiming a 10% uplift in performance over x64. That struck me as one of the few apples to apples comparisons ever of the instruction sets at the high end, from a party not really incentivized to bend the truth one way or another. But it could have easily come from something like the relaxed memory model, or they could have just been overly optimistic. The chip was cut after all.
  - hajile 6y ago
    You're running into the same problem, just from a different angle. With the exception of Atom, all recent Intel designs have been a RISC core with a CISC decoder slapped on top. Everything else being equal, the simpler decoder will create a smaller chip. Because the decoder is always running all-out, the simpler decoder will also use less power. x86 instructions are multi-length from 1 to 15 bytes. The cost to slice that up is always going to be bigger than fixed-length instructions. RISC-V has variable length in theory, but in practice, compact instructions extend into 32-bit instructions with some bits added which is important for decode cache while longer instructions are ignored. Because there's a maximum tolerable decode latency of a very few cycles and latency increases with cache size, decode cache size has a definite cap. x86 has a couple orders of magnitude more potential instructions than RISC-V. More instructions translates into a lower hit rate for the same size cache barring any heuristics (more on that below). Matching variable-length arrays to an unknown set of arrays in cache is inherently a hard problem. Every solution has tradeoffs and the resulting heuristics are bad for computing (see below). In contrast, searching for a match on a fixed 32-bit array has much more simple general solutions that don't require tradeoffs. C and CPU designs feed off each other. Let's say there are instructions X and Y which can do equivalent things. x86 engineers played around with both and got a lucky insight into how to make X a bit faster. Compiler writers jump on it and start using the faster solution. x86 engineers now all but stop looking to improve Y and spend their time tinkering with X instead. Compilers now focus even more heavily around not just X, but any instructions more closely associated with X. In that entire (true) story, nobody gave a second thought to whether the final result of Y would have been faster overall if not for the lucky break with X. If x86 developers were actually free to choose whichever instructions they wanted, x86 decode would be much, much slower than it appears to be. This self limitation argues that perhaps a more RISC-like ISA is inevitable. A new ISA where everything is used would definitely have complexity, transistor, and power disadvantages vs a new ISA that didn't make that mistake.
klelatti 6y ago
I'm sure that you're right that the instruction decoder power budget isn't a huge issue. Don't think its strictly accurate to say that Intel 'chose not to pursue' the mobile SoC market - IIRC they tried, made little progress and gave up having spent a lot of money in the process.

MrBuddyCasino 6y ago

> A couple of publicly visible engineers that do have experience are on record as saying that cell-phone-class competitive x86 was absolutely possible. Weren't there Windows Phone devices with x86 SoC, but they weren't competitive?

toast0 6y ago
Public Windows Phone 7, 8, and Windows Mobile 10 devices were all arm. Intel cancelled further development on Atom for phones at roughly the same time Microsoft announced Windows Mobile 10's desktop convergence feature (plug phone into monitor and get a desktop-like experience, I think there was a wireless option as well). It's pretty simple to speculate this would have been way more nifty on an x86 chip, because Windows Mobile 10 was more or less Windows 10, so you would have a bigger software library, instead of only UWP applications. Commercially made x86 Android phones exist, the most popular to my knowledge were some of the Asus ZenPhone models.
ThrowawayR2 6y ago
There never were any. Intel cancelled their Broxton phone SoC in 2016: https://www.anandtech.com/show/10288/intel-broxton-sofia-smartphone-socs-cancelled https://www.anandtech.com/show/10288/intel-broxton-sofia-sma... (A major mistake on their part IMO.) There was some speculation back then that Microsoft might have been interested in x86 phones but no proof ever emerged.
hajile 6y ago
It existed, but why bother? When Atom was released in 2008, the A9 had already been announced (a year before). A9 was around 10-15% faster per clock and were often multicore meaning a 1.5GHz chip was faster in all metrics over the 1.6GHz Atom. A few articles came out June/July of this year with Analysts saying that Intel had spent over 10 Billion dollars trying to break into the mobile market with no success. ARM's current R&D budget (according to Nvidia a month or so ago) is 0.5B. If they spent that much every year since 2000, they would barely match Intel, but their entire market cap in stayed under 4B all the way until 2009. Remember, that R&D includes their high-end ARM cores, but also GPU, midrange designs, various microcontroller designs, a realtime OS, ARM tooling, NPUs, various kernel support, etc If that much money can't fix up x86 to keep up with a budget a fraction of the size, I take that as proof that the ISA really does matter.

arcticbull 6y ago

By large I mean up to 10%, and I have a study for you. [1] [1] https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool...

brandmeyer 6y ago
I skimmed the paper. They reported that the difference in total power spent in two(!) microbenchmarks when switching between L1I and the decode cache is 10% for one, and 3% for the other. The attribution of power was done entirely using a linear regression model on some core perf counters, and the core's own internal estimate for power consumption over the whole package. I don't think you can generalize from that result to much of anything.
- reitzensteinm 6y ago
  I don't have a source, but back when ARM Zen was going to be a thing (hopefully it still will), AMD was claiming a 10% uplift in performance over x64. That struck me as one of the few apples to apples comparisons ever of the instruction sets at the high end, from a party not really incentivized to bend the truth one way or another. But it could have easily come from something like the relaxed memory model, or they could have just been overly optimistic. The chip was cut after all.
- hajile 6y ago
  You're running into the same problem, just from a different angle. With the exception of Atom, all recent Intel designs have been a RISC core with a CISC decoder slapped on top. Everything else being equal, the simpler decoder will create a smaller chip. Because the decoder is always running all-out, the simpler decoder will also use less power. x86 instructions are multi-length from 1 to 15 bytes. The cost to slice that up is always going to be bigger than fixed-length instructions. RISC-V has variable length in theory, but in practice, compact instructions extend into 32-bit instructions with some bits added which is important for decode cache while longer instructions are ignored. Because there's a maximum tolerable decode latency of a very few cycles and latency increases with cache size, decode cache size has a definite cap. x86 has a couple orders of magnitude more potential instructions than RISC-V. More instructions translates into a lower hit rate for the same size cache barring any heuristics (more on that below). Matching variable-length arrays to an unknown set of arrays in cache is inherently a hard problem. Every solution has tradeoffs and the resulting heuristics are bad for computing (see below). In contrast, searching for a match on a fixed 32-bit array has much more simple general solutions that don't require tradeoffs. C and CPU designs feed off each other. Let's say there are instructions X and Y which can do equivalent things. x86 engineers played around with both and got a lucky insight into how to make X a bit faster. Compiler writers jump on it and start using the faster solution. x86 engineers now all but stop looking to improve Y and spend their time tinkering with X instead. Compilers now focus even more heavily around not just X, but any instructions more closely associated with X. In that entire (true) story, nobody gave a second thought to whether the final result of Y would have been faster overall if not for the lucky break with X. If x86 developers were actually free to choose whichever instructions they wanted, x86 decode would be much, much slower than it appears to be. This self limitation argues that perhaps a more RISC-like ISA is inevitable. A new ISA where everything is used would definitely have complexity, transistor, and power disadvantages vs a new ISA that didn't make that mistake.

klelatti 6y ago

I'm sure that you're right that the instruction decoder power budget isn't a huge issue. Don't think its strictly accurate to say that Intel 'chose not to pursue' the mobile SoC market - IIRC they tried, made little progress and gave up having spent a lot of money in the process.