11 ms·

(both of these are genuine questions, not rhetorical ones) 1. If x64 wasn't already dominant and had the same market share as ARM, would you choose x64? Why?

(both of these are genuine questions, not rhetorical ones) 1. If x64 wasn't already dominant and had the same market share as ARM, would you choose x64? Why? 2. With x64's current dominance, would you buy a ARM system as your primary one, knowing that you'll have significant difficulties developing for the majority of current market share?

hidiegomariani 6y ago
noob here my thought is 1. arm is more power efficient than x64? 2. emulation + shift to remote development environments?
- albntomat0 6y ago
  Is the emulation environment really there? Maybe the nodejs (and everything not low level) can seamlessly develop on arm and ship on x64?
  - remexre 6y ago
    I spent a week recently working from a Pinebook Pro after spilling water on my primary laptop; my workflow was already fairly SSH-centric, but I had fairly few problems with software compatibility that weren't fixed by binfmt_misc + qemu. (That week was spent mostly developing in OCaml and Lisp; I suspect if I were doing C++ or Haskell, I would've had a harder time.)
- tylerhou 6y ago
  One theory behind ARM's power efficiency is that you don't have to waste power and area converting x86 into uops. But this is a constant overhead. It matters a lot on 5/10W TDP mobile processors, but matters much less on 45W TDP laptop processors.
  - martin8412 6y ago
    Hasn't it been a while since 45W TDP processors were common in laptops? My X395 uses a 15W TDP processor
    - neogodless 6y ago
      No. They are different use cases. Personally I prefer the 45W chips with higher base clocks at the expense of battery life. 15W is unsuitable for some workloads, though the latest 15W "U" chips from AMD are making some waves there.
    - tylerhou 6y ago
      The i9-9980H(K) found in high-end laptops has a 45W TDP. Granted, this is the most power hungry laptop processor you can find.
cglong 6y ago
Someone described ARM Macs as targeting the modern developer, i.e. one targeting mobile first. I wouldn't want a Mac incapable of running Windows, but I don't think I fit this demographic.
- snazz 6y ago
  Windows itself runs on ARM64 just fine. The third party software usually still requires Microsoft’s emulation layer. I’m not sure that Apple would still maintain Boot Camp, however. I doubt that that matters as much as it used to.
  - cbhl 6y ago
    To me, it's funny how the newer legacy software that's 64-bit only is going to be the problem in an ARM64 world -- the 32-bit x86 binaries will still be fine.
    - Tagbert 6y ago
      That might be a problem in the Windows world but it is unlikely to be a problem for Mac OS. This is likely why Apple finally shut down the 32-bit apps last year. Almost any app built using the Apple 64-bit libraries (both Objective-C and Swift) should be relatively easy to recompile with an ARM64 target.
    - mappu 6y ago
      My impression is that Microsoft are taking a very conservative interpretation of the x86 ISA patents (compared to e.g. qemu-user which has made this available for years now). Patents have a 20 year lifespan, most of the x86_32 ones have expired, but x86_64 is just barely still covered (the first publication was in 2000, and first commercial product was on AMD Opteron/Athlon64 in 2003). So it's probably just a matter of time before the userland emulation stuff is further extended, although we won't get anything newer than SSE2 for the same reason.
