Solved! ARM Apple High-End CPU - Intel replacement

Page 21 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Richie Rich

Senior member
Jul 28, 2019
470
229
76
There is a first rumor about Intel replacement in Apple products:
  • ARM based high-end CPU
  • 8 cores, no SMT
  • IPC +30% over Cortex A77
  • desktop performance (Core i7/Ryzen R7) with much lower power consumption
  • introduction with new gen MacBook Air in mid 2020 (considering also MacBook PRO and iMac)
  • massive AI accelerator

Source Coreteks:
 
  • Like
Reactions: vspalanki
Solution
What an understatement :D And it looks like it doesn't want to die. Yet.


Yes, A13 is competitive against Intel chips but the emulation tax is about 2x. So given that A13 ~= Intel, for emulated x86 programs you'd get half the speed of an equivalent x86 machine. This is one of the reasons they haven't yet switched.

Another reason is that it would prevent the use of Windows on their machines, something some say is very important.

The level of ignorance in this thread would be shocking if it weren't depressing.
Let's state some basics:

(a) History. Apple has never let backward compatibility limit what they do. They are not Intel, they are not Windows. They don't sell perpetual compatibility as a feature. Christ, the big...

Andrei.

Senior member
Jan 26, 2015
316
386
136
Very dubious about that TFLOP number being FP32.
It is FP32, the smaller mobile variants reach 1TFLOP: https://images.anandtech.com/doci/15178/Snippet.png

I don't remember seeing that RockChip roadmap, but Natt was a rumoured codename for G77, and that chip should very much be G77.

HiSilicon will be jumping to A78.

IP is not tied to any process node - vendors can synthesise it in whatever process they want.
 

DrMrLordX

Lifer
Apr 27, 2000
21,629
10,841
136
First Cortex-A77 Geekbench scores are starting to appear in Geekbench: type 3341 (=0xD0D Cortex-A77 CPU ID) in the search window.

For instance a Samsung SM-G986N gets 925/3230. Frequency was about 2.8 GHz during the run.

That'd be, for single thread, about 20% above Cortex-A76. And (keeping in mind cross OS comparisons can be misleading) about the speed of Apple A11.

Not bad! My ROG Phone II (855+, overclocked) can't do any better than 739/2806, and that's with X-mode and the freezer trick. I'm guessing MT score in that device is probably power/thermal limited compared to the ST results.
 

Thala

Golden Member
Nov 12, 2014
1,355
653
136
The image only showed Adreno 640, not 680 in the 8cx - do we not have a concrete figure on this from a benchmark somewhere?

Qualcomm did claim about 2x Adreno 640 for the Adreno 680 and Microsoft claimed 2.3 TFlops for Adreno 685 in SQ1. Since Adreno 685 is unlikely to be slower than Adreno 680 the 2.3TFLop figure is indeed FP32.
Another indication is, that SQ1 has double the memory bandwidth than the mobile Snapdragon 855 - which can be accounted to GPU bandwidth requirements.
 
Last edited:

Nothingness

Platinum Member
Jul 3, 2013
2,410
745
136
How big are MacBook and IMac today?
No doubt they could make a better CPU than Core i7 but how much can it cost?
Volume is everything. Something like a server CPU?
Apple doesn't provide unit numbers anymore. In 20Q1 Mac revenues were $7B while iPad were $6B.

But don't forget they have a specific CPU just for iPad Pro which likely sells much less than other iPad. So even for "low" volume they do make dedicated SoC.
 

Doug S

Platinum Member
Feb 8, 2020
2,259
3,511
136
How big are MacBook and IMac today?
No doubt they could make a better CPU than Core i7 but how much can it cost?
Volume is everything. Something like a server CPU?


Apple doesn't need a new CPU, the one they are already making for the iPhone/iPad basically matches top end AMD/Intel desktop performance category in single thread per SPEC2006. When people say "oh Apple is targeting low power with its cores, no way can it compete with high power x86 designs" they are missing that Apple has only two big cores in the iPhone and AMD/Intel have over 10x as many in their high end CPUs. I don't know what Apple's max wattage per big core is but it is probably something like 4 watts. How many watts per core is the latest Threadripper with 64 cores and a 280 watt TDP? Pretty much the same, and even if it can reach 10 watts per core in turbo that's still a pretty small difference. Maybe Apple could squeeze a little more performance out of their cores in a "turbo mode" if they increased the voltage and power draw to the CPU cores, and ramped the clock up another 10 to 20% but that would just be icing on the cake - they don't need to do this to compete with the highest end x86.

