Hacker News Reader

Comment by reitzensteinm | Hacker News Reader

Both times, the performance boost of the new architecture significantly offset the emulation overhead. It's going in reverse this time, emulating the old instruction set with a weaker processor.

Further, there's a lot more focus on battery life these days, and while many apps will be tolerable from a UX perspective if you halved their speed, that also means the CPU is spending twice as long at the highest turbo states. Ouch.

I also think Apple could pull it off, and actually want to see it happen for the health of the PC industry. But I haven't seen anyone declaring it's not possible, I think that's a bit of a straw man.

View on HN

Both times the new CPU architecture was faster than the older one, granted. But still the emulated software would be slower on the new models with the emulator compared to bare metal execution on the old models.

I assume Apple will make some more improvements to close the gap between x86 and ARM, and switch when it makes sense for them. I also assume that, with the Mac App Store, they will start forcing developers to ship software compiled to both architectures ahead of making the switch. This way, only software that is distributed outside their store would be slow, which is going to become more and more niche as Apple enabled stricter signing enforcement by default in macOS Sierra (by default, only apps from the Mac App Store are allowed to run).

Given that Apple has full control over the CPU itself, I wouldn't be surprised if the first ARM Mac has a CPU with a handful of extra instructions which bridge the performance gap. I bet they already did extensive profiling of x86 code from any major app (esp. those submitted to the app store) and identified 5-6 instructions (to be made available to the emulation layer only) which avoid some of the most expensive translation / abstraction / emulation steps.

They don’t have full control. Apple can’t add instructions, only Arm can. If they want something new they have to go back to Arm, sure hey probably have lots of pull, but that’s the way it is. And one reason ppl like RiscV.

Actually - if I'm not mistaken - what you say holds true for almost any other company but _not_ for Apple: They are holders of an architectural license, which gives them (and very few others in the world) this freedom.

It was discussed a while ago here on HN: https://news.ycombinator.com/item?id=10190521

Architecture license means you can use the ISA (provided by Arm). Micro arch means you can license the core implementations form Arm. Apple is an ISA license, meaning they have full control of the micro arch as long as it passes verification by Arm. That’s the beauty of Arm, you get rid of the problem of creating the whole software ecosystem...it’s already there, and companies like Cavium, Apple, Qualcomm are free to add their secret sauce and benefit from the mature software environment. At least, that’s the hope.

Prior to ARMv8, all licensees could add additional specialized instructions or even entire instruction sets using the ARM coprocessor model.

By changing a few registers, you could alter how instructions were interpreted. This was used by some vendors for hardware-software interfacing, and by others to provide specific acceleration primitives for their specialized workloads.

ARM used this mechanism themselves to offer an optional floating point unit, with specialized vectorized floating point instructions.

Unfortunately, support for coprocessors has been removed from ARMv8.

Reply on news.ycombinator.com