Apple Expected to Announce Arm-Based Mac Plans at WWDC, Transition Away From Intel to Begin in 2021

[Bustermd]

Interesting. All Apple computer designs with CPUs from any company but Intel were commercial failures. We'll see if they can change this pattern.

In 1997, when Steve Jobs returned to Apple 36.6% of US households had a personal computer. By 2010 77% of US households had a personal computer. Apple's transition to Intel happened in the middle of that home computer "boom" which also corresponded to the rise of personal media players and smartphones, which apple frankly dominated so more people bought in to the Apple ecosystem. Between 1990-1997, in the post Apple II/Commodore 64 era, most computer users went PC because of the programs needed for work, or for gaming, whereas now the software people need for productivity and entertainment have become significantly more OS-agnostic (web based, etc). Also much more people are users of Apple products because of iphone, ipad, and apple watch which are dominant products in their respective categories. The vast majority of those users could care less about the processor architecture: all they care about is going to the apple store to get a cool device that they can then get service for very easily at the same apple store.

So comparing new ARM macs to previous generations of macs that were in every respect niche products for enthusiasts is not exactly an, ahem, Apples to Apples comparison {insert rimshot here}

 

[Atlantico]

I designed the x86-64 integer instructions, but a future ARM 128-bit wouldn't have to make the same decisions I made.

It is so bizarre to claim *you* designed something, and then use the wrong term for it. You also don't display more than a peripheral knowledge of CPU design, and consistently fall back on pedestrian vocabulary and wrong technical terms.

Amazon Graviton 2 is a server CPU that have 64 ARM cores on it.

You are the fanboyism yourself when talking about Intel. Nobody talk like that for Intel 20 years ago when DEC and Power was still in the PC market.
There's nothing magic about x86 and ARM can do everything x86 can -- since ARM could emulate x86. If emulated performance is times faster than native then who care about native or not?

ARM is not bind to low power device. Graviton 2 is already faster than the fastest Xeon in server market.

Intel is slowing down a lot these years and for past 10 years they only increased IPC by 15%.
Today a A13 have 80% more IPC than a Skylake, that's a shame for Intel.
AMD is doing well for the past 3 years, but not as good as Apple's ARM was for the same time.

And since Apple definitely knows how Intel and AMD's next few years secret products, they are making this decision with much more knowledge than us.

Nice strawman you knocked down there.

You clearly didn't read my post, or just replied without understanding it before posting a knee-jerk response.

You just re-iterated what I wrote. Indeed there is nothing "magic" about x86 and ARM can do everything x86 can... with two important caveats.

1. ARM can't run x86 or amd64 code natively
2. ARM becomes hot and hungry when scaled up, like the performance CPUs from Intel and AMD.

To turn your example around, there's nothing "magic" about ARM. You want performance that can keep up with Intel and AMD, you pay in power, heat and cooling. There's no free lunch in electrical engineering.

 

[cmaier]

It is so bizarre to claim *you* designed something, and then use the wrong term for it. You also don't display more than a peripheral knowledge of CPU design, and consistently fall back on pedestrian vocabulary and wrong technical terms.

Sigh. Would you prefer I call it AMD64?

Here's some of my "peripheral knowledge" below. The JSSC paper mentions that I worked at AMD at the time that paper was published. I also worked at Exponential Technology (where I designed the x704 floating point unit and the floating point unit on the follow-up chip), Sun (where I designed the out-of-order hardware for Ultrasparc V), and AMD (where I designed parts of K6-II, K6-III (and the "plus" versions of those), Athlon 64, Opteron, and several other chips. Prior to that I designed the cache controller and static RAMs for the F-RISC/G processor at RPI.

High Speed Microprocessor Cache Memory Hierarchies for Yield-Limited Technologies