Apple could easily leverage the 'X' version they make for the iPad every other year for their Mac line. It has 4 big cores, which is plenty for most of the Mac line, the only Macs they offer that have more than four cores and might be slower than next year's A14X would be the Mac Pro, iMac Pro and big screen Macbook Pro (which is offered with 6 or 8 cores) They would need to add some blocks to the SoC for things Macs have that iPads don't like HDMI/DP, TB, SATA, etc. but that's only a few sq mm of die size that would be "wasted" on iPads. Not sure how Apple's GPU compares to Intel's integrated GPU but I'm guessing it should be competitive.

They could handle the bigger Macs using the same A14X (or more likely a follow-on A15X or A16X since they aren't going to go ARM across the whole Mac line in a single year - they need to give developers time to port everything before they switch the "Pro" line of Macs) by making it able to act as a "chiplet" ala AMD to build bigger CPUs. Put two A*X together and you have an 8 core CPU (with double the memory channels) for the high end Macbook Pro. Put four together for the iMac Pro. Put eight together for a 32 core monster Mac Pro tower with an insane number of memory channels as the final step to complete the Mac transition to ARM.

Apple simply doesn't need to design a different core, or even a different SoC to go to ARM on the Mac. There were a few milestones on the roadmap they would have wanted to achieve:

1) match x86 performance so ARM native apps would be no slower than x86 native apps
2) retire all support for 32 bit code to avoid doubling the number of libraries they need to support and simplify x86 to ARM translation that will be necessary until developers port their apps
3) retire old APIs to avoiding supporting libraries/APIs that are used by few apps

Those three are checked off:

1) performance levels of their SoC CPU cores nearly match Intel's best in single thread, and since Apple is increasing performance faster than Intel (and TSMC is executing process improvements faster than Intel as well) it is only a matter of time before Apple's single thread performance is better than Intel's best (especially if they can squeeze additional performance out of a "turbo mode" when they have a bit higher per core power budget and active cooling available)

2) & 3) have been addressed by the latest macOS update, which drop support for 32 bit code and obsolete libraries and APIs.

I don't think there are any more pieces that need to be in place to make this happen, so I wouldn't be at all surprised to see this year's 5nm A14X in a couple lower end Macs like the Mini and non-Pro Macbook. Maybe those would be available only to developers at first so they could begin the porting process to produce x64/ARM64 fat binaries, and reach consumers the following year. The big ones using the "chiplets" would follow a year or two later since that would take more testing, and Apple would want most of the important software already available for ARM64 so they need do little or no x86 emulation.
 

Nothingness

Platinum Member
Jul 3, 2013
2,410
745
136
Great post! I agree with most of what you wrote except for a detail:

I don't think there are any more pieces that need to be in place to make this happen
You forgot a point: Windows support for Mac machines. Some users seem to really need it. I wonder what proportion they represent, but I don't think Apple can afford to ignore them. I think this would need a cooperation between Apple and Microsoft, something that could be possible these days I guess.
 

avAT

Junior Member
Feb 16, 2015
24
10
81
You forgot a point: Windows support for Mac machines. Some users seem to really need it. I wonder what proportion they represent, but I don't think Apple can afford to ignore them. I think this would need a cooperation between Apple and Microsoft, something that could be possible these days I guess.

While I believe they would put every effort into addressing this if they identified ways that they could, including cooperating with MS as you suggest, I'll never believe they would hold back plans over this.

It's not an accident that they aren't saddled with *their own* legacy backward compatibility. They certainly aren't interested in being saddled with someone else's.
 

Doug S

Platinum Member
Feb 8, 2020
2,259
3,511
136
Great post! I agree with most of what you wrote except for a detail:


You forgot a point: Windows support for Mac machines. Some users seem to really need it. I wonder what proportion they represent, but I don't think Apple can afford to ignore them. I think this would need a cooperation between Apple and Microsoft, something that could be possible these days I guess.


Microsoft already supports Windows on ARM, which includes support for running x86 code on ARM. That's not going to perform as well, but so long as you aren't running some pretty CPU intensive Windows programs it shouldn't be a problem. People who are running CPU intensive Windows programs on their Mac probably have one of the Pro line of Macs which would go ARM later. Maybe ARM Macs give Microsoft a little help trying to push Windows on ARM and it encourages more Windows devs to release ARM versions of their applications by the time we see Macbook Pro go ARM. Yeah I'm not sure I buy that either but the full transition would take several years so people who want to stick with x86 because of Windows could do so even after Apple starts rolling out ARM Macs.

