6 ms·

On the one hand, x86 is (eventually) going the way of the dodo for some of the biggest datacenter customers, which is a large part of the reason that Intel has

On the one hand, x86 is (eventually) going the way of the dodo for some of the biggest datacenter customers, which is a large part of the reason that Intel has once again opened itself up to the prospect of foundry. On the other hand, x86 is so ubiquitous for PC that it would take a sea change for Apple Silicon to take over. Users and businesses are entrenched and this isn't the first time that Apple has run a different architecture from the rest of the PC crowd. I, for one, prefer my x86 MBP to the newfangled M1 because of RAM, compatibility, external display support, and number of ports. These limitations are all a function of implementation, not inherent to Apple Silicon, but they influence my preferences nonetheless. COVID-19 has changed the way that work is balanced against everything else in our lives, and I view its impact on the chip market as demand creation rather than a demand spike. We will never go back 100% to the way that things were prior to the pandemic; big shocks all have that in common. The hybrid model of work from home as a complement to office work means that people/companies will need to buy and maintain more hardware. I share your hope that this doesn't turn out the way the delayed nodes did. Intel's 10nm and 7nm setbacks started in the Krzanich days during the doldrums of the PC glut. People were mobile, phone innovations were booming, and no substantial PC advancements came to the fore during that time. I think we can give Intel some benefit of the doubt and assume that they aren't dumb enough to repeat the error of announcing a road map for which there is no road map...especially because the tick-tock model is already a thing of the past and exerts no expectations nowadays.

chrisseaton 5y ago
> Users and businesses are entrenched What dependency do you think most users and business have on the instruction set architecture, even if you ignore that you can translate?
- wmf 5y ago
  In many cases the dependency is native (not virtualized) Windows and Windows doesn't run natively on any good ARMs.
- Denvercoder9 5y ago
  There's an unbelievable amount of software out there for which porting is either not viable or not economical.
- Calvin02 5y ago
  I think you'd be surprised at how many businesses have proprietary applications that their resource stretched & budget starved IT orgs would not want to update. Consumers probably less so but businesses will definitely care. Translation might be an option for some. However, Rosetta currently only supports limited translation [0]. [0] - https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment https://developer.apple.com/documentation/apple-silicon/abou...
  - chrisseaton 5y ago
    > I think you'd be surprised at how many businesses have proprietary applications that their resource stretched & budget starved IT orgs would not want to update. Written in assembly language?
    - AnimalMuppet 5y ago
      Written in VB5. Or in C, but we're not sure where to find the source. Or expecting to be compiled by a 16-bit compiler and run in a DOS box. Or written in some off-brand interpreted language, and the interpreter only runs on x86. Or... Finding the source isn't free. Finding the archived compiler isn't free. Finding a machine that still can run the compiler isn't free. Re-writing the app isn't free.
      - chrisseaton 5y ago
        Doesn't dynamic binary translation cover these cases? It can't be that performance sensitive if it's written it VB5 and running on modern hardware.
        AnimalMuppet 5y ago
        It might. But if you've got a VB5 program that you're still running, are you the kind of person who knows about binary translation? Or do you just say "I'd better keep buying x86 and running Windows forever"?
- magicalhippo 5y ago
  At work we use Delphi to produce Windows applications that rely on Win32 and GDI. While Delphi can be used to make say Android apps, if you're going for Win32 you're limited to the x86(-64) compiler. A lot of the low-level stuff in standard libraries, third-party libraries and in our own code rely on platform details like calling conventions, which will almost certainly be different for a different architecture. Sure it can probably be rewritten, and a lot of code in the standard library already has generic high-level variants as fallback, but it's not going to be a simple recompile for us. By extension then, our customers rely on the ISA as long as they rely on our application, and our software is key to their operation.
smoldesu 5y ago
> On the one hand, x86 is (eventually) going the way of the dodo for some of the biggest datacenter customers For the most part, I'm convinced the bulk of this transition has already happened. If you were running highly-parallelized code or needed to switch to specialty hardware, you've probably done so already. > On the other hand, x86 is so ubiquitous for PC that it would take a sea change for Apple Silicon to take over. Not just Apple silicon, but for ARM to take over. Even the best compatibility layers for x86/ARM still present a massive performance hit, and there's otherwise no real incentive for the bulk of PC owners to switch over. I say this as the kid who grew up with a first-gen Raspberry Pi on their wishlist: x86 is an immovable force, and it will be decades before it loses support in the mainline Linux kernel. Even if Apple, Microsoft, Amazon and every other Fortune 500 company made a mad-dash transition to ARM (which they won't), you still couldn't dethrone x86 in terms of support and install-base.
reacharavindh 5y ago
It is true that M1 is limited in terms of some functions such as memory capacity, external display support etc. But, you need to consider two things. 1. M1 is Apple's 1st iteration. M1x or M2 is coming around, and Apple could likely get rid of all of those limitations. 2. Apple's tight control over M1 means they can build all sorts of features into the SOC and fast unlike Intel which has to cater to heterogenous needs from its integrators. Also, if you use a Mac with M1, you'd quickly realise how much of a work intel needs to catch up. Boy, it's so pleasant to use while being cool and quiet. Intel needs to run for the money and hope that no one figures out how to replicate Apple's success in the non-macos space and start eating intel's gold pot of datacenter CPUs. AWS Graviton?
rbanffy 5y ago
> it would take a sea change for Apple Silicon to take over Not really. Over my career I used x86, MIPS, PPC, SPARC, x86, and ARM machines. With the exception of x86 Windows boxes, they all looked and felt mostly the same. The Mac in front of me and the Linux laptop to my left incidentally use x86 CPUs but, at the core, they are both Unix-like machines and that's what I use them for. I don't care about binary compatibility and what ISA the machine uses inside it.