tylerhou 6y ago
> knowing that you'll have significant difficulties developing for the majority of current market share? I think this is a very small issue. The reason why it's hard to develop for ARM today is that reasonably powerful (read: non-phone) ARM processors are not very common. The barrier for developing on ARM is that you have to explicitly purchase another ~$500 laptop in order to test on ARM. Also, libraries generally support x86 but not necessarily ARM. With small desktop market share, the expense is often not worth it. On the other hand, x86 processors are ubiquitous, and if you're a developer, you can almost certainly find a old laptop or desktop with an x86 processor laying around to test your software on (especially if you're in the demographic to buy relatively expensive MacBooks). Also, since most people use x86, it makes sense to invest in that market. TL;DR: ARM -> x86 barrier to entry is much lower because x86 processors are so common, x86 opportunity is much more lucrative, and most libraries already support x86.
- armitron 6y ago
  There is a plethora of powerful ARM processors for dirt cheap prices. The market is flooded with ~50$ 64bit multicore ARM boards that run Linux. In fact, there are no x86 equivalents, so you're basically describing the opposite of what's actually the case.
  - icedchai 6y ago
    Raspberry Pi's? Pine64's? I have many of these devices. These are fun to play around with, but are no replacement for a modern x86-64 system.
    - armitron 6y ago
      A replacement for modern x86-64 system is definitely not what the comment I replied to described, even though a lot of these ARM boards certainly apply, depending on subset of tasks needed. Here is one example of what you get for 50 dollars: https://www.hardkernel.com/shop/odroid-c4/ https://www.hardkernel.com/shop/odroid-c4/ This is a quadcore 2GHz 64bit board that can run Android / Ubuntu 20 / Wayland / WebGL / Linux Kernel 5.4 / Vulkan.
tylerhou 6y ago
> If x64 wasn't already dominant and had the same market share as ARM, would you choose x64? Why? I would pick the one which performed the best on my workload. Assuming everything was equal; performance, performance per watt, software support, market share, price to performance: I would pick ARM because I think the competitive landscape is more diverse. x86 is effectively an AMD-Intel duopoly, especially with the cross-licensing agreements. It's a lot easier to start working with ARM IP, which means there should be more competitors, which should translate to better future performance improvements. Even today, we see many more companies competing in this space (Ampere, Marvell, Qualcomm, Apple to a degree), not to mention startups looking to develop their own ARM chips. [1] https://techcrunch.com/2020/04/29/arm-is-offering-early-stage-startups-free-access-to-its-chip-designs/ https://techcrunch.com/2020/04/29/arm-is-offering-early-stag...
scarface74 6y ago
Seeing that most popular languages - Java, C#, Python, Javascript, etc. - run on top of VM and you can develop on one architecture and deploy to another, why does it matter? I develop on a Windows laptop and deploy to Linux all of the time. I have some Python programs that have native dependencies. I still develop on Windows, push and the CI/CD pipeline runs on Linux and packages a Windows build. But even with my first job out of college back in the 90s, I was writing C code that I developed on Windows and was cross compiled for DEC VAX and Stratus VOS mainframes.
- scarface74 6y ago
  I still develop on Windows, push and the CI/CD pipeline runs on Linux and packages a Windows build. Should be “packages a Linux build” “ I was writing C code that I developed on Windows and was cross compiled for DEC VAX and Stratus VOS mainframes.” Of course cross compiles is not the correct terminology. We built the same code on the target machines.
- pjmlp 6y ago
  Even with languages like C, targeting bytecode as distribution format is also an option. Mainframes do it, as means to integrate C and C++ into their language environments. Back in the early mobile OS wars, there was a company selling J2ME like stack, but using C and C++ instead. Then there is the LLVM bitcode used by Apple on iOS and watchOS (which happens to be more platform neutral than regular LLVM bitcode). Oh and WebAssembly and MSIL as well.
  - scarface74 6y ago
    LLVM won’t allow that type of portability. That was a myth that was dispelled by none other than Chris Lattner during an interview on ATP. The transcript of the interview is now returning a 404 though. https://atp.fm/205 https://atp.fm/205
    - pjmlp 6y ago
      LLVM open source version, yes you are correct. LLVM proprietary Apple own internal fork, as used in iOS and watchOS, is another matter. As a matter of fact, there is a WWDC talk about how it allowed the seamless migration of 32 to 64 on watchOS.