https://d1wqtxts1xzle7.cloudfront.net/50090229/43.74373620161103-27656-10p6qk2.pdf?1478225056=&response-content-disposition=inline%3B+filename%3DAccurate_high-speed_performance_predicti.pdf&Expires=1591830725&Signature=cCS5Uv~BOS-2oe39WSl69tuSWuLOFzOLf6cQHdfFpMZX6Wau~gMPvw9~8DpAHPZnaEpp59kvf63EKh0erwSIThIe3cSwdKxejh03JMj7rqwLYPVFv5oFoK2Sec5oE91~rsTYzpuaXXDsVKYL8~sdgWUXg72qGyOtB~AHkI1btDe6HYOmvDaD9LHZccDOqOzHXQe7qyq2aKN3UwZD8XdK4AhdRweQ5-yWBKPLL4k526pRRsmyODYqs5t7Qrq5qWXKhhzbpjuy8yfSthdrHHsF6ZTh1aVkx-T00aC7QHbTCPHhi~j~AYpiTbDlz6Crp4WGfdDh9DxRNp1-EhHA57x4iQ__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA

https://d1wqtxts1xzle7.cloudfront.net/50090222/iciss.1996.55242820161103-6850-1ehihke.pdf?1478225053=&response-content-disposition=inline%3B+filename%3DEmbedded_at-speed_testing_schemes_with_l.pdf&Expires=1591830742&Signature=PoyKe4j9qVzdHQCi3v~3Ztx0BWBigAeF2unGuA2vbj4KpCoTfhtgHZ00U5i5HVueOGVnUV8vUZNlwTmyLAtrDJp2~2T4lgA4ItqFlBklrZIy7ISaYQFlP98KHNAKjCZD~bUtV~BvOw2TtUsx0uGxdx6xb7tmtWdQsQDtogWLIxSjON5nAgw-ST7xxOsrWSc7ZkoQCazmJJERWABZD3ubL9He83K8U7a~cZ053CvD3k50ZSwQzJDRZizgdLEkOs9RZqAlUsR90TpcGcxATRYcE0oKi4X-UTbTn7TIDeHQDSiTxZFsxmS0b~fbEBICBY04bgs1ds42fXcQdXiWc-S~2g__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA

https://www.ecse.rpi.edu/frisc/publications&patents/Carlough00845192.pdf

A 533-MHz BiCMOS superscalar RISC microprocessor

This 533-MHz BiCMOS very large scale integration (VLSI) implementation of the PowerPC architecture contains three pipelines and a large on-chip secondary cache to achieve a peak performance of 1600 MIPS. The 15 mm/spl times/10 mm die contains 2.7 M transistors (2M CMOS and 0.7 M bipolar) and...

ieeexplore.ieee.org

 

[WestonHarvey1]

I think we will see a Mac Mini special dev edition with ARM processor this year. It's a really big change and the only way to make it happen is to give developers a test device. Selling a laptop / iMac as test device is non-sense (all-in-one is not good for testing purposes), Mac Pro is too expensive. So Mac Mini is the choice IMO.

Why? Apple did no such thing with the switch from PPC to Intel. Their first Intel products were the MacBook Pro and iMac. They didn't need a "test device".

 

[MikeZTM]

If ARM happens it'll be irrelevant. I can edit my photos on a iPad Pro and get a x86 based machine with linux for work.

ARM does nothing with any application your are running today.
All current software can be port to ARM with little to no effort since Catalina already dropped outdated 32bit support. It just need some time from those big names since their test department have to work on it for months before shipping a new version.

2-3 years will be enough for almost all your current workflow to natively work on a ARM Mac.
An end user should never notice any difference when using a ARM Mac except the performance.
[automerge]1591828288[/automerge]

Why? Apple did no such thing with the switch from PPC to Intel. Their first Intel products were the MacBook Pro and iMac. They didn't need a "test device".

They did have a test device.
That was a PowerMac case with Pentium 4 inside. It was only ship to developers and was recalled when Intel Mac started shipping.

I bet this time they will do something similar. Like a mac mini with A13/A12z inside for selected developers.
or just allow registered developer to run macOS on a iPad Pro for test with a build-in kill switch.
[automerge]1591828427[/automerge]

It is so bizarre to claim *you* designed something, and then use the wrong term for it. You also don't display more than a peripheral knowledge of CPU design, and consistently fall back on pedestrian vocabulary and wrong technical terms.



Nice strawman you knocked down there.

