9 ms·

Both Intel and AMD have the major disadvantage of having (or, let's say, wanting) to maintain x86 backward compatibility - which means not only staying compatib

by rob74 4y ago

Both Intel and AMD have the major disadvantage of having (or, let's say, wanting) to maintain x86 backward compatibility - which means not only staying compatible with the almost 45 year old CISC instruction set of the Intel 8086, but also with the whole line of CPUs that came after it. All this ballast makes it harder for them to build an energy-efficient CPU. By contrast, Apple was able to just create a new CPU based on the much more modern ARM architecture, and switch to it like they have already done two times before (from 68k to PowerPC and then to x86), because they control the whole Macintosh platform. Compare that to Microsoft's largely unsuccessful attempt of selling ARM-based Windows machines.

saagarjha 4y ago
Having to support x86 is definitely not a "major" disadvantage.
- hajile 4y ago
  The X2 cores in 8cx gen3 get similar performance to Zen 2 U-series chips while using 7-10w instead of 15-50w. How many more ARM chips have to get equivalent performance at a tiny fraction of the power before people will finally start considering that either AMD and Intel hire the most incompetent people out there or that ISA actually matters?
  - saagarjha 4y ago
    The competent people say that ISA doesn’t matter, so there’s that.
    - hajile 4y ago
      Do their actions match their words? ARM could have extended their ARMv7 ISA to also be 64-bit without much trouble at all (plenty of space in the ISA). Instead, we got a ground up redesign that has more in common with MIPS64 than with ARMv7 (to the point that it's fascinating that ARM and some others bought MIPS just to get patent rights before immediately selling them off again). I'm sure the go-to individual here is Jim Keller. First, were his words free from constraint? If he said "x86 is crap and we should be using ARM or RISC-V" while working for those companies, how long would it take for him to be fired? Even if he were working at another company, saying that would burn a bridge that has kept him fed for decades. Would that be worth it? He later said that if he were designing a new chip from the ground up, he'd probably go with RISC-V. He then proceeded to do that when he went to work for TensTorrent even though licensing ARM cores and adding their custom units on the side would be cheaper and faster to market. Given his connections, working with the AMD custom division would also be possible and would not only save some time and money for the startup, but would also have a massive set of available and heavily-optimized software working from the very start which would save even more money. I'd say that his actions when free from corporate constraints show a definite opinion on the matter.
      - therealcamino 4y ago
        When you're designing a new chip and working at a a fabless semiconductor startup, that doesn't mean you're free from corporate constraints. The most obvious is that if you design an ARM-based chip, the company has to pay royalties, and if you design a RISC-V chip, you don't.
        hajile 4y ago
        ARM typically charges 1-2% in royalties. A company has to sell a LOT of chips for this to be the driving factor. In the case of a startup, we're talking about eliminating two entire teams costing tens to hundreds of millions per year and probably getting to market faster. You can sell a LOT of chips for even a small 100M R&D cost.
yxhuvud 4y ago
How about waiting until the competitors is actually on the same process node size until declaring the x86 baggage to costly? Most of all, Apple is currently in the lead because they threw money on TSMC to get a virtual monopoly on the smallest node size. How much of that which will remain once the competitors are comparable is an unknown at this point.
- throwaway5959 4y ago
  What if Apple maintains a lead in process mode though? 3 nm while Intel is at 5, 2 nm while Intel is at 3, etc. I’m glad they have competition from more than just AMD and wish all three the best.
  - yxhuvud 4y ago
    Apple may maintain the lead, but it is done by throwing money at TSMC, not by having better technology by themselves. I'd prefer a situation where the TSMC let all of them have some access to the better node sizes as that would let the company with the better tech sell more.
    - throwaway5959 4y ago
      I don’t see why the distinction would matter to the people it should matter the most to, Apple’s customers.
      - yxhuvud 4y ago
        I was responding to a claim that Apple would keep their lead due to x86 baggage. It matters for the truthiness for that claim, it doesn't matter for how much stuff Apple will sell.
- mromanuk 4y ago
  Comparing currently available CPUs on the market is pretty fair.
dtech 4y ago
This argument goes back 30 years. As far as I know, not a hardware engineer, it's not that much of an issue since the only complicated thing is the decoder, and then it's microcode and not an issue. The TSO memory guarantee X86 is probably the exception, since Apple supports it on their M1s too for emulation.
kaba0 4y ago
Do we know whether that x86 backward compatibility is all that problematic? If I’m not mistaken, it is only used as a “public API” even in current CPUs, and on a microcode level it doesn’t have as much relevance.
- dmitrygr 4y ago
  For example: Decode. One of the things Apple CPUs keep being praised for is how wide they are. To be wide effectively and keep your execution units busy, you need a wide decoder. With aarch64 it is easy. Every instruction is 4 bytes on a 4 byte boundary. Want a 4-wide decoder? Ingest 16 bytes and copy-and-paste the same decoder 4 times. X86 instructions are variable-length: 1-15 bytes. And you do not know how long any instruction is until you read almost every byte of it (there is no length byte up front - it is just a list of prefixes). Thus to make a 4-wide decoder you need to ingest up to 60 bytes, and your decoder cannot start on instruction #2 till it finds the end of # 1. (Or guess, and rewind as needed). Much harder and a rather long dependency chain for decoder #4 to even get started. Now say you want to go wider: 8-wide. Arm64: copy and paste same decoders again. Done X86: Now you need to ingest 120 bytes, and find even more boundaries, each depending on the previous - an even longer dependency chain. Decoder #8 cannot start till #1 - #7 are almost done. A mess nobody has managed to solve yet.
  - abc_lisper 4y ago
    Excellent answer. I learnt something today!
  - gary_0 4y ago
    And those bytes matter when most Intel CPU cores have only a few dozen KB of L1I cache. Interestingly, the M1 and M2 performance cores have a whopping 192KB of L1 instruction cache.
    - kaba0 4y ago
      Isn’t it in part due to business reasons, namely that Apple is not a CPU vendor, it doesn’t have to turn a profit on chips so it can allow much larger die sizes and thus larger cache sizes as well. Is there something inherent in ARM here I’m missing?
alberth 4y ago
> Apple was able to just create a new CPU based on the much more modern ARM architecture Is that accurate? x86 launched in 1978. (64bit in 2003). ARM launched in 1985. (64bit in 2011). https://en.m.wikipedia.org/wiki/X86 https://en.m.wikipedia.org/wiki/X86 https://en.m.wikipedia.org/wiki/ARM_architecture_family https://en.m.wikipedia.org/wiki/ARM_architecture_family
- dmitrygr 4y ago
  X86-64 INCLUDES all the legacy cruft of x86-32 and x86-16 and is thus 44 years old. Aarch64 in Apple chips doesn’t include A32 and is thus 11 years old. It is indeed a large age difference.
  - agsnu 4y ago
    Apple was also the first vendor to ship an ARMv8-A compatible chip; I'm sure there have been reports that they heavily influenced the design of AArch64 but I can't dig them out right now.
    - NobodyNada 4y ago
      To back this up, here’s a Twitter thread from an Apple engineer: https://twitter.com/stuntpants/status/1346470705446092811 https://twitter.com/stuntpants/status/1346470705446092811 > arm64 is the Apple ISA, it was designed to enable Apple’s microarchitecture plans. There’s a reason Apple’s first 64 bit core (Cyclone) was years ahead of everyone else, and it isn’t just caches. > Arm64 didn’t appear out of nowhere, Apple contracted ARM to design a new ISA for its purposes. When Apple began selling iPhones containing arm64 chips, ARM hadn’t even finished their own core design to license to others. > ARM designed a standard that serves its clients and gets feedback from them on ISA evolution. In 2010 few cared about a 64-bit ARM core. Samsung & Qualcomm, the biggest mobile vendors, were certainly caught unaware by it when Apple shipped in 2013. > Apple planned to go super-wide with low clocks, highly OoO, highly speculative. They needed an ISA to enable that, which ARM provided. > M1 performance is not so because of the ARM ISA, the ARM ISA is so because of Apple core performance plans a decade ago.
  - 4y ago
hnlmorg 4y ago
> much more modern ARM architecture ARM is nearly as old as x86 and has had just as many evolutions in architecture as x86.
- johnklos 4y ago
  But ARM didn't start out as a shitpile of attempted backwards compatibility with an 8 bit CPU. The i8086 was made as an evolution of the i8080.
  - ido 4y ago
    And it's also not really "nearly as old" considering how fast stuff developed in the early day - the first ARM CPUs launched in 1986, and the i8086 in 1978 - 8 years earlier.
    - NobodyNada 4y ago
      Yeah, the processor world changed a LOT in those 8 years. Specifically, Berkley RISC and MIPS were developed, which ARM was based on. In today’s world of “tick-tock-tock-tock-tock-tock” it’s easy to forget just how fast the semiconductor industry was moving during the 70’s-80’s. Just about every processor sold introduced a completely new architecture
    - hnlmorg 4y ago
      That still doesn’t make ARM “modern”.
      - johnklos 4y ago
        No. The design made it modern. Look at the m68000 (1979) compared with the i8086 (1978). The m68k was 32 bits from the beginning, so while moving from the m68000 to the m68020 did add some instructions, there were no "special modes" for "backwards compatibility". All binaries that run on the m68000 can directly on the m68020. Add an MMU and optionally an FPU to an m68020 (1984) or just use an m68030 (1987), and you have a fully modern system that can run modern software in 2022. The i80386 (1985) is 32 bits and much more modern than the i8086, but real mode and 386 mode are completely different. Even with this modernization, Intel didn't bother with atomic operations, which is why neither Linux nor the BSDs support the original i80386. To run modern software, you'd need an i80486 (1989).
CoastalCoder 4y ago
IMHO a major enabler for this is LLVM. I think it's significantly reduced the time / cost / difficulty in rolling out a new instruction set architecture.
- cowtools 4y ago
  Are the GCC cross-compilers for ARM64 not sufficient? We're not talking about some niche, new architecture here like RISCV or WASM.
  - pdpi 4y ago
    Rolling out a new architecture isn't just about getting your own tools out, it's about enabling the rest of the ecosystem to come along for the ride. LLVM is specifically meant to be a compiler backend that you write languages frontends against. It sort of solves the expression problem for programming languages, and there's a whole range of production-ready compilers out there using it. When they add support for an architecture, every one of those languages also gets a large part of the work to support it done for them.
- gary_0 4y ago
  I think it goes beyond LLVM, it's software in general. 20 years ago, software was locked into a particular architecture because proprietary compilers and binary blobs were the norm, and vendors still ruled their platforms with an iron fist. But nowadays, open source libraries and compilers are a lot more standard, and a lot of hardware/software is cross-platform so switching is easier. Linux is mainstream and gives you support for dozens of architectures for free. Also, CPU technology (outside of tiny embedded chips) is a lot more uniform with fewer weird variations or cost-cutting shortcuts, and transistors are ridiculously cheap. You can assume 32/64-bit, little-endian, twos-complement math, IEEE-754 floats, etc.
rbanffy 4y ago
> Compare that to Microsoft's largely unsuccessful attempt of selling ARM-based Windows machines. Microsoft failed at that multiple times in the past. Windows NT was initially available for multiple architectures, but that mostly ended with Windows 2000. Itanium got support until Server 2008 but non-server software support was very limited. Some Windows NT releases had a "workstation" label but application support, even from Microsoft, was between halfhearted and non-existent and the availability of some programs (such as Office) was almost a secret (I remember it existing for PPC, but never heard anything for MIPS or Alpha).
mrandish 4y ago
> staying compatible with the almost 45 year old CISC instruction set It's easy to take for granted how unusual it was the WinTel hegemony happened at all. As a fan of the breathtaking diversity of classic 80s desktop computing (Amiga, Atari, C64, Spectrum, MSX, etc), I lamented the steamroller of WinTel beige-box homogenization as it paved over so many divergent evolutionary branches. Yet the fact I can still install and run mass market consumer software products released in the mid-90s on Windows 11. Yes, a high price was paid in both silicon and OS software to sustain such extraordinary backward compatibility - and is still being paid. While the utility of running circa-Win 95 software today in minimal, it's pretty amazing and I think the underlying stability in APIs, user interfaces and peripheral interfaces had under-appreciated positive impacts on the rapid prolife ation of desktop computing across society. Remember that the landline phone and cable companies initially envisioned the "home computer" to a be little more than a dumb terminal consumers would rent like a telephone handset. We're fortunate that vision failed when the commoditization of PCs allowed the home "internet terminal" to be a full user-owned and controlled computer with significant local processing and storage.
- CamperBob2 4y ago
  An underrepresented point of view, certainly. As a software developer at a small game publisher, our idea of hell was a dozen incompatible platforms, none of which had a decisive advantage over the others, few of which could be ignored if the company were to prosper, and all of which were just different enough to tie up resources for porting that were badly needed for product development. Wintel made a lot of good things possible that simply could never have happened in a fragmented market.
Asooka 4y ago
But you can run x86 software on the M1 at almost native speed through a software translator. Isn't that proof enough that the instruction set itself isn't what's holding back the hardware?
- fooker 4y ago
  Most of the translation is done ahead of time, not something you pay for while running.

by rob74 4y ago

saagarjha 4y ago

Having to support x86 is definitely not a "major" disadvantage.

hajile 4y ago
The X2 cores in 8cx gen3 get similar performance to Zen 2 U-series chips while using 7-10w instead of 15-50w. How many more ARM chips have to get equivalent performance at a tiny fraction of the power before people will finally start considering that either AMD and Intel hire the most incompetent people out there or that ISA actually matters?
- saagarjha 4y ago
  The competent people say that ISA doesn’t matter, so there’s that.
  - hajile 4y ago
    Do their actions match their words? ARM could have extended their ARMv7 ISA to also be 64-bit without much trouble at all (plenty of space in the ISA). Instead, we got a ground up redesign that has more in common with MIPS64 than with ARMv7 (to the point that it's fascinating that ARM and some others bought MIPS just to get patent rights before immediately selling them off again). I'm sure the go-to individual here is Jim Keller. First, were his words free from constraint? If he said "x86 is crap and we should be using ARM or RISC-V" while working for those companies, how long would it take for him to be fired? Even if he were working at another company, saying that would burn a bridge that has kept him fed for decades. Would that be worth it? He later said that if he were designing a new chip from the ground up, he'd probably go with RISC-V. He then proceeded to do that when he went to work for TensTorrent even though licensing ARM cores and adding their custom units on the side would be cheaper and faster to market. Given his connections, working with the AMD custom division would also be possible and would not only save some time and money for the startup, but would also have a massive set of available and heavily-optimized software working from the very start which would save even more money. I'd say that his actions when free from corporate constraints show a definite opinion on the matter.
    - therealcamino 4y ago
      When you're designing a new chip and working at a a fabless semiconductor startup, that doesn't mean you're free from corporate constraints. The most obvious is that if you design an ARM-based chip, the company has to pay royalties, and if you design a RISC-V chip, you don't.
      - hajile 4y ago
        ARM typically charges 1-2% in royalties. A company has to sell a LOT of chips for this to be the driving factor. In the case of a startup, we're talking about eliminating two entire teams costing tens to hundreds of millions per year and probably getting to market faster. You can sell a LOT of chips for even a small 100M R&D cost.

yxhuvud 4y ago

How about waiting until the competitors is actually on the same process node size until declaring the x86 baggage to costly? Most of all, Apple is currently in the lead because they threw money on TSMC to get a virtual monopoly on the smallest node size. How much of that which will remain once the competitors are comparable is an unknown at this point.

throwaway5959 4y ago
What if Apple maintains a lead in process mode though? 3 nm while Intel is at 5, 2 nm while Intel is at 3, etc. I’m glad they have competition from more than just AMD and wish all three the best.
- yxhuvud 4y ago
  Apple may maintain the lead, but it is done by throwing money at TSMC, not by having better technology by themselves. I'd prefer a situation where the TSMC let all of them have some access to the better node sizes as that would let the company with the better tech sell more.
  - throwaway5959 4y ago
    I don’t see why the distinction would matter to the people it should matter the most to, Apple’s customers.
    - yxhuvud 4y ago
      I was responding to a claim that Apple would keep their lead due to x86 baggage. It matters for the truthiness for that claim, it doesn't matter for how much stuff Apple will sell.
mromanuk 4y ago
Comparing currently available CPUs on the market is pretty fair.

dtech 4y ago

This argument goes back 30 years. As far as I know, not a hardware engineer, it's not that much of an issue since the only complicated thing is the decoder, and then it's microcode and not an issue. The TSO memory guarantee X86 is probably the exception, since Apple supports it on their M1s too for emulation.

kaba0 4y ago

Do we know whether that x86 backward compatibility is all that problematic? If I’m not mistaken, it is only used as a “public API” even in current CPUs, and on a microcode level it doesn’t have as much relevance.

dmitrygr 4y ago
For example: Decode. One of the things Apple CPUs keep being praised for is how wide they are. To be wide effectively and keep your execution units busy, you need a wide decoder. With aarch64 it is easy. Every instruction is 4 bytes on a 4 byte boundary. Want a 4-wide decoder? Ingest 16 bytes and copy-and-paste the same decoder 4 times. X86 instructions are variable-length: 1-15 bytes. And you do not know how long any instruction is until you read almost every byte of it (there is no length byte up front - it is just a list of prefixes). Thus to make a 4-wide decoder you need to ingest up to 60 bytes, and your decoder cannot start on instruction #2 till it finds the end of # 1. (Or guess, and rewind as needed). Much harder and a rather long dependency chain for decoder #4 to even get started. Now say you want to go wider: 8-wide. Arm64: copy and paste same decoders again. Done X86: Now you need to ingest 120 bytes, and find even more boundaries, each depending on the previous - an even longer dependency chain. Decoder #8 cannot start till #1 - #7 are almost done. A mess nobody has managed to solve yet.
- abc_lisper 4y ago
  Excellent answer. I learnt something today!
- gary_0 4y ago
  And those bytes matter when most Intel CPU cores have only a few dozen KB of L1I cache. Interestingly, the M1 and M2 performance cores have a whopping 192KB of L1 instruction cache.
  - kaba0 4y ago
    Isn’t it in part due to business reasons, namely that Apple is not a CPU vendor, it doesn’t have to turn a profit on chips so it can allow much larger die sizes and thus larger cache sizes as well. Is there something inherent in ARM here I’m missing?

alberth 4y ago

> Apple was able to just create a new CPU based on the much more modern ARM architecture Is that accurate? x86 launched in 1978. (64bit in 2003). ARM launched in 1985. (64bit in 2011). https://en.m.wikipedia.org/wiki/X86 https://en.m.wikipedia.org/wiki/X86 https://en.m.wikipedia.org/wiki/ARM_architecture_family https://en.m.wikipedia.org/wiki/ARM_architecture_family

dmitrygr 4y ago
X86-64 INCLUDES all the legacy cruft of x86-32 and x86-16 and is thus 44 years old. Aarch64 in Apple chips doesn’t include A32 and is thus 11 years old. It is indeed a large age difference.
- agsnu 4y ago
  Apple was also the first vendor to ship an ARMv8-A compatible chip; I'm sure there have been reports that they heavily influenced the design of AArch64 but I can't dig them out right now.
  - NobodyNada 4y ago
    To back this up, here’s a Twitter thread from an Apple engineer: https://twitter.com/stuntpants/status/1346470705446092811 https://twitter.com/stuntpants/status/1346470705446092811 > arm64 is the Apple ISA, it was designed to enable Apple’s microarchitecture plans. There’s a reason Apple’s first 64 bit core (Cyclone) was years ahead of everyone else, and it isn’t just caches. > Arm64 didn’t appear out of nowhere, Apple contracted ARM to design a new ISA for its purposes. When Apple began selling iPhones containing arm64 chips, ARM hadn’t even finished their own core design to license to others. > ARM designed a standard that serves its clients and gets feedback from them on ISA evolution. In 2010 few cared about a 64-bit ARM core. Samsung & Qualcomm, the biggest mobile vendors, were certainly caught unaware by it when Apple shipped in 2013. > Apple planned to go super-wide with low clocks, highly OoO, highly speculative. They needed an ISA to enable that, which ARM provided. > M1 performance is not so because of the ARM ISA, the ARM ISA is so because of Apple core performance plans a decade ago.
- 4y ago

hnlmorg 4y ago

> much more modern ARM architecture ARM is nearly as old as x86 and has had just as many evolutions in architecture as x86.

johnklos 4y ago
But ARM didn't start out as a shitpile of attempted backwards compatibility with an 8 bit CPU. The i8086 was made as an evolution of the i8080.
- ido 4y ago
  And it's also not really "nearly as old" considering how fast stuff developed in the early day - the first ARM CPUs launched in 1986, and the i8086 in 1978 - 8 years earlier.
  - NobodyNada 4y ago
    Yeah, the processor world changed a LOT in those 8 years. Specifically, Berkley RISC and MIPS were developed, which ARM was based on. In today’s world of “tick-tock-tock-tock-tock-tock” it’s easy to forget just how fast the semiconductor industry was moving during the 70’s-80’s. Just about every processor sold introduced a completely new architecture
  - hnlmorg 4y ago
    That still doesn’t make ARM “modern”.
    - johnklos 4y ago
      No. The design made it modern. Look at the m68000 (1979) compared with the i8086 (1978). The m68k was 32 bits from the beginning, so while moving from the m68000 to the m68020 did add some instructions, there were no "special modes" for "backwards compatibility". All binaries that run on the m68000 can directly on the m68020. Add an MMU and optionally an FPU to an m68020 (1984) or just use an m68030 (1987), and you have a fully modern system that can run modern software in 2022. The i80386 (1985) is 32 bits and much more modern than the i8086, but real mode and 386 mode are completely different. Even with this modernization, Intel didn't bother with atomic operations, which is why neither Linux nor the BSDs support the original i80386. To run modern software, you'd need an i80486 (1989).

CoastalCoder 4y ago

IMHO a major enabler for this is LLVM. I think it's significantly reduced the time / cost / difficulty in rolling out a new instruction set architecture.

cowtools 4y ago
Are the GCC cross-compilers for ARM64 not sufficient? We're not talking about some niche, new architecture here like RISCV or WASM.
- pdpi 4y ago
  Rolling out a new architecture isn't just about getting your own tools out, it's about enabling the rest of the ecosystem to come along for the ride. LLVM is specifically meant to be a compiler backend that you write languages frontends against. It sort of solves the expression problem for programming languages, and there's a whole range of production-ready compilers out there using it. When they add support for an architecture, every one of those languages also gets a large part of the work to support it done for them.
gary_0 4y ago
I think it goes beyond LLVM, it's software in general. 20 years ago, software was locked into a particular architecture because proprietary compilers and binary blobs were the norm, and vendors still ruled their platforms with an iron fist. But nowadays, open source libraries and compilers are a lot more standard, and a lot of hardware/software is cross-platform so switching is easier. Linux is mainstream and gives you support for dozens of architectures for free. Also, CPU technology (outside of tiny embedded chips) is a lot more uniform with fewer weird variations or cost-cutting shortcuts, and transistors are ridiculously cheap. You can assume 32/64-bit, little-endian, twos-complement math, IEEE-754 floats, etc.

rbanffy 4y ago

> Compare that to Microsoft's largely unsuccessful attempt of selling ARM-based Windows machines. Microsoft failed at that multiple times in the past. Windows NT was initially available for multiple architectures, but that mostly ended with Windows 2000. Itanium got support until Server 2008 but non-server software support was very limited. Some Windows NT releases had a "workstation" label but application support, even from Microsoft, was between halfhearted and non-existent and the availability of some programs (such as Office) was almost a secret (I remember it existing for PPC, but never heard anything for MIPS or Alpha).

mrandish 4y ago

> staying compatible with the almost 45 year old CISC instruction set It's easy to take for granted how unusual it was the WinTel hegemony happened at all. As a fan of the breathtaking diversity of classic 80s desktop computing (Amiga, Atari, C64, Spectrum, MSX, etc), I lamented the steamroller of WinTel beige-box homogenization as it paved over so many divergent evolutionary branches. Yet the fact I can still install and run mass market consumer software products released in the mid-90s on Windows 11. Yes, a high price was paid in both silicon and OS software to sustain such extraordinary backward compatibility - and is still being paid. While the utility of running circa-Win 95 software today in minimal, it's pretty amazing and I think the underlying stability in APIs, user interfaces and peripheral interfaces had under-appreciated positive impacts on the rapid prolife ation of desktop computing across society. Remember that the landline phone and cable companies initially envisioned the "home computer" to a be little more than a dumb terminal consumers would rent like a telephone handset. We're fortunate that vision failed when the commoditization of PCs allowed the home "internet terminal" to be a full user-owned and controlled computer with significant local processing and storage.

CamperBob2 4y ago
An underrepresented point of view, certainly. As a software developer at a small game publisher, our idea of hell was a dozen incompatible platforms, none of which had a decisive advantage over the others, few of which could be ignored if the company were to prosper, and all of which were just different enough to tie up resources for porting that were badly needed for product development. Wintel made a lot of good things possible that simply could never have happened in a fragmented market.

Asooka 4y ago

But you can run x86 software on the M1 at almost native speed through a software translator. Isn't that proof enough that the instruction set itself isn't what's holding back the hardware?

fooker 4y ago
Most of the translation is done ahead of time, not something you pay for while running.