Hacker News Reader

Comment by zrm | Hacker News Reader

The scaling is really the question. ARM processors generally have better performance per watt because they're designed to prioritize power efficiency over absolute performance. The Intel parts Apple's ARM processors compare to on performance are the lowest power ones, which isn't exactly the sweet spot for Intel's microarchitecture.

If you gave the ARM designers the (higher) laptop power budget, almost certainly they'd increase performance at the expense of performance per watt. In other words they'd take more of the trade offs that Intel and AMD do. But to justify switching architectures it can't just be the same, it would have to be enough better to be worth the transition.

View on HN

This has been exactly proven out by Amazon - https://aws.amazon.com/about-aws/whats-new/2019/12/announcin...

If Amazon can make a server class ARM chip that is competitive or better with their custom designed Xeons, I take it as a truism Apple could do the same for mobile.

The problem is the use-case. The software Mac laptops run would perform horribly on ARM. A Macbook Pro is not going to have an ARM processor.

It already does, in the T2. It seems to me like future T* chips will run more and more of the system, leaving the x86 to become something like the MBP’s discrete GPU option. And then, like discrete GPUs, eventually an x86 CPU is only available in top-end models.

Why do you think the software Macs run are so much different than the software that iPad Pros run? They run some of the same frameworks. Since when you run iOS apps in the simulator for Macs you actually running x86 builds of iOS apps linked against an x86 build of the iOS frameworks, it’s not hard to compare performance

There are a lot of reasons to expect that to work better for servers than laptops.

Most server workloads scale with core count, so winning in performance per watt is winning in general because you can scale performance by adding cores. A server with twice as many cores that are each half as fast is just as good, but that doesn't work for a laptop.

A server processor also doesn't have to win at every workload. If it can win at any workload, people can use it for only those, which makes it useful. That also doesn't really work for a laptop.

People run Linux on servers. It's portable. The architectural transition cost there is close to zero.

On top of that, Amazon is fudging the benchmarks in claiming it's faster. They're comparing performance "per-vCPU" which on Intel are hyperthreads rather than full cores. That's fine when Amazon is charging less for the ARM "vCPU" than the Intel hyperthread "vCPU", but you can't use that trick when running single-threaded workloads on a laptop.

And OS X is portable. It’s already been ported from PPC to x86 and parts of it back and forth between ARM and x86.

The operating system itself isn't the problem, it's all the applications. And the PowerPC transition was both easier and more worth it because the x86 processors were so much faster than the PowerPC processors of the time that they were competitive even when emulating PowerPC code, which wouldn't be the case this time.

“All the applications” don’t matter. Once you have the OS, Apple’s first party applications, Microsoft, Adobe, and a few Mac only niche apps, you cover most of your bases.

During the 680x0 to PPC transition, almost all of the applications that needed performance were already ported. The same was true for the x86 transition.

But more than likely, this time it will be the low end that would go ARM to optimize for battery life and the high end would stay x86.

Also the difference this time is that the two largest commercial vendors - Adobe and Microsoft already have ARM versions and Apple has Catalyst to make porting iPad apps to MacOS easier.

Also, during the last two translations, there was a lot more assembly code optimizations in third party apps than now. Especially going from 68K to PPC.

And sadly, there are a lot more Electron apps out there that would be easy to port.

Microsoft has struggled to get Windows ARM laptops because they also thought the performance/power ratio made it worth it.

> “All the applications” don’t matter.

Getting the most popular applications is the easy part, the hard part is the long tail. Only 1% of people may use a particular obscure application, but when there are a thousand such applications, the average person uses ten of them.

You also have to deal with a period of people wanting to run the applications they already own, not the newer version they have to pay to upgrade to or which isn't the same version the rest of their family or company uses on their existing hardware.

There are a lot of people who need nothing more than a web browser, but that's the target market for Chromebooks rather than MacBooks.

That 1% of applications is probably not performance critical and would work fine under emulation. But really, do you know the Mac scene? This isn’t Windows with thousands of line of business apps that have been running without upgrades for a couple of decades. Apple has already killed a lot of old apps when they dropped PPC compatibility and later 32 bit compatibility.

There are two existence proofs that Apple knows how to do this. They’ve done this twice and took customers with them both times. What are the Mac users who don’t like the transition going to do? Buy PCs and lose all compatibility with their apps?

The last thing that’s different this time is that Apple had a lot more to lose in 1994 when the Mac was all of their business and 2006 when the Mac was half of their business (the iPod was the other half). This time the Mac is only 10% of their business.

Also, many apps are going subscription. The upgrade would be “free”.