monocasa 6y ago
I've heard from a fairly drunk Intel chip designer that CISC continues to make sense in gate counts where full OoO cores make sense. 1) You're almost certainly decoding into u-ops even if you chose RISC because you'll have uarch features like a seperate pipe line for the AGU and the load store queues, atomics that have to wait to go out all the way to L2 for fairly arbitrary lengths of time, etc. You can see this in cores as simple as BOOM, and it's opinion of the RISC-V community that macro op fusion of prescribed clauses is the way to go. 2) These decoders are a drop in the bucket when compared to OoO circuitry and power budget. 3) The complex addressing modes and memory RMW operands are effectively a way to address physical registers while consuming no architectural registers, and very few bits of I$. Yes, x86 is ancient and isn't as optimal as it could be from a huffman encoding perspective (hlt is a single byte opcode!), but it's pretty damn good overall. Better than AArch64 at code density and therefore I$ pressure. As an aside, I'm sorta curious what a CISC-V would look like, and if it would set a new bar.
- remexre 6y ago
  > isn't as optimal as it could be from a huffman encoding perspective I've been toying with the idea of literally having decoding as decompression, where there's a special instruction to change the dictionary. I guess this'd be tantamount to implementing the decoder as an FPGA, but I'm hoping there's some reasonable version where a fairly non-dense "base encoding" becomes a pretty optimal bit stream.
  - monocasa 6y ago
    I've actually played with that idea as well in the past, as a mechanism for emulating other architectures. Who wouldn't love a RISCV that you can turn into a passable x86 or M68K or whatever? In the past too, there were user programmable uCode machines intended to be a generic platform for pretty arbitrary ISAs, so it's not an entirely crazy idea. I eventually came to the conclusion that programmable fabrics in the critical path like instruction decoders on modern processors didn't make sense from a timing perspective, and a classic RISC (or VLIW like Transmeta/Denver) + JIT continued to make more sense. In hindsight I believe you can see this in x86 cores where the microcode ROM is pretty much only executed in already slow paths, and the patch RAM is even more anemic. I'd imagine you'd hit the same issues. That being said, my experiments were hardly conclusive and I'd absolutely love to be proven wrong.
blinkingled 6y ago
I can buy AMD or Intel CPUs, AMD/Intel/NVidia GPUs, a vast array of motherboards and cards, storage and networking pretty much off the shelf, throw Windows or Linux standard builds on it and expect it to work great and perform great. Try doing that with ARM and tell me under what limited circumstances would you buy ARM laptop/desktop/workstation. CPUs are at a stage where AMD and Intel are doing great in non battery constrained setups and with battery constraints you will only get better battery life if you don't make the CPUs sweat. In server/workstation design I would expect AMD and Intel to beat the crap out of ARM anything just because how much optimized they are in that space owing to massive use. So except for frothing at mouth idiots that keep droning about this there isn't much value for the normal customer in buying ARM anything and lose on all fronts - software availability, build flexibility, compatible hardware availability and even performance for many cases. (Spare me teh Geekbench please.) It does make sense for Apple to market their own CPUs to people who are into that type of thing - it's more control, more money and least dependence for Apple - all round win for them if they can pull it off. But it's not going to be easy unless they have something that is hugely better and overcomes at least some of the disadvantages.
- weare138 6y ago
  >I can buy AMD or Intel CPUs, AMD/Intel/NVidia GPUs, a vast array of motherboards and cards, storage and networking pretty much off the shelf, throw Windows or Linux standard builds on it and expect it to work great and perform great. I think this might be one of the motivations for Apple to switch to it's own CPUs instead of just switching to a different x86-64 CPU like AMD's Ryzen. Apple would be able to lock MacOS to the hardware like iOS and the iPhone.
  - blinkingled 6y ago
    Absolutely it is but it's not just to shut down the few hackintosh users although that'd be an welcome consequence. It's only because they still have not figured out how the locked down macOS will work that they have not announced anything so far. Download apps only from Mac App Store, make it easy for people 100% in Apple ecosystem to do what they need to do (XCode, browsing, store apps, multi tasking) and they're good to go. They already charge premium for the hardware - not having to pay Intel will fatten the margins, with app store revenue and maybe banning 3rd party browsing engines they can get exactly what they have always wanted and so long as they provide people with some macOS features - terminal access (even if controlled) and multitasking etc. - people in the Apple ecosystem aren't going to care. Of course it maybe gradual and it maybe not so restrictive - they may allow 3rd party app installations and make it harder like they have already done in a way.