I agree that people who run Windows on Macs are probably the biggest issue for a Mac transition to ARM, but I don't believe Apple would let that stand in their way if they had everything in place on the macOS side.
 
  • Like
Reactions: Etain05

soresu

Platinum Member
Dec 19, 2014
2,662
1,862
136
Amusingly it is ARM64 getting the first 10 bit SIMD optimisations for the dav1d av1 decoder project, courtesy of a little Netflix sponsorship now that they are pushing out AV1 video streams.

No benchmarks as yet, but there are already 5 optimisations merged, with at least 1 more to follow soon, possibly even before the impending v0.6 release.

We will probably see a comprehensive set of benchmarks following the v0.6 release so we won't have to wait too long.
 
  • Like
Reactions: coercitiv

Doug S

Platinum Member
Feb 8, 2020
2,259
3,511
136
The biggest hurdle for Windows on Arm Mac is graphics and the GPU choice Apple will go with. We might have some surprises here - I don't know which way they'll go, I have doubts they'll write Windows drivers for their own GPU.

That's a good point, I hadn't considered that. Perhaps the lower end Macs like the Mini and non-Pro laptops will be unable to boot directly into Windows (but would still work fine for Parallels since it uses a virtualized driver) so if you wanted to do that you'd need a higher end Mac with a discrete GPU.
 

soresu

Platinum Member
Dec 19, 2014
2,662
1,862
136
Dolphin has been ported to Windows on ARM and it looks like it was easy; it already was running on AArch64 Android so that made it easier than porting from scratch, but that still looks a pretty nice achievement.
Yeah, the ARM64 backend for Dolphin has been in development for years now, though they do admit it still has some ways to go before it catches up to the x86 backend in optimisation levels.

I'm more interested in the emulators previously announced but as yet far from done - like DobieStation (PS2), Mikage (3DS), Corgi3DS, Citra Android (3DS).

It should be a given that the Switch emulator yuzu would get an Android port, but I'm not sure what other blocks exist for that beyond the CPU ISA.

Other well developed emulators like RPCS3 and Xenia have stated they will not pursue an ARM/Android port until they have it working reasonably well on x86 with a lot of games.

Who knows, with Citra getting an Android/ARM64 port, we may even get a Cemu port too.
 

soresu

Platinum Member
Dec 19, 2014
2,662
1,862
136
The biggest hurdle for Windows on Arm Mac is graphics and the GPU choice Apple will go with. We might have some surprises here - I don't know which way they'll go, I have doubts they'll write Windows drivers for their own GPU.
So far they have only used Img Tech derivative IP and AMD in recent years - if this persists I can't see a problem.

Though it depends just how derivative the Img Tech stuff is - I'm not sure if their new agreement is because they also want the new cores due to a predicted shortfall in their future custom designs, very likely they may have their eye on Img Tech's Wizard/Caustic Ray acceleration uArch.

To be honest I'm pretty confused why Apple didnt simply buy Imagination Tech years ago, it's not like their gfx IP is nearly as widely used as it was back when they first started using for Ax, so they probably would escape anti monopoly claims.
 

awesomedeluxe

Member
Feb 12, 2020
69
23
41
I had an interesting idea I need someone to shoot down for me. I only have an enthusiast's education in APU architecture, so please bear with me.

Let's say things go great at TSMC and yields are just absolutely fantastic at 5nm. Apple has their theoretical A14XXX ready to go, it's heckin' sexy, and macOS and all Apple software run swimmingly on it.

AMD is prepped to release a really promising all-TSMC-5nm APU later that year, and Apple has engineering samples of it. Could Apple call up AMD and say: "hey, we want you to make a custom part for us bridging your best low power APU to our A14X. This is going to be a BIG die, but yield is ok and we think it will work out. We're going to have all our applications run on the A14X, but we're attaching your APU for legacy support."

Is this kind of solution feasible? What would prevent it from working? If it could work, are there any components that could be shared between the A14X and AMD APU?
 

ksec

Senior member
Mar 5, 2010
420
117
116
How big are MacBook and IMac today?
No doubt they could make a better CPU than Core i7 but how much can it cost?
Volume is everything. Something like a server CPU?

