13 ms·

This is my consideration. 1)ARM is good for phones/tablets/portable small devices which runs on battery because it saves much more power. 2)I think that x64 h

This is my consideration. 1)ARM is good for phones/tablets/portable small devices which runs on battery because it saves much more power. 2)I think that x64 hardware of similar specs outperforms arm64 in performance.[Personal observance] 3) I love how I can boot Different linux distros/BSDs/HaikuOS/Windows/other x64-generic-OS.In my arm64 phone,I can't(OS must be especially crafted for that specific processor ,then it must be tweaked carefully for that device in order to boot).Also,there is very much diversity in arm64 space.This implies that some arm64 hardware can't boot/run some OSs which hasn't been crafted for that device. For my use-case,(3) is very important.I am damn sure that,some manufacturers might manufacture hardware that can't boot other OS(say situation where most (arm) laptops can't run linux and only runs windows). I don't want that to happen.Also , booting up OS in arm64 is not standardized(there is lot of diversity in boot process in arm64 unlike x64).Also ,some components might not be upstreamed in Linux kernel(So,I need to patch my kernel everytime/My kernel will never get updated to new major version like many android phones). Speaking of other architectures,I also don't think RISC-V will become major architecture anytime soon/will suffer the same disadvantages of arm64 I mentioned above.Maybe,pp64(openpower) might be good architecture but I haven't got a chance to deal with that hardware.

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.
hrktb 6y ago
On 2), using the iPad Pro puts me in the opposite camp, where sheer performance is better from my perception. The limitations come more from what I can do that how good/fast/responsive it is done. I get there is more to it that just an ARM vs x86 straight comparison, but even my 2019 MBP feels less smooth when it comes to simple and comparable tasks like browsing sites while watching videos.
- andai 6y ago
  These days I will often use my phone instead of my desktop because it's less laggy. Admittedly my computer is a few years old, but so is my phone!
  - wayneftw 6y ago
    What activity could possibly be less laggy on your phone? I can't stand using my iPhone or my iPad for anything other than very basic features since they're so slow and limited compared to how quickly I can get things done on one of my real computers. Selecting text or placing the cursor on a phone is an exercise in frustration. Browsing the web too - I have to contend with every other website treating my phone like a 2nd class citizen and some sites like Reddit or Twitch try so hard to force you to use their app. On Google I have to either use desktop mode and zoom in after each search or I have to put up with shitty AMP results. I basically associate ARM with shitty locked-down operating systems that don't have my best interests in mind.
    - roamerz 6y ago
      You had me with you until the last paragraph. I appreciate my ARM device. In my case an iphone. Out of all if the other ‘brands’ Apple comparatively has my best interests (privacy and security) in mind. With some of the mentioned trade-offs of course.
      - grawprog 6y ago
        Your best interests are not necessarily everyone's best interests, security at the expense of freedom is not mine or many other people's best interest.
g_p 6y ago
Regarding 3, I think a lot of this stems from ARM not using standardised interfaces with discovery of peripherals. Historically, board configuration ended up "compiled into" kernels and bootloaders. Device Tree (DTB) has made this a bit better, as the device tree can sit alongside the kernel or bootloader, holding the board-specific configurations. The real root issue though is that ARM devices are generally built as "finished" products, so don't need to support pluggable hardware, meaning you can make assumptions about what pin on the SoC is used for each purpose, and exactly what it's connected to. This leads to kludges on phone handsets sometimes, where audio jack polarity is incorrect etc, and needs a board-specific driver hack. These hacks were often maintained in a board-specific kernel tree. DTB certainly helps, but ARM devices are still (to some extent) quite hardware-specific. Moving towards UEFI bootloaders on ARM64 looks promising, and there are now "generic" ARM64 bootable images for some Linux distros. Hopefully we'll see more use of a standard UEFI interface on ARM devices, so we can get towards having common bootable OS images, without board specifics needing handled by the OS!
- kevin_thibedeau 6y ago
  The problem is onboard peripherals that share pins. There is no way to represent these simultaneously in a devicetree.
  - colonwqbang 6y ago
    What do you mean? The device tree is just a nested hash table, the interpretation of which is completely up to the device driver(s). If there is a limitation like you say, I guess it is fixable by patching the relevant driver?
- bogomipz 6y ago
  Thanks for the insight. Are there some distros which have better support for ARM as a whole is really more a question of what distro has the best support for my specific ARM device? Also how far along is UEFI bootloaders for ARM64?
- R0b0t1 6y ago
  Device tree is really a step backwards. People hate how complicated plug and play became, but device tree is x86 before hardware discovery became a thing. That's mostly the gist of what you're saying, but I think it needs to change; a lot of embedded platforms are adopting device tree now and it's just making things more difficult.