ksec 6y ago
The question isn't really x86 ( inclusive of every instruction currently on modern x86 ) vs ARM. It is simply the business model changes. The older I get the more I am convinced it isn't the technical that changes or determines the outcome, it is the value proposition. Not to mention no one "choose" x86. They chose Intel, or Intel CPU that still currently offer top performance under 10 - 16 Core.

hidiegomariani 6y ago

noob here my thought is 1. arm is more power efficient than x64? 2. emulation + shift to remote development environments?

albntomat0 6y ago
Is the emulation environment really there? Maybe the nodejs (and everything not low level) can seamlessly develop on arm and ship on x64?
- remexre 6y ago
  I spent a week recently working from a Pinebook Pro after spilling water on my primary laptop; my workflow was already fairly SSH-centric, but I had fairly few problems with software compatibility that weren't fixed by binfmt_misc + qemu. (That week was spent mostly developing in OCaml and Lisp; I suspect if I were doing C++ or Haskell, I would've had a harder time.)
tylerhou 6y ago
One theory behind ARM's power efficiency is that you don't have to waste power and area converting x86 into uops. But this is a constant overhead. It matters a lot on 5/10W TDP mobile processors, but matters much less on 45W TDP laptop processors.
- martin8412 6y ago
  Hasn't it been a while since 45W TDP processors were common in laptops? My X395 uses a 15W TDP processor
  - neogodless 6y ago
    No. They are different use cases. Personally I prefer the 45W chips with higher base clocks at the expense of battery life. 15W is unsuitable for some workloads, though the latest 15W "U" chips from AMD are making some waves there.
  - tylerhou 6y ago
    The i9-9980H(K) found in high-end laptops has a 45W TDP. Granted, this is the most power hungry laptop processor you can find.

cglong 6y ago

Someone described ARM Macs as targeting the modern developer, i.e. one targeting mobile first. I wouldn't want a Mac incapable of running Windows, but I don't think I fit this demographic.

snazz 6y ago
Windows itself runs on ARM64 just fine. The third party software usually still requires Microsoft’s emulation layer. I’m not sure that Apple would still maintain Boot Camp, however. I doubt that that matters as much as it used to.
- cbhl 6y ago
  To me, it's funny how the newer legacy software that's 64-bit only is going to be the problem in an ARM64 world -- the 32-bit x86 binaries will still be fine.
  - Tagbert 6y ago
    That might be a problem in the Windows world but it is unlikely to be a problem for Mac OS. This is likely why Apple finally shut down the 32-bit apps last year. Almost any app built using the Apple 64-bit libraries (both Objective-C and Swift) should be relatively easy to recompile with an ARM64 target.
  - mappu 6y ago
    My impression is that Microsoft are taking a very conservative interpretation of the x86 ISA patents (compared to e.g. qemu-user which has made this available for years now). Patents have a 20 year lifespan, most of the x86_32 ones have expired, but x86_64 is just barely still covered (the first publication was in 2000, and first commercial product was on AMD Opteron/Athlon64 in 2003). So it's probably just a matter of time before the userland emulation stuff is further extended, although we won't get anything newer than SSE2 for the same reason.

tylerhou 6y ago

> knowing that you'll have significant difficulties developing for the majority of current market share? I think this is a very small issue. The reason why it's hard to develop for ARM today is that reasonably powerful (read: non-phone) ARM processors are not very common. The barrier for developing on ARM is that you have to explicitly purchase another ~$500 laptop in order to test on ARM. Also, libraries generally support x86 but not necessarily ARM. With small desktop market share, the expense is often not worth it. On the other hand, x86 processors are ubiquitous, and if you're a developer, you can almost certainly find a old laptop or desktop with an x86 processor laying around to test your software on (especially if you're in the demographic to buy relatively expensive MacBooks). Also, since most people use x86, it makes sense to invest in that market. TL;DR: ARM -> x86 barrier to entry is much lower because x86 processors are so common, x86 opportunity is much more lucrative, and most libraries already support x86.