I believe I have provided those number in this thread.

~18-20M. Judging from the revenue it would be closer to 18M.

Roughly 20% are desktop, an official figure given out by Phill. That is roughly 3.6M Desktop Mac. And vast majority of them are iMac and Mac mini. Mac Pro represent a rounding error in the total.

Within these Macs, its CPU ranges from 25W to 250W.
 

avAT

Junior Member
Feb 16, 2015
24
10
81
Is this kind of solution feasible? What would prevent it from working? If it could work, are there any components that could be shared between the A14X and AMD APU?

I also don't have the knowledge to understand the feasibility, but I'll point out that AMD was basically working on something like this a few years ago as "Skybridge" and later dropped it.

Edit: On second glance, apparently I don't have the knowledge to understand that "Skybridge" seems to have been something else entirely. My bad.
 
Last edited:

Thala

Golden Member
Nov 12, 2014
1,355
653
136
Dolphin has been ported to Windows on ARM and it looks like it was easy; it already was running on AArch64 Android so that made it easier than porting from scratch, but that still looks a pretty nice achievement.

Dolphin is a special case compared to more standard software as it relies on JIT. The suprising thing was how easy it was to rip-out the x86 JIT engine and replace it with the ARM64 JIT engine from the Android build - it was literally just replacing a few files and then press the compile button.
How do i know? Because i already made an Windows ARM64 build of Dolphin back in November. I had bigger issues with QT (which is required by Dolphin) than with Dolphin itself.
 
  • Like
Reactions: Nothingness

DisEnchantment

Golden Member
Mar 3, 2017
1,602
5,788
136
Dolphin is a special case compared to more standard software as it relies on JIT. The suprising thing was how easy it was to rip-out the x86 JIT engine and replace it with the ARM64 JIT engine from the Android build - it was literally just replacing a few files and then press the compile button.
How do i know? Because i already made an Windows ARM64 build of Dolphin back in November. I had bigger issues with QT (which is required by Dolphin) than with Dolphin itself.
Qt is by design cross platform. We have our CI/CD delivering Qt based components for amd64 and arm64v8 Xavier based targets and it is fairly trivial.
You can build it from source as well.
 

DisEnchantment

Golden Member
Mar 3, 2017
1,602
5,788
136
Other thing I want to add what I notice in my own team :oops:
Even though I use all Intel at work on Windows and Linux, my devs use Macs. They develop code but they compile it on the network infrastructure VMs. Our company allows client machines to be Mac or Laptops.
They use Mac for they same reason they use iPhone. So they don't care intel or arm. They want Apple.
They just need VS Code and push everything to remote. Trigger build and that's it, wait for the job to complete and schedule tests.

I am starting to notice lately similar thing around our supplier offices.
In this regard Apple already is winning.
 
  • Like
Reactions: coercitiv

Thala

Golden Member
Nov 12, 2014
1,355
653
136
Qt is by design cross platform. We have our CI/CD delivering Qt based components for amd64 and arm64v8 Xavier based targets and it is fairly trivial.
You can build it from source as well.

Targetting different platforms was not the issue, the issue was cross compiling. When compiling ARM64 targets on an Windows x64 host most of the QT build tools where also build for ARM64 and thus not beeing able to run on the host. And yes - i had to build it from source.
When not cross-compiling like when compiling on ARM64 Linux host tagetting ARM64 Linux - i had no issues.
 
Last edited:

Nothingness

Platinum Member
Jul 3, 2013
2,410
745
136
Targetting different platforms was not the issue, the issue was cross compiling. When compiling ARM64 targets on an Windows x64 host most of the QT build tools where also build for ARM64 and thus not beeing able to run on the host. And yes - i had to build it from source.
When not cross-compiling like when compiling on ARM64 Linux host tagetting ARM64 Linux - i had no issues.
Couldn't you build Dolphin/Qt natively on your WoA machine? Lack of tools? Lack of memory? Not powerful enough?

As far as I am concerned this little sentence in the Dolphin blog entry is enough to disqualify the device at the moment:

And the first device to launch with it (though technically a lightly customized variant), the Microsoft Surface Pro X, is Windows on ARM exclusive device. It is locked down tight; months of reverse engineering have only barely begun to see progress.

I don't care about Windows, I want to run Linux natively on the machine.

I wonder if Samsung Book S will be better (though it seems limited to 8 GB RAM / 256 GB SSD which is too small for me).