colonwqbang 6y ago
On (2), what does "similar specs" mean to you? I can think of several interpretations like performance/watt or performance/dollar. It is not my understanding that Intel hardware generally beats ARM in these categories. I suppose that Intel would win in a competition of "maximum single-thread perf regardless of power or cost". But that does not sounds like something that is intended by "simlar specs". On (1), I would point out that saving power is beneficial to everyone and will likely only become more important in the future. (3) is a bummer but is something that we can possibly solve with technologies like the Linux Device Tree. Certainly, it is not impossible to build an open platform on ARM if the manufacturer cooperates. To what extent they will do so, remains to be seen I think.
- hansvm 6y ago
  > On (2), what does "similar specs" mean to you? I can think of several interpretations like performance/watt or performance/dollar. It is not my understanding that Intel hardware generally beats ARM in these categories. Not the person you replied to, but this could have a couple interpretations where Intel wins. Here's one option: If you take two CPUs with similar core counts, clock speed, and transister counts then which one will have higher throughput, lower latency, ... for typical operations? This is open to interpretation of course (e.g. if you didn't need floating point throughput then AMD bulldozer architectures were competitive when released), but it's not unreasonable to evaluate CPUs based on your personal workloads.
- R0b0t1 6y ago
  Just for a relatable example on most ARM processors that would compare to a low-end x86_64 machine, I notice python programs running far slower with similar memory and core count. It might be memory issues, x86 machines have very wide memory busses. But I am still left a little confused, and practically it still has impact.
- varbhat 6y ago
  2) I can see x64 hardware on bit costlier machines. And,i can see arm64 on cheaper machines. On general computing devices, as price increases ,you get to see less arm64 hardwares. I had low cost laptop with AMD processor. It compiled faster and handled load better than Rasp. Pi. of comparable hardware(similar specs not exact specs). Rasp. Pi was ofc cheaper than AMD laptop.(about 0.4x of AMD laptop). I don't think AMD laptop consumed lot of power than arm64 Rasp. Pi. arm64 being lower in cost consuming lower energy ,you can feel that arm64 is better than x64 in perf/dollar or perf/watt but reality is that there is no comparable hardware of both architecture in respective product range and difference is not that apparent when it comes to arm64. Also my AMD laptop compiled,cross compiled,handled large load much better than arm64 hardware of comparable specs. 1) Yes, power saving is desirable feature. I can't see arm64 workstations around. So,if you need performant hardwares,i think that x64/ppc64 becomes inevitable. 3) Definitely a bummer , still unresolved. Let's see how it goes. x64 has benefit in this point.
tyingq 6y ago
"I think that x64 hardware of similar specs outperforms arm64 in performance" Performance per watt is probably going to be the primary driver. "How cheaply can I rent a 'vCPU' drives decisions."
beached_whale 6y ago
regarding 2) I would like to see a non-heavily power managed ARM that also has a bunch of cache like a similar x64 would. 3) this is probably not the CPU, see Rpi4 which runs windows/linux/and several others
ofrzeta 6y ago
about 3) whatever happened to the Server Base Boot Requirements (SBBR) and Server Base System Architecture (SBSA) specs? They were supposed to standardize stuff like that. https://developer.arm.com/architectures/platform-design/server-systems https://developer.arm.com/architectures/platform-design/serv...
- deleted 6y ago
  [deleted]
sjs382 6y ago
> 2)I think that x64 hardware of similar specs outperforms arm64 in performance.[Personal observance] Can you elaborate on this a bit? What devices are you comparing (on both sides of the comparison)?

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.

hrktb 6y ago

On 2), using the iPad Pro puts me in the opposite camp, where sheer performance is better from my perception. The limitations come more from what I can do that how good/fast/responsive it is done. I get there is more to it that just an ARM vs x86 straight comparison, but even my 2019 MBP feels less smooth when it comes to simple and comparable tasks like browsing sites while watching videos.

andai 6y ago
These days I will often use my phone instead of my desktop because it's less laggy. Admittedly my computer is a few years old, but so is my phone!
- wayneftw 6y ago
  What activity could possibly be less laggy on your phone? I can't stand using my iPhone or my iPad for anything other than very basic features since they're so slow and limited compared to how quickly I can get things done on one of my real computers. Selecting text or placing the cursor on a phone is an exercise in frustration. Browsing the web too - I have to contend with every other website treating my phone like a 2nd class citizen and some sites like Reddit or Twitch try so hard to force you to use their app. On Google I have to either use desktop mode and zoom in after each search or I have to put up with shitty AMP results. I basically associate ARM with shitty locked-down operating systems that don't have my best interests in mind.
  - roamerz 6y ago
    You had me with you until the last paragraph. I appreciate my ARM device. In my case an iphone. Out of all if the other ‘brands’ Apple comparatively has my best interests (privacy and security) in mind. With some of the mentioned trade-offs of course.
    - grawprog 6y ago
      Your best interests are not necessarily everyone's best interests, security at the expense of freedom is not mine or many other people's best interest.

g_p 6y ago