You clearly didn't read my post, or just replied without understanding it before posting a knee-jerk response.

You just re-iterated what I wrote. Indeed there is nothing "magic" about x86 and ARM can do everything x86 can... with two important caveats.

1. ARM can't run x86 or amd64 code natively
2. ARM becomes hot and hungry when scaled up, like the performance CPUs from Intel and AMD.

To turn your example around, there's nothing "magic" about ARM. You want performance that can keep up with Intel and AMD, you pay in power, heat and cooling. There's no free lunch in electrical engineering.

That 64core Graviton2 running at 110W isn't anywhere power hungry as a Intel Xeon.
And it have 64 lanes of PCIe 4.0 connection, double the IO ability of the best Xeon.

Yet a single 28 Core Xeon burning 280W.
Well at least Amazon can build a CPU using TSMC n7 instead of Intel 14nm+++.

Remember how 22nm Atom beat those 40/32nm mobile CPUs in tablets? Even ARM's architecture is s**t this fab advantage is still huge.

 

[WestonHarvey1]

They did have a test device.
That was a PowerMac case with Pentium 4 inside. It was only ship to developers and was recalled when Intel Mac started shipping.

I remember this. I feel foolish now.

 

[Unregistered 4U]

Macs have been under-powered for how long?

For about as long as Intel has been slipping

Additionally, future apps will be "Fat" and include both x86 and ARM code, just like apple did in the PPC/x86 transition days.

No, if you’re downloading from the app store, it will be as it is now with iOS, the code that gets downloaded is tailored for your device. If you’re downloading from the internet, you’ll likely choose between Intel and ARM.

Translating an ARM iOS App to Intel macOS Using Bitcode

www.highcaffeinecontent.com

If Apple goes all in on ARM why would anyone want to purchase any Intel based Macs today ?

I would agree. Don’t buy an Intel Mac today, WAIT until the 22nd, see what reality is, THEN make your decision. If you need a Mac that supports Intel features that aren’t available, then buy away!

Apple will probably put ARM processors in the low end Macs for a while. They will wait to see how that plays out.

Apple already knows how it’s going to play out. They don’t have to wait and see. They will likely do what they did with he last transition where there will be no products shipping with Intel processors within 12 months after the first one ships.

I wonder if third parties will rewrite all their drivers, I'm thinking about my scanner, printer, Wacom tablet, audio interface, will they become obsolete ?

It depends on if they want to keep your business/their market share. Something like this is always an opening for an upstart competitor. The scanner company could come out with a inferior product BUT if customers need ARM compatibility and THAT is the only scanner that offers it, then your current scanner vendor loses out on the sale. I would guess that, unless your scanner company has financial concerns, they’ll provide a driver. Developing a driver now is always cheaper than having someone erode your market share later.

 

[aednichols]

Random guessing here, but iPad Pro makes sense as a dev transition kit. Has a keyboard, touch, trackpad, A12X/Z chip and perhaps there will be a special image of macOS for it. It's also portable. A G5 Tower made sense in 2005, but my guess is they'd want this to be portable.

I can think of one big reason why not. Inevitably photos of this device would come to circulate on the ‘net with inadequate context, setting false expectations with non-technical users. If Apple intends to keep iPad/iPadOS and Mac/macOS separate platforms, they should remain crystal clear in their messaging.

 

[djjeff]

2-3 years will be enough for almost all your current workflow to natively work on a ARM Mac. An end user should never notice any difference when using a ARM Mac except the performance.

The question is: How much of his workflow will be natively ported to ARM? If it's not 100% then the question becomes will the emulation (I assume Apple will provide emulation) outweigh any negatives associated with the change?

 

[MikeZTM]

The question is: How much of his workflow will be natively ported to ARM? If it's not 100% then the question becomes will the emulation (I assume Apple will provide emulation) outweigh any negatives associated with the change?

Since Microsoft is also doing ARM transition, Office shouldn't be a problem here and same goes for Adobe.
And a lot open source/Java based software already runs on a Pi today. I can guess more than 80% of regular people's workflow on a Mac will be natively supported on a ARM Mac within a year.

