The comparison is a bit unfair. x86 is like a decade older than ARM. Not that much in retrospect. aarch64 is as "free of historical legacy" as x86_64 is (that is: not at all free). There is lot of cruft and even multiple ISAs in aarch64 (e.g. T32/Thumb).

And the CISC vs RISC arguments are questionable, seeing that Apple has done the migration in both directions by now.

I noticed that Apple made absolutely no mention of ARM in their keynote. Seems like they're trying to whitelabel it for brand benefits as well as to divorce themselves from any expectations around standards?

That was interesting! Surely not an accident. Possibly to:

- Emphasise the breadth of their silicon expertise across CPU / GPU / Neural Engines etc. - Because Arm has little or no brand recognition (Apple > Intel > Arm in branding terms). - Distinguish from any me-too moves to Arm by competitors.

There you go! Someone finally figured it out. Apple is moving to Apple Silicon, not ARM. Try to get LG to announce they’re offering a PC with Apple Silicon tomorrow.

The absence of any ARM mention is marketing, nothing more.

Which competitors? Windows and ChromeOS have already been sold on ARM hardware.

They scarcely ever have with regards to iOS either; architecture has never been a talking point for their CPUs. How long was it from iPhone announcement to knowing it was ARM? How long from the Apple A4 announcement to knowing it was ARM?

Yep, most of that old "cruft" is essentially unused and turned off. A log of critics of x86 don't really know what they're talking about. x86 is inefficient because they don't really have much incentive to end the status quo where performance is more important than power to most customers. People are happy with 3-4 hours out of their laptops so Intel and AMD aim for that and sacrifice power for performance, quit often that is the tradeoff in the design.

> People are happy with 3-4 hours out of their laptops so Intel and AMD aim for that and sacrifice power for performance

Heck, I'm happy with 1 hour. I leave my laptop plugged in nearly 100% of the time. The point of the laptop is that it's easy to move, not that I want to use it while I'm in transit.

Intel missed the whole move of personal computing to mobile devices. Not missing out on that should have been incentive enough one might think.

Some is turned off but some still has to be dealt with (variable instruction lengths for example).

Intel tried to compete in mobile for a long time and failed even with a better manufacturing process.

> Some is turned off but some still has to be dealt with (variable instruction lengths for example).

Modern x86_64 processors don't actually natively execute x86 instructions, they translate them into the instructions the hardware actually uses. The percentage of the die required to do that translation is small and immaterial.

> Intel tried to compete in mobile for a long time and failed even with a better manufacturing process.

Intel didn't understand the market.

I recently bought a new phone. On paper it's twice as fast as my old phone. I imagine that's true but I can't tell any difference. Everything was sufficiently fast before and it still is. I never use my phone to do anything that needs an actually-fast CPU. I have no reason to pay additional money for a faster phone CPU. But I do notice how often I have to charge the battery.

These are not atypical purchasing criteria for mobile devices, but that's not the market Intel was chasing with their designs and pricing, so they failed. It's not because they couldn't make an x86 CPU for that market, it's because they didn't want to, because it's a lower margin commodity market.

Faster cpus become more power-efficient cpus because they can race to sleep. So you really do want to pay more for that cpu, but not for the compute performance but for the battery life.

https://en.wikichip.org/wiki/race-to-sleep

That's assuming the faster CPUs use the same amount of power. It's possible for a slower CPU to have better performance per watt. This is often exactly what happens when you limit clock speed -- performance goes down, performance per watt goes up.

> Intel tried to compete in mobile for a long time and failed even with a better manufacturing process.

They didn't fail because of performance, though, they failed because of app support & lack of a quality radio. The CPU performance & efficiency itself was otherwise fine. It wasn't always chart-topping good, but it wasn't bad either.

Agreed - CPUs (at the end at least) were fine. Also they were probably looking for bigger margins than were available.

General point is that I think that Arm has a small architectural advantage due to lack of cruft but that other factors are usually more important - e.g. the resources and quality of team behind implementation.

Sorry meant A64 rather than aarch64 as pretty sure that Apple hasn't supported 32 bit for a while now (so no T32 or Thumb) so the instruction set was announced in 2010 and definitely cleaner than x86.

Agreed that CISC vs RISC is very questionable by now.

Provided that the software is correctly written, ARM's weaker memory model allows for more flexible instruction and I/O scheduling.

It seems most people feel that the DEC Alpha went too far in weakening the memory model to improve performance, but A64 seems to at least be near the sweet spot.

It's also not a huge amount of work that gets thrown away decoding x86 instructions in parallel, but there's non-zero overhead introduced by having the start location of the next instruction depend on what the current instruction is.

The weaker memory model also uncovers synchronization bugs that have been papered over by x86's stronger semantics ;)

Apple's recent aarch64 implementations don't support any of the 32 bit ARM instruction sets, and aarch64 is a significant departure from armv7