4 ms·

The thing about x64 is that it's really complex instruction decoding system is unavoidable overhead. Especially since every processor translates the x64 instruc

by rocqua 6y ago

The thing about x64 is that it's really complex instruction decoding system is unavoidable overhead. Especially since every processor translates the x64 instructions into processor-specific micro-instructions. And then those are run by the processor. It seems to me that a simpler instruction set that occurs much less overhead than the above will simply have a higher performance ceiling. The only advantage I see in x64 is that the complex instructions are a form of 'compression' for the micro-instructions. Maaaaybe the resultant bandwidth reduction in reading isntructions is worth the performance overhead of x64 instruction decoding.

throwaway_pdp09 6y ago
IANA hardware/cpu guy but, instructions that get decoded get cached in a parallel-to-data-L1 cache, the L1-instruction cache. > Maaaaybe the resultant bandwidth reduction in reading isntructions is worth the performance overhead of x64 instruction decoding. Access to main mem is slow, much slower than decoding circuitry, so it is very well worth it. From what I've read, the decoding time mattered early on, hence (among other reasons) RISC, but as chips speeded up decoding time became less important, then an overhead as the instructions were large. IIRC, and I can't back this up so take with caution, the alpha chips suffered because of this (but of course you could always take large instructions then decode them smaller and cache those decoded instrs). Just my view. Ask a chip expert for a better opinion.
classichasclass 6y ago
I'm sympathetic to this view and it was probably true in older generations of chips, but it turns out that instruction decode is a very small portion of die size and power usage these days. The L2 probably uses more juice, for example. See Hirki et al.: https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool...
- api 6y ago
  I think most of the power envelope difference these days is process node, with Intel chips usually lagging behind. That being said, I do think that if the same amount of performance engineering were dumped into ARM as has been put into X64 ARM would win. The simpler instruction encoding, less cruft (but not none!), and other modern characteristics would make that optimization go further. My concern as others have mentioned is lack of standardized interfaces and peripheral enumeration, leading to a lack of flexibility and the loss of ability to run alternative OSes and drivers. That can be fixed, but does anyone care enough to fix it?
  - ben-schaaf 6y ago
    > I think most of the power envelope difference these days is process node, with Intel chips usually lagging behind. That hasn't been the case until quite recently. Before TSMC 7nm Intel was still at least on-par with everyone else. I think it boils down to arm chips being designed from the ground up with power usage in mind (with a fair number having slower low-power secondary cores and such), whereas Intel mostly expects your CPU to always be doing something even at idle.
Symmetry 6y ago
Decode complexity is a real cost to x86-64 but it's not a huge one. Well, for medium devices in the Pentium range it can be pretty significant but for modern large cores it'll only end up costing 5% or so of the total power budget on x86. And there are some design effects where ARM cores will tend to make the decode unit big enough that it's never the limiting factor whereas x86 cores tend to balance the size of the decoder against the other stages more. More significant than that, I think, is that modern 64 bit ARM is actually tend to produce denser code than modern 64 bit x86 - which is really weird when you consider that ARM-64 is fixed width and x86-64 is variable width but backwards compatibility can do that. And more important than that, however, is that x86-64 has a very strict memory model and ARM a more relaxed one which can cause problems for programmers who aren't careful but has huge implications for the design of the memory backend.
- monocasa 6y ago
  > More significant than that, I think, is that modern 64 bit ARM is actually tend to produce denser code than modern 64 bit x86 Do you have a citation for that? Everything I've seen says the opposite, including http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document... The strongest wording I've seen is that aarch64 is 'competitive with' x86_64.
  - Symmetry 6y ago
    You know I think you're correct and I was mis-remembering. I think what I might have actually been confused by is instructions per task rather than bytes of instruction per task but given that my memory has already failed me once here who knows.
zozbot234 6y ago
> The only advantage I see in x64 is that the complex instructions are a form of 'compression' for the micro-instructions. Maaaaybe the resultant bandwidth reduction in reading isntructions is worth the performance overhead of x64 instruction decoding. It would be sensible to expect that, but as it turns out the RISC-V C ("compressed instructions") extension is quite competitive with x86/amd64. Of course, ARM64 doesn't seem to have an equivalent to RISC-V C, even the old Thumb mode is gone.
duskwuff 6y ago
> The only advantage I see in x64 is that the complex instructions are a form of 'compression' for the micro-instructions. It's not a very good one. The x86_64 ISA encoding evolved out of the original 8086 instruction encoding, and has inherited a lot of inefficiencies from there -- a lot of one-byte opcodes are wasted on rarely used bytewise instructions (like XLAT), privileged instructions (like the IN/OUT family), or on opcodes that are simply invalid in 64-bit mode. Most instructions in real x86_64 code are two to four bytes long, not even counting immediate values. A focused attempt could probably do much better.