armitron 6y ago
There is a plethora of powerful ARM processors for dirt cheap prices. The market is flooded with ~50$ 64bit multicore ARM boards that run Linux. In fact, there are no x86 equivalents, so you're basically describing the opposite of what's actually the case.
- icedchai 6y ago
  Raspberry Pi's? Pine64's? I have many of these devices. These are fun to play around with, but are no replacement for a modern x86-64 system.
  - armitron 6y ago
    A replacement for modern x86-64 system is definitely not what the comment I replied to described, even though a lot of these ARM boards certainly apply, depending on subset of tasks needed. Here is one example of what you get for 50 dollars: https://www.hardkernel.com/shop/odroid-c4/ https://www.hardkernel.com/shop/odroid-c4/ This is a quadcore 2GHz 64bit board that can run Android / Ubuntu 20 / Wayland / WebGL / Linux Kernel 5.4 / Vulkan.

tylerhou 6y ago

> If x64 wasn't already dominant and had the same market share as ARM, would you choose x64? Why? I would pick the one which performed the best on my workload. Assuming everything was equal; performance, performance per watt, software support, market share, price to performance: I would pick ARM because I think the competitive landscape is more diverse. x86 is effectively an AMD-Intel duopoly, especially with the cross-licensing agreements. It's a lot easier to start working with ARM IP, which means there should be more competitors, which should translate to better future performance improvements. Even today, we see many more companies competing in this space (Ampere, Marvell, Qualcomm, Apple to a degree), not to mention startups looking to develop their own ARM chips. [1] https://techcrunch.com/2020/04/29/arm-is-offering-early-stage-startups-free-access-to-its-chip-designs/ https://techcrunch.com/2020/04/29/arm-is-offering-early-stag...

scarface74 6y ago

Seeing that most popular languages - Java, C#, Python, Javascript, etc. - run on top of VM and you can develop on one architecture and deploy to another, why does it matter? I develop on a Windows laptop and deploy to Linux all of the time. I have some Python programs that have native dependencies. I still develop on Windows, push and the CI/CD pipeline runs on Linux and packages a Windows build. But even with my first job out of college back in the 90s, I was writing C code that I developed on Windows and was cross compiled for DEC VAX and Stratus VOS mainframes.

scarface74 6y ago
I still develop on Windows, push and the CI/CD pipeline runs on Linux and packages a Windows build. Should be “packages a Linux build” “ I was writing C code that I developed on Windows and was cross compiled for DEC VAX and Stratus VOS mainframes.” Of course cross compiles is not the correct terminology. We built the same code on the target machines.
pjmlp 6y ago
Even with languages like C, targeting bytecode as distribution format is also an option. Mainframes do it, as means to integrate C and C++ into their language environments. Back in the early mobile OS wars, there was a company selling J2ME like stack, but using C and C++ instead. Then there is the LLVM bitcode used by Apple on iOS and watchOS (which happens to be more platform neutral than regular LLVM bitcode). Oh and WebAssembly and MSIL as well.
- scarface74 6y ago
  LLVM won’t allow that type of portability. That was a myth that was dispelled by none other than Chris Lattner during an interview on ATP. The transcript of the interview is now returning a 404 though. https://atp.fm/205 https://atp.fm/205
  - pjmlp 6y ago
    LLVM open source version, yes you are correct. LLVM proprietary Apple own internal fork, as used in iOS and watchOS, is another matter. As a matter of fact, there is a WWDC talk about how it allowed the seamless migration of 32 to 64 on watchOS.

monocasa 6y ago

I've heard from a fairly drunk Intel chip designer that CISC continues to make sense in gate counts where full OoO cores make sense. 1) You're almost certainly decoding into u-ops even if you chose RISC because you'll have uarch features like a seperate pipe line for the AGU and the load store queues, atomics that have to wait to go out all the way to L2 for fairly arbitrary lengths of time, etc. You can see this in cores as simple as BOOM, and it's opinion of the RISC-V community that macro op fusion of prescribed clauses is the way to go. 2) These decoders are a drop in the bucket when compared to OoO circuitry and power budget. 3) The complex addressing modes and memory RMW operands are effectively a way to address physical registers while consuming no architectural registers, and very few bits of I$. Yes, x86 is ancient and isn't as optimal as it could be from a huffman encoding perspective (hlt is a single byte opcode!), but it's pretty damn good overall. Better than AArch64 at code density and therefore I$ pressure. As an aside, I'm sorta curious what a CISC-V would look like, and if it would set a new bar.