Regarding 3, I think a lot of this stems from ARM not using standardised interfaces with discovery of peripherals. Historically, board configuration ended up "compiled into" kernels and bootloaders. Device Tree (DTB) has made this a bit better, as the device tree can sit alongside the kernel or bootloader, holding the board-specific configurations. The real root issue though is that ARM devices are generally built as "finished" products, so don't need to support pluggable hardware, meaning you can make assumptions about what pin on the SoC is used for each purpose, and exactly what it's connected to. This leads to kludges on phone handsets sometimes, where audio jack polarity is incorrect etc, and needs a board-specific driver hack. These hacks were often maintained in a board-specific kernel tree. DTB certainly helps, but ARM devices are still (to some extent) quite hardware-specific. Moving towards UEFI bootloaders on ARM64 looks promising, and there are now "generic" ARM64 bootable images for some Linux distros. Hopefully we'll see more use of a standard UEFI interface on ARM devices, so we can get towards having common bootable OS images, without board specifics needing handled by the OS!

kevin_thibedeau 6y ago
The problem is onboard peripherals that share pins. There is no way to represent these simultaneously in a devicetree.
- colonwqbang 6y ago
  What do you mean? The device tree is just a nested hash table, the interpretation of which is completely up to the device driver(s). If there is a limitation like you say, I guess it is fixable by patching the relevant driver?
bogomipz 6y ago
Thanks for the insight. Are there some distros which have better support for ARM as a whole is really more a question of what distro has the best support for my specific ARM device? Also how far along is UEFI bootloaders for ARM64?
R0b0t1 6y ago
Device tree is really a step backwards. People hate how complicated plug and play became, but device tree is x86 before hardware discovery became a thing. That's mostly the gist of what you're saying, but I think it needs to change; a lot of embedded platforms are adopting device tree now and it's just making things more difficult.

colonwqbang 6y ago

On (2), what does "similar specs" mean to you? I can think of several interpretations like performance/watt or performance/dollar. It is not my understanding that Intel hardware generally beats ARM in these categories. I suppose that Intel would win in a competition of "maximum single-thread perf regardless of power or cost". But that does not sounds like something that is intended by "simlar specs". On (1), I would point out that saving power is beneficial to everyone and will likely only become more important in the future. (3) is a bummer but is something that we can possibly solve with technologies like the Linux Device Tree. Certainly, it is not impossible to build an open platform on ARM if the manufacturer cooperates. To what extent they will do so, remains to be seen I think.

hansvm 6y ago
> On (2), what does "similar specs" mean to you? I can think of several interpretations like performance/watt or performance/dollar. It is not my understanding that Intel hardware generally beats ARM in these categories. Not the person you replied to, but this could have a couple interpretations where Intel wins. Here's one option: If you take two CPUs with similar core counts, clock speed, and transister counts then which one will have higher throughput, lower latency, ... for typical operations? This is open to interpretation of course (e.g. if you didn't need floating point throughput then AMD bulldozer architectures were competitive when released), but it's not unreasonable to evaluate CPUs based on your personal workloads.
R0b0t1 6y ago
Just for a relatable example on most ARM processors that would compare to a low-end x86_64 machine, I notice python programs running far slower with similar memory and core count. It might be memory issues, x86 machines have very wide memory busses. But I am still left a little confused, and practically it still has impact.
varbhat 6y ago
2) I can see x64 hardware on bit costlier machines. And,i can see arm64 on cheaper machines. On general computing devices, as price increases ,you get to see less arm64 hardwares. I had low cost laptop with AMD processor. It compiled faster and handled load better than Rasp. Pi. of comparable hardware(similar specs not exact specs). Rasp. Pi was ofc cheaper than AMD laptop.(about 0.4x of AMD laptop). I don't think AMD laptop consumed lot of power than arm64 Rasp. Pi. arm64 being lower in cost consuming lower energy ,you can feel that arm64 is better than x64 in perf/dollar or perf/watt but reality is that there is no comparable hardware of both architecture in respective product range and difference is not that apparent when it comes to arm64. Also my AMD laptop compiled,cross compiled,handled large load much better than arm64 hardware of comparable specs. 1) Yes, power saving is desirable feature. I can't see arm64 workstations around. So,if you need performant hardwares,i think that x64/ppc64 becomes inevitable. 3) Definitely a bummer , still unresolved. Let's see how it goes. x64 has benefit in this point.

tyingq 6y ago

"I think that x64 hardware of similar specs outperforms arm64 in performance" Performance per watt is probably going to be the primary driver. "How cheaply can I rent a 'vCPU' drives decisions."

beached_whale 6y ago

regarding 2) I would like to see a non-heavily power managed ARM that also has a bunch of cache like a similar x64 would. 3) this is probably not the CPU, see Rpi4 which runs windows/linux/and several others

ofrzeta 6y ago

about 3) whatever happened to the Server Base Boot Requirements (SBBR) and Server Base System Architecture (SBSA) specs? They were supposed to standardize stuff like that. https://developer.arm.com/architectures/platform-design/server-systems https://developer.arm.com/architectures/platform-design/serv...

deleted 6y ago
[deleted]

sjs382 6y ago

> 2)I think that x64 hardware of similar specs outperforms arm64 in performance.[Personal observance] Can you elaborate on this a bit? What devices are you comparing (on both sides of the comparison)?