For emulation, currently Windows 10 already support emulating x86 software. It is about 50% performance reduction compared to native ARM64 code. Since Windows have a much wilder software environment I guess Apple's emulation should be at least same as this number.

Take A13@2.6GHz single core equals Skylake@5.0GHz single core performance. 50% reduction gives you about 2.5GHz Intel performance--which is current Intel MacBook Pro 16's sustained frequency.

If we have 8 big cores in a ARM MacBook that is about the same performance of a top tier MacBook Pro today.
Sounds familiar to me as I was using first gen MacBook and runs a lot of PowerPC software when Apple claim the emulation is about same performance of last gen PowerBook G4. In real world it wasn't as smooth as it advertised but definitely not slow enough for regular people to notice the difference compare to last gen native PowerPC Mac.

I played Warcraft 3 on my MacBook without any issue when Intel patch wasn't out yet.

 

[dgdosen]

1. ARM can't run x86 or amd64 code natively
2. ARM becomes hot and hungry when scaled up, like the performance CPUs from Intel and AMD.

To turn your example around, there's nothing "magic" about ARM. You want performance that can keep up with Intel and AMD, you pay in power, heat and cooling. There's no free lunch in electrical engineering.

Thanks for that perspective - especially on #2.

I think for #1, Apple will just make sure to "intermediate representation" all the things, and hopefully allow 3rd parties to ship IR outside the walls of the app store.

For #2 - How do you see Apple vs Intel vs AMD shaking out? I have to think Apple wouldn't be touting all ARM if they can't prove they're ahead of Intel/AMD, otherwise customers will walk, right?

 

[djjeff]

Since Microsoft is also doing ARM transition, Office shouldn't be a problem here and same goes for Adobe. And a lot open source/Java based software already runs on a Pi today. I can guess more than 80% of regular people's workflow on a Mac will be natively supported on a ARM Mac within a year.

Microsoft is transitioning away from x64 to ARM? Or are you referring to their hardware products?

As for the 80% number that may be the case for regular users. What about those who fall outside of that definition? What about the other 20%?

Take A13@2.6GHz single core equals Skylake@5.0GHz single core performance. 50% reduction gives you about 2.5GHz Intel performance--which is current Intel MacBook Pro 16's sustained frequency.

I do not recognize such a comparison because this example is a hypothetical. After having read all the posts in this thread I am surprised at the optimism given to an Apple ARM processor implementation. The performance of such a processor seems unrealistically high.
[automerge]1591838665[/automerge]

For #2 - How do you see Apple vs Intel vs AMD shaking out? I have to think Apple wouldn't be touting all ARM if they can't prove they're ahead of Intel/AMD, otherwise customers will walk, right?

I'm certain Apple isn't making this change on a whim. I would be shocked if Apple hasn't put a lot of thought, engineering, testing, etc. into this change. It would be foolish to think otherwise.

OTOH I do not think the ARM specification and Apple's implementation of it are going to significantly outperform x64. IMO it would be equally foolish to think Apple's chip designers are significantly more capable in processor design that they could produce processors which are so ahead of x64 that they negate any downsides.

The above is not to say they can't produce a competitive or even faster processor. But I can't imagine it is so phenomenally better than the competition. I fully expect, assuming this rumors is true, Apple to provide benchmarks illustrating the performance of a Macintosh ARM processor. However I've seen such benchmarks in the past (68K and PPC) and the benefits weren't universally true for all applications.

Even if an Apple ARM implementation is phenomenally better there's also the question of how long it can be sustained. The PPC was a good processor and competed well against x86. However it didn't have staying power and ultimately was replaced by x86 (at least wrt the Macintosh).

I am very much looking forward to an ARM based Macintosh. I assume Apple is doing this for reasons other than ultimate performance (that may be a positive side effect).

 

[Sydde]

Hate to be this guy, but could someone explain to me what an ARM processor is and how it differentiates from Intel processors? In what way(s) is this more advantageous for us?

ARM is a shared architecture, being developed by a company in Britain, with input from many users/manufacturers. Intel CPUs are made by Intel and AMD, with some input from their customers, but the designs are limited by the small number of sources (basically just 2).