As far as performance. The most popular Mac has been the MacBook Air. The people buying those aren’t doing performance critical tasks using niche applications that won’t be ported.

> That 1% of applications is probably not performance critical and would work fine under emulation.

Each application having 1% of the users doesn't mean it's 1% when you add them all together. And they're all different applications. Why would you expect these to be less likely to be performance critical than any other?

Even for applications that aren't performance-critical, if the point is to save battery, emulation does the opposite.

> This isn’t Windows with thousands of line of business apps that have been running without upgrades for a couple of decades. Apple has already killed a lot of old apps when they dropped PPC compatibility and later 32 bit compatibility.

MacOS X 10.5 supported 64-bit Intel applications in 2007. That's more than a decade for old applications to accumulate. I doubt even most of the legacy Windows cruft is older than that anymore.

> There are two existence proofs that Apple knows how to do this. They’ve done this twice and took customers with them both times. What are the Mac users who don’t like the transition going to do? Buy PCs and lose all compatibility with their apps?

When they did it before, the new processors were a lot faster. There was a large benefit to offset the transition cost.

Existing Mac users don't immediately have to buy a PC, all they have to do is not buy a new Mac.

> The last thing that’s different this time is that Apple had a lot more to lose in 1994 when the Mac was all of their business and 2006 when the Mac was half of their business (the iPod was the other half). This time the Mac is only 10% of their business.

If the argument is can Apple stop making x86 Macs without going out of business, sure they can. If the argument is that Mac users should want to buy the first ARM model that comes out instead of holding onto their existing MacBook, not so much. It would have to be a real upgrade from what they already have, not just something equivalent but worse because it has to emulate some of their applications.

> As far as performance. The most popular Mac has been the MacBook Air. The people buying those aren’t doing performance critical tasks using niche applications that won’t be ported.

The MacBook Air has a Core i5. It's not exactly slow.

I'm also not sure what you mean by performance critical. Maybe they're not doing 3D rendering where you care quite a lot about the difference between three hours and five, but when people upgrade their hardware they still want it to go from responding in 500ms to 300ms instead of the other way around. And in that sense basically everything is performance critical.

Care to give examples of “performance” critical Mac applications that people are using and are not likely to get ported relatively quickly?

Even for applications that aren't performance-critical, if the point is to save battery, emulation does the opposite.

What are these specialized applications? Audio, photo and video apps are historically the first to get ported. Adobe and Microsoft have historically taken a year or two.

Active Mac only developers like BareBones have have been the first to port their apps.

When they did it before, the new processors were a lot faster. There was a large benefit to offset the transition cost.

For reference 68K applications ran slower on the 6100/60 and 7100/66 than my 68030-40Mhz (accelerated) LCII. Out of the first generation PPC based Macs, only the 8100/80 was always faster than my 68030 Mac. My Mac was about half the speed of the high end 68040-40Mhz Quadras. In this case it’s the battery benefit.

And back in the 10.5 days, most apps were still 32 bit and using the Carbon APIs.

If the argument is that Mac users should want to buy the first ARM model that comes out instead of holding onto their existing MacBook, not so much. It would have to be a real upgrade from what they already have, not just something equivalent but worse because it has to emulate

And this is the same thing that happened the last two times. Users waited until the apps they cared about the most were ported. Especially for the PPC transition, it wasn’t until both the second generation high end 604s that PPC based Macs could run emulated programs faster. Heck the second generation lowend 603 based PPC Macs were slower emulating 68K Software than 601 based Macs.

I'm also not sure what you mean by performance critical. Maybe they're not doing 3D rendering where you care quite a lot about the difference between three hours and five, but when people upgrade their hardware they still want it to go from responding in 500ms to 300ms instead of the other way around. And in that sense basically everything is performance critical.

I can’t speak to the architecture of the PPC emulator for the x86 based Macs. But in the case of 68K programs that spent a lot of time calling OS routines, they would get a significant speed boost because they were calling native code - at the time emulated programs saw a significant speed boost by calling native QuickDraw routines.

The other advantage this time is that Apple is designing its own chips. It can make architectural decisions in the processor design to make emulation better.

Also, people are already using Electron apps, they couldn’t care too much about performance.

For a contemporary report of emulation speed of PPC Macs.

https://tidbits.com/1994/02/21/powerpc-reports-positive/

(reports were that PPC ran emulation at the speed of a low end 68040 Quadra without an FPU)

The most likely possibility there is that Apple will release the system with some form of dynamic binary translation, much like they did for the PPC/x86 transition. It's also possible that Apple might make some customizations to their ARM core to accelerate the translation process, or even to allow some x86 code to be run directly.

Reply on news.ycombinator.com