remexre 6y ago
> isn't as optimal as it could be from a huffman encoding perspective I've been toying with the idea of literally having decoding as decompression, where there's a special instruction to change the dictionary. I guess this'd be tantamount to implementing the decoder as an FPGA, but I'm hoping there's some reasonable version where a fairly non-dense "base encoding" becomes a pretty optimal bit stream.
- monocasa 6y ago
  I've actually played with that idea as well in the past, as a mechanism for emulating other architectures. Who wouldn't love a RISCV that you can turn into a passable x86 or M68K or whatever? In the past too, there were user programmable uCode machines intended to be a generic platform for pretty arbitrary ISAs, so it's not an entirely crazy idea. I eventually came to the conclusion that programmable fabrics in the critical path like instruction decoders on modern processors didn't make sense from a timing perspective, and a classic RISC (or VLIW like Transmeta/Denver) + JIT continued to make more sense. In hindsight I believe you can see this in x86 cores where the microcode ROM is pretty much only executed in already slow paths, and the patch RAM is even more anemic. I'd imagine you'd hit the same issues. That being said, my experiments were hardly conclusive and I'd absolutely love to be proven wrong.

blinkingled 6y ago

I can buy AMD or Intel CPUs, AMD/Intel/NVidia GPUs, a vast array of motherboards and cards, storage and networking pretty much off the shelf, throw Windows or Linux standard builds on it and expect it to work great and perform great. Try doing that with ARM and tell me under what limited circumstances would you buy ARM laptop/desktop/workstation. CPUs are at a stage where AMD and Intel are doing great in non battery constrained setups and with battery constraints you will only get better battery life if you don't make the CPUs sweat. In server/workstation design I would expect AMD and Intel to beat the crap out of ARM anything just because how much optimized they are in that space owing to massive use. So except for frothing at mouth idiots that keep droning about this there isn't much value for the normal customer in buying ARM anything and lose on all fronts - software availability, build flexibility, compatible hardware availability and even performance for many cases. (Spare me teh Geekbench please.) It does make sense for Apple to market their own CPUs to people who are into that type of thing - it's more control, more money and least dependence for Apple - all round win for them if they can pull it off. But it's not going to be easy unless they have something that is hugely better and overcomes at least some of the disadvantages.

weare138 6y ago
>I can buy AMD or Intel CPUs, AMD/Intel/NVidia GPUs, a vast array of motherboards and cards, storage and networking pretty much off the shelf, throw Windows or Linux standard builds on it and expect it to work great and perform great. I think this might be one of the motivations for Apple to switch to it's own CPUs instead of just switching to a different x86-64 CPU like AMD's Ryzen. Apple would be able to lock MacOS to the hardware like iOS and the iPhone.
- blinkingled 6y ago
  Absolutely it is but it's not just to shut down the few hackintosh users although that'd be an welcome consequence. It's only because they still have not figured out how the locked down macOS will work that they have not announced anything so far. Download apps only from Mac App Store, make it easy for people 100% in Apple ecosystem to do what they need to do (XCode, browsing, store apps, multi tasking) and they're good to go. They already charge premium for the hardware - not having to pay Intel will fatten the margins, with app store revenue and maybe banning 3rd party browsing engines they can get exactly what they have always wanted and so long as they provide people with some macOS features - terminal access (even if controlled) and multitasking etc. - people in the Apple ecosystem aren't going to care. Of course it maybe gradual and it maybe not so restrictive - they may allow 3rd party app installations and make it harder like they have already done in a way.

ksec 6y ago

The question isn't really x86 ( inclusive of every instruction currently on modern x86 ) vs ARM. It is simply the business model changes. The older I get the more I am convinced it isn't the technical that changes or determines the outcome, it is the value proposition. Not to mention no one "choose" x86. They chose Intel, or Intel CPU that still currently offer top performance under 10 - 16 Core.