Using the ARM specification, Apple designs custom SoCs for their devices, which are code-compatible with other ARM processors but tend to be loaded with additional features, like neural network logic (without which, FaceID would simply not exist) and dynamic logic arrays (FPGAs) that can selectively accelerate some workloads (possibly, facilitate emulating Intels).

So, Apple's custom SoCs may be designed with some unique performance enhancements that you will not find in an Intel processor, and the customization could, theoretically, offer better security than your generic Intel.

 

[MikeZTM]

Microsoft is transitioning away from x64 to ARM? Or are you referring to their hardware products?

As for the 80% number that may be the case for regular users. What about those who fall outside of that definition? What about the other 20%?


I do not recognize such a comparison because this example is a hypothetical. After having read all the posts in this thread I am surprised at the optimism given to an Apple ARM processor implementation. The performance of such a processor seems unrealistically high.
[automerge]1591838665[/automerge]

I'm certain Apple isn't making this change on a whim. I would be shocked if Apple hasn't put a lot of thought, engineering, testing, etc. into this change. It would be foolish to think otherwise.

OTOH I do not think the ARM specification and Apple's implementation of it are going to significantly outperform x64. IMO it would be equally foolish to think Apple's chip designers are significantly more capable in processor design that they could produce processors which are so ahead of x64 that they negate any downsides.

The above is not to say they can't produce a competitive or even faster processor. But I can't imagine it is so phenomenally better than the competition. I fully expect, assuming this rumors is true, Apple to provide benchmarks illustrating the performance of a Macintosh ARM processor. However I've seen such benchmarks in the past (68K and PPC) and the benefits weren't universally true for all applications.

Even if an Apple ARM implementation is phenomenally better there's also the question of how long it can be sustained. The PPC was a good processor and competed well against x86. However it didn't have staying power and ultimately was replaced by x86 (at least wrt the Macintosh).

I am very much looking forward to an ARM based Macintosh. I assume Apple is doing this for reasons other than ultimate performance (that may be a positive side effect).

It's not hypothetical. A13 numbers are based on SPEC2006 score from Anandtech. SPEC is not geekbench.
Believe it or not, it's a fact that A13 single core performance is almost reaching 9900k single core boost.

I do not think a A14 single core would be slower than a A13 today.

 

[Wilderness-1902]

For example, when we create a website for various browsers, which browser is the first target browser during development process. I think it was IE ten years ago, it should be Google Chrome for now. and developers will try to support other browsers. Developers always choose the browser, that has the largest market share, as the first target browser. The software quality on the target browser will generally better.

MacOS (x86) is not a first target OS for most of software developers. Bootcamp and emulators give MacOS users a chance to use some good software on Windows or Linux. MacOS(arm) will get rid of this chance. It is generally a bad idea.

 

[cmaier]

For example, when we create a website for various browsers, which browser is the first target browser during development process. I think it was IE ten years ago, it should be Google Chrome for now. and developers will try to support other browsers. Developers always choose the browser, that has the largest market share, as the first target browser. The software quality on the target browser will generally better.

MacOS (x86) is not a first target OS for most of software developers. Bootcamp and emulators give MacOS users a chance to use some good software on Windows or Linux. MacOS(arm) will get rid of this chance. It is generally a bad idea.

But ios is a first target Os for many more developers than Windows.

So now you can write code that runs on iphones all the way up to macs, and scales appropriately.

 

[Wilderness-1902]

But ios is a first target Os for many more developers than Windows.

So now you can write code that runs on iphones all the way up to macs, and scales appropriately.

iOS is still a consumer platform. MacOS is a full OS. Maybe you're a CPU expert. But "scale" is NOT easy for software developers from iOS to MacOS.

 

[cmaier]

iOS is still a consumer platform. MacOS is a full OS. Maybe you're a CPU expert. But "scale" is NOT easy for software developers from iOS to MacOS.

Didn’t say it’s easy. It’s possible. I have one such app I wrote myself that is used in my enterprise. (I used to have a dozen apps on the App Store, but that was years ago.)

 

[Sydde]

... Bootcamp and emulators give MacOS users a chance to use some good software on Windows or Linux....