chrisseaton 5y ago

> Users and businesses are entrenched What dependency do you think most users and business have on the instruction set architecture, even if you ignore that you can translate?

wmf 5y ago
In many cases the dependency is native (not virtualized) Windows and Windows doesn't run natively on any good ARMs.
Denvercoder9 5y ago
There's an unbelievable amount of software out there for which porting is either not viable or not economical.
Calvin02 5y ago
I think you'd be surprised at how many businesses have proprietary applications that their resource stretched & budget starved IT orgs would not want to update. Consumers probably less so but businesses will definitely care. Translation might be an option for some. However, Rosetta currently only supports limited translation [0]. [0] - https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment https://developer.apple.com/documentation/apple-silicon/abou...
- chrisseaton 5y ago
  > I think you'd be surprised at how many businesses have proprietary applications that their resource stretched & budget starved IT orgs would not want to update. Written in assembly language?
  - AnimalMuppet 5y ago
    Written in VB5. Or in C, but we're not sure where to find the source. Or expecting to be compiled by a 16-bit compiler and run in a DOS box. Or written in some off-brand interpreted language, and the interpreter only runs on x86. Or... Finding the source isn't free. Finding the archived compiler isn't free. Finding a machine that still can run the compiler isn't free. Re-writing the app isn't free.
    - chrisseaton 5y ago
      Doesn't dynamic binary translation cover these cases? It can't be that performance sensitive if it's written it VB5 and running on modern hardware.
      - AnimalMuppet 5y ago
        It might. But if you've got a VB5 program that you're still running, are you the kind of person who knows about binary translation? Or do you just say "I'd better keep buying x86 and running Windows forever"?
magicalhippo 5y ago
At work we use Delphi to produce Windows applications that rely on Win32 and GDI. While Delphi can be used to make say Android apps, if you're going for Win32 you're limited to the x86(-64) compiler. A lot of the low-level stuff in standard libraries, third-party libraries and in our own code rely on platform details like calling conventions, which will almost certainly be different for a different architecture. Sure it can probably be rewritten, and a lot of code in the standard library already has generic high-level variants as fallback, but it's not going to be a simple recompile for us. By extension then, our customers rely on the ISA as long as they rely on our application, and our software is key to their operation.

smoldesu 5y ago

> On the one hand, x86 is (eventually) going the way of the dodo for some of the biggest datacenter customers For the most part, I'm convinced the bulk of this transition has already happened. If you were running highly-parallelized code or needed to switch to specialty hardware, you've probably done so already. > On the other hand, x86 is so ubiquitous for PC that it would take a sea change for Apple Silicon to take over. Not just Apple silicon, but for ARM to take over. Even the best compatibility layers for x86/ARM still present a massive performance hit, and there's otherwise no real incentive for the bulk of PC owners to switch over. I say this as the kid who grew up with a first-gen Raspberry Pi on their wishlist: x86 is an immovable force, and it will be decades before it loses support in the mainline Linux kernel. Even if Apple, Microsoft, Amazon and every other Fortune 500 company made a mad-dash transition to ARM (which they won't), you still couldn't dethrone x86 in terms of support and install-base.

reacharavindh 5y ago

It is true that M1 is limited in terms of some functions such as memory capacity, external display support etc. But, you need to consider two things. 1. M1 is Apple's 1st iteration. M1x or M2 is coming around, and Apple could likely get rid of all of those limitations. 2. Apple's tight control over M1 means they can build all sorts of features into the SOC and fast unlike Intel which has to cater to heterogenous needs from its integrators. Also, if you use a Mac with M1, you'd quickly realise how much of a work intel needs to catch up. Boy, it's so pleasant to use while being cool and quiet. Intel needs to run for the money and hope that no one figures out how to replicate Apple's success in the non-macos space and start eating intel's gold pot of datacenter CPUs. AWS Graviton?

rbanffy 5y ago

> it would take a sea change for Apple Silicon to take over Not really. Over my career I used x86, MIPS, PPC, SPARC, x86, and ARM machines. With the exception of x86 Windows boxes, they all looked and felt mostly the same. The Mac in front of me and the Linux laptop to my left incidentally use x86 CPUs but, at the core, they are both Unix-like machines and that's what I use them for. I don't care about binary compatibility and what ISA the machine uses inside it.