by rocqua 6y ago

throwaway_pdp09 6y ago

IANA hardware/cpu guy but, instructions that get decoded get cached in a parallel-to-data-L1 cache, the L1-instruction cache. > Maaaaybe the resultant bandwidth reduction in reading isntructions is worth the performance overhead of x64 instruction decoding. Access to main mem is slow, much slower than decoding circuitry, so it is very well worth it. From what I've read, the decoding time mattered early on, hence (among other reasons) RISC, but as chips speeded up decoding time became less important, then an overhead as the instructions were large. IIRC, and I can't back this up so take with caution, the alpha chips suffered because of this (but of course you could always take large instructions then decode them smaller and cache those decoded instrs). Just my view. Ask a chip expert for a better opinion.

classichasclass 6y ago

I'm sympathetic to this view and it was probably true in older generations of chips, but it turns out that instruction decode is a very small portion of die size and power usage these days. The L2 probably uses more juice, for example. See Hirki et al.: https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool...

api 6y ago
I think most of the power envelope difference these days is process node, with Intel chips usually lagging behind. That being said, I do think that if the same amount of performance engineering were dumped into ARM as has been put into X64 ARM would win. The simpler instruction encoding, less cruft (but not none!), and other modern characteristics would make that optimization go further. My concern as others have mentioned is lack of standardized interfaces and peripheral enumeration, leading to a lack of flexibility and the loss of ability to run alternative OSes and drivers. That can be fixed, but does anyone care enough to fix it?
- ben-schaaf 6y ago
  > I think most of the power envelope difference these days is process node, with Intel chips usually lagging behind. That hasn't been the case until quite recently. Before TSMC 7nm Intel was still at least on-par with everyone else. I think it boils down to arm chips being designed from the ground up with power usage in mind (with a fair number having slower low-power secondary cores and such), whereas Intel mostly expects your CPU to always be doing something even at idle.

Symmetry 6y ago

Decode complexity is a real cost to x86-64 but it's not a huge one. Well, for medium devices in the Pentium range it can be pretty significant but for modern large cores it'll only end up costing 5% or so of the total power budget on x86. And there are some design effects where ARM cores will tend to make the decode unit big enough that it's never the limiting factor whereas x86 cores tend to balance the size of the decoder against the other stages more. More significant than that, I think, is that modern 64 bit ARM is actually tend to produce denser code than modern 64 bit x86 - which is really weird when you consider that ARM-64 is fixed width and x86-64 is variable width but backwards compatibility can do that. And more important than that, however, is that x86-64 has a very strict memory model and ARM a more relaxed one which can cause problems for programmers who aren't careful but has huge implications for the design of the memory backend.

monocasa 6y ago
> More significant than that, I think, is that modern 64 bit ARM is actually tend to produce denser code than modern 64 bit x86 Do you have a citation for that? Everything I've seen says the opposite, including http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document... The strongest wording I've seen is that aarch64 is 'competitive with' x86_64.
- Symmetry 6y ago
  You know I think you're correct and I was mis-remembering. I think what I might have actually been confused by is instructions per task rather than bytes of instruction per task but given that my memory has already failed me once here who knows.

zozbot234 6y ago

> The only advantage I see in x64 is that the complex instructions are a form of 'compression' for the micro-instructions. Maaaaybe the resultant bandwidth reduction in reading isntructions is worth the performance overhead of x64 instruction decoding. It would be sensible to expect that, but as it turns out the RISC-V C ("compressed instructions") extension is quite competitive with x86/amd64. Of course, ARM64 doesn't seem to have an equivalent to RISC-V C, even the old Thumb mode is gone.

duskwuff 6y ago

> The only advantage I see in x64 is that the complex instructions are a form of 'compression' for the micro-instructions. It's not a very good one. The x86_64 ISA encoding evolved out of the original 8086 instruction encoding, and has inherited a lot of inefficiencies from there -- a lot of one-byte opcodes are wasted on rarely used bytewise instructions (like XLAT), privileged instructions (like the IN/OUT family), or on opcodes that are simply invalid in 64-bit mode. Most instructions in real x86_64 code are two to four bytes long, not even counting immediate values. A focused attempt could probably do much better.