A rather notable fraction of Linux is GPL/LGPL, so, if Apple goes full ARM, you will not lose all the Linux catalog. After all, the Linux kernel underlies Android. It might take some time for what you use to get ported, but it probably will.

 

[Wilderness-1902]

Didn’t say it’s easy. It’s possible. I have one such app I wrote myself that is used in my enterprise. (I used to have a dozen apps on the App Store, but that was years ago.)

"Easy" means costs and users experiences. I think it is easier to migrate software from Windows to MacOS.

There are a lot of iOS developers because MacOS uses x86 CPU. Developers from other platforms have a chance to try Xcode and migrate apps.

 

[MikeZTM]

"Easy" means costs and users experiences. I think it is easier to migrate software from Windows to MacOS.

There are a lot of iOS developers because MacOS uses x86 CPU. Developers from other platforms have a chance to try Xcode and migrate apps.

In fact it is much harder to port a Windows software to macOS than port a Windows x86 software to Windows arm64 if you are using Visual Studio for your development -- which most windows developers are using.
Your "think" is wrong from a software development prospective.

And why iOS developers care about what CPU they are using? They develop software for another device and as long as the cross compile toolchain works it does not matter if their development machine runs Intel or ARM or even IBM Power.

 

[rp2011]

Desktop and Laptop sales are still shrinking every single year. But even though Apple sells twice as many iPads than Macs, the category is still very profitable for Apple, and makes more from Macs than iPads while selling only half as many units.
I think if Apple can demonstrate better performance and battery life with ARM chips, it may be able garner market share even while the desktop and laptop market continues to shrink if it can get more people to choose Macs over Windows machines.
But honestly, for me, the excitement is the prospect of better iPad Pros. Going from 8 cores to 12 sounds pretty good. Having pro Mac apps on ARM, makes the inevitability of them going to the iPad Pro that much more inevitable. And I really do think the future of the computer is the iPad Pro form factor and not the clamshell or the the desktop.

 

[Wilderness-1902]

In fact it is much harder to port a Windows software to macOS than port a Windows x86 software to Windows arm64 if you are using Visual Studio for your development -- which most windows developers are using.
Your "think" is wrong from a software development prospective.

And why iOS developers care about what CPU they are using? They develop software for another device and as long as the cross compile toolchain works it does not matter if their development machine runs Intel or ARM or even IBM Power.

I was a Windows/WinCE/Java Developer 10 years ago. When I had a x86 mbp, I had a chance to play with Xcode and now I am a iOS developer. I think x86 was the opportune to bring more developers. I don't think a lot of developers work on iOS development only. In a mixed development environment, such as full-stack development, mac(x86) is a good choice.

In my experiences, Windows x86/ARM64, share a lot of major APIs, so migration has less pain. iOS and MacOS does not. For example, we can have the core logic wrapped in C and make it platform independent. But we still need to rewrite UI when migrating between iOS/MacOS or Window/MacOS. Considering Windows is a full OS and there are a lot of restricts on iOS. So it is easier for me to migrate apps from Window to MacOS.

I know Apple have tried to support UIKit APIs on MacOS. But it is still in an early stage.

 

[cmaier]

I was a Windows/WinCE/Java Developer 10 years ago. When I had a x86 mbp, I had a chance to play with Xcode and now I am a iOS developer. I think x86 was the opportune to bring more developers. I don't think a lot of developers work on iOS development only. In a mixed development environment, such as full-stack development, mac(x86) is a good choice.

In my experiences, Windows x86/ARM64, share a lot of major APIs, so migration has less pain. iOS and MacOS does not. Apple have tried to support Foundation APIs on MacOS. But it is still in an early stage.

Most of UIKit works on MacOS now. Took me about an hour to port a very extensive app (about two dozen viewcontrollers). Of course it takes much more time to make the mac app feel like a mac app.

 

[Wilderness-1902]

Most of UIKit works on MacOS now. Took me about an hour to port a very extensive app (about two dozen viewcontrollers). Of course it takes much more time to make the mac app feel like a mac app.

UIKit is designed for mobile OS. So it doesn't have the capability to present complex UI elements.