• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."

Solved! ARM Apple High-End CPU - Intel replacement

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

soresu

Golden Member
Dec 19, 2014
1,571
783
136
Well It is not Linus Tech Tips, and does not release video every day etc.

What is definitive, it is very intresting rumor or not a crazy rumor from Klingon.

Heeey, don't affiliate or compare me with Coreteks!

My news posting was based directly on Anandtech's coverage of ARM's TechCon 2019 keynote.

No speculation was used in the OP with the exception of the v9.0-A part, given only Matterhorn's codename was stated by ARM, no more.
 

scannall

Golden Member
Jan 1, 2012
1,751
1,177
136
My thing is, if x86 sucks as much as you guys say, then why is it so dominant? x86 has gone up against several competing ISAs over the years, and come out on top from both a price and performance perspective.

There must be more to it than just "x86 sucks."
Because of the installed base of software. And the most popular OS runs on x86. Not really counting Microsoft's Windows on ARM yet, as the app list is pretty short still. Basically it's what we're stuck with for the time being. And likely for quite a ways into the future.
 

Carfax83

Diamond Member
Nov 1, 2010
6,042
847
126
Doesn't really need as high of clock speeds when the IPC is so much higher.
I'm not a semiconductor industry professional or IT guy, but from everything I've read about Apple's Bionic CPUs and their IPC, it seems that they are designed to operate at a sweet spot which maximizes IPC. This doesn't however mean that IPC that they achieve at their sweet spot would be attainable at the much higher frequencies seen in desktop CPUs.

For instance, one common adjustment I've read that Apple would have to make, is to either decrease the size of their L1 cache, or increase the cycle latency. That's just one, but essentially, Apple would have to make adjustments and compromises to increase the frequency to be more competitive with Intel desktop CPUs, which would result in a loss of IPC.
 

Thala

Golden Member
Nov 12, 2014
1,135
446
136
So Firefox took years to move to x64 on Windows because of API differences from 32 bit Windows then?
There were 2 big issues for Firefox to tackle:

1) A 32 bit program does not necessarily compile for 64 bit. This is in many cases because sizeof(int) != sizeof(void*) under 64 bit but sizeof(int))==sizeof(void*) under 32 bit. You would not believe how many 32 bit programs actually assigning a pointer value to an int variable. Such constructs immediatly fail under 64 bit compilation.
Therefore if the code is only available for 32 bit (x86) i try to first compile it for 64bit (x64) and fixing all the associated issues until it runs on my development machine (x64) and then i just compile for ARM64...which typically immediatly works.

2) Some programs are using dynamic translations (like for instance some emulators, but in any case each web browser for their Javascript engine). This is a non-trivial change as you need to rewrite the whole dynamic code generation modules from scratch.
 
  • Like
Reactions: soresu

Carfax83

Diamond Member
Nov 1, 2010
6,042
847
126
Because of the installed base of software. And the most popular OS runs on x86. Not really counting Microsoft's Windows on ARM yet, as the app list is pretty short still. Basically it's what we're stuck with for the time being. And likely for quite a ways into the future.
You don't think that a theoretical competing architecture that could possibly blow away x86-64 from both a price and performance perspective would be enough of an incentive to start porting these apps over to a new ISA, or creating new apps from scratch?

Isn't that what Apple did when they switched over to x86? The problem though, is that the theoretical architecture that can smash x86-64 does not exist, and from what I've seen, there is no indication that ARM could potentially manifest in that manner.
 
  • Like
Reactions: Thunder 57

name99

Senior member
Sep 11, 2010
400
296
136
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 weeping and wailing THIS YEAR (every year there's a big weeping and wailing...) is about Catalina dropping all 32-bit compatibility.
Apple has switched from 68K to PPC to x86 (to ARM on iDevices). They have switched from 32 to 64-bits multiple times. Every one of those transitions was smooth. Most people never even noticed. Of course there is that very particular internet personality who is still whining five years later how some transition killed his cat and ate his dog... Do you want to base your analysis of the future on Mr Grumpy, or on the lived experience on most users?

(b) Why don't most users notice? Because
- most users only use Apple apps. I cannot stress how important this is. Apple apps cover most of what people want, and they are very good. And Apple apps will transition to ARM COMPLETELY when Apple transitions. Apple is not MS, randomly leaving bits and pieces of the OS to rot away and never recompiling them.

- most Apple developers are used to change. If they're not, they're bankrupt. Apple tells them years in advance to adopt some technologies and stop using others, and if they refuse to do so THEIR APPS STOP WORKING. (Which includes, as a side effect, that people stop paying for them...) If you ship a GL app today, you're an idiot. If you ship a Carbon app today, it won't work on Catalina. If you ship a PPC assembly app, well, good luck being part of you little community of three other fanatics living in the past. Apple developers have apps written in high level languages, not assembly. So they retarget by recompiling.

- Apple has long experience in how to allow their developers to easily create fat binaries that run on multiple architectures. They'll have a version of Xcode that does this as appropriate (probably announced at WWDC next year) and any developer that's not actually dead will be shipping fat binaries by the time the consumer ARM Macs ship.

- Apple is used to shipping emulators, JITs, and similar machinery that can handle old binaries. Apple doesn't have much interest in supporting this long-term. But they will provide such support for the first few years. People's old x86-64 apps will work (not as fast as before, but they will work) for a year or so, while people who rely on them find an alternative.

(c) Why is this all true for Apple but not Microsoft? Because, repeat after me kids, APPLE IS NOT MICROSOFT!
I'm not interested in arguing about the values of perpetual compatibility and caution vs perpetual change and risk taking. Both have their place, both attract different personalities. It's just a fact that MS is one, Apple is the other. One consequence is that when Apple makes a change like this, it goes all in. Once Apple has decided on ARM Macs, the entire line will be ARM Macs within a year. Within ~three years the old x86 Macs will stop getting new APIs. After ~five years they'll stop getting OS updates, after ~seven years they'll stop getting Security updates. Meanwhile MS still can't decide 20 years later whether it wants to fully support .NET and CLR or not. It remains wishy-washy about its ARM support.
This has consequences. It means that Apple developers are used to rebuilding every year, whereas many Wintel developers never even bother trying to compile for ARM. It means few Apple users are running code that was compiled more than a year ago --- because such code, even if it's still sorta compatible doesn't work well on the newest devices; and because the kinds of developers who don't update their code frequently don't make any money on Macs.

(d) This may come as a shock to you, but the number of people who actually give a damn about Windows running on their Macs is miniscule. Why would they? Everything they want exists in Mac form. Sure, if you hang out in certain places it sounds like this is a super-important issue --- just like if you hang out in certain places everyone will insist that gaming on Linux is like, totally, the economic foundation of the computer entertainment industry...

(e) For those people who absolutely insist on still running Windows on their Macs, here's another surprise: It's no longer 1995, and we have new technologies!
If you require x86+Windows in the modern world, the way you will get it is through a PC in a thumb drive that will communicate with the host Mac's virtualized IO and screen. Basically what Parallels does today, but with the x86 code running on a thumb PC and communicating via USB-C. Apple probably won't even do the work, they'll just let Parallels or VMWare write the code and drivers for both ends and sell the thumb PCs; all Apple will do is work with them if there are any particular technical issues that come up. Expect to see one or both of them demo-ing such a solution when Apple announces the ARM Macs to consumers.
NO-ONE is going to bother with some sort of hydra chip that either executes both ARM and x86 code, or even that puts an x86 core on the ARM SoC.


There is a constant thread going through the people who say Apple can't do this: they are people who haven't studied the history of Apple, and who don't use Apple products very much. They look at this from the point of view of how it would fall out if MS did this. But, what did I say, kids, APPLE IS NOT MS!
Apple USERS are not MS users -- different expectations, different software on their machines.
Apple DEVELOPERS are not MS developers -- used to change, used to supporting multiple OSs and ISAs.


As for why Apple would do this

(a) performance. Apple ALREADY matches the best performance Intel has in their "standard" cores. Look at the numbers. The phone cores do this under phone constraints (most significantly a current constraint). The iPad cores tend to run 5..10% higher performance partially because the current constraint is not so strict, partially because they have wider memory. Obviously the Mac cores would be at the very least the iPad cores, with that wider memory, and with even less severe current constraints.
Apple does this by IPC, not frequency, and if you insist that frequency matters, all you're showing is your ignorance. Intel built themselves a massive hole (that they now apparently can't get out of) because they obsessed over frequency too much (apparently learning NOTHING from how the same obsession failed with the P4).
The one place Apple still lags Intel in a measurable way, for some tasks, is code that can use wide vectors (ie AVX-512). Presumably Apple will soon (maybe even next year) have SVE which takes care of that.

(b) SMT. Another sure sign of the ignorant.
SMT is a DUD. It gives 25% extra performance (so your 4 cores have the throughput of five cores -- for some types of code) at the cost of enormous validation and security headaches.
There are ways to add SMT-like functionality that are much smarter than SMT (in particular forget the "symmetric" part, have fibers that are user-level controlled, not OS controlled, so they never cross protection boundaries) and I certainly hope that if ARM or Apple ever go down the "SMT-like" path, they do that, not Intel-style SMT.
But for now, the ARM/Apple "answer" to SMT is small cores. If you need extra throughput, use the small cores. An A12X (4 large, small cores) has the throughput of ~5 large cores --- same, effectively as SMT"s 25% boost. Different ways to solve the same problem of optionality --- how do I ship a system that maximizes for all of latency, throughput, AND power? SMT gives you some flexibility for the first two, big.little gives you that same flexibility but for all three.

(c) Control. Look at what Apple has done with control of their own SoC. Obviously continual performance improvements.
Much better security. (Including IO security.)
Continually adding features to GPU, plus adding NPU, plus now adding what's apparently for on-machine learning (AMX).
Other functionality we don't even really know yet (U1).

Against that, with Intel all they get is more of the same, year after year. Intel turnaround times are SO slow. Upgrades appear to have actually stopped. Security remains an on-going issue.

Sure Apple can try to deal with some of this through heroic interventions like adding the T1 then T2 chips to retrofit some security. But god, what a pain!
Look at things like how long Apple wanted to use LPDDR4 in Macs --- but couldn't because Intel. I'm sure at least part of the delay for the new Mac Pros was that Apple kept hoping (or being promised by Intel) that soon Intel would be shipping something with PCIe4. But no, still waiting on that.
 
Last edited:

naukkis

Senior member
Jun 5, 2002
399
249
116
I'm not a semiconductor industry professional or IT guy, but from everything I've read about Apple's Bionic CPUs and their IPC, it seems that they are designed to operate at a sweet spot which maximizes IPC. This doesn't however mean that IPC that they achieve at their sweet spot would be attainable at the much higher frequencies seen in desktop CPUs.

For instance, one common adjustment I've read that Apple would have to make, is to either decrease the size of their L1 cache, or increase the cycle latency. That's just one, but essentially, Apple would have to make adjustments and compromises to increase the frequency to be more competitive with Intel desktop CPUs, which would result in a loss of IPC.
They don't need to adjust anything to be competitive with Intel desktop CPU. You probably haven't red Anand's Iphone11 review where they are benchmarked both with spec2006. Specint2006 results are practically same for A13 in a phone than with Intel fastest desktop 9900K, and faster than Ryzen 3900X. Comparison isn't fair to A13, as they are comparing a phone to fastest desktop cpus. Put that A13 in desktop environment with more power and thermal headroom - or put that 9900K to phone to have fair cpu arch comparison - its pretty obvious which one will win and with a quite a margin.

And L1 cache size isn't a problem for clocks, it's a problem for 4K virtual page sizes to have VIVT cache accesses with 8-way associative cache which limits cache sizes to 32KB, Apple uses 16KB page sizes to be able to increase those L1 caches to 128K with same configuration. It's probably bigger problem for Intel to increase L1d to 48KB.
 

dark zero

Platinum Member
Jun 2, 2015
2,543
100
106
x86 is not sinking by any means now that AMD is finally throwing its weight around, though they've changed places with Intel in terms of stagnation, so until Intel comes back to form the market could tilt towards AMD some, hopefully Lisa doesn't let that go to her head (or the shareholders complacently ask for scaling back R&D so they can enjoy profits).

As for PowerPC, what bad experience do you speak of?

When Apple transitioned to x86, sure PowerPC CPU IPC was not stellar next to x86 - but that hardly warrants a label of bad experience.

A bad experience is more like Microsoft and nVidia with the first Xbox, or Sony with nVidia on PS3, or Nintendo with Switch TX1 security bug.

Basically anyone with nVidia....
And everyone forgets VIA with the chinese....
Meanwhile AMD AND Intel won't allow to Apple to get the crown so easily
 

soresu

Golden Member
Dec 19, 2014
1,571
783
136
This is a non-trivial change as you need to rewrite the whole dynamic code generation modules from scratch.
Yeah, I think parts of Spidermonkey are still lax on A64 optimisation - though bugzilla is often hard to make out on that score.

Having said that, their priorities seem to have strayed from Javascript for a while due to the rust/Servo/Quantum efforts to overhaul the rest of Firefox piece by piece.

Apparently the new Cranelift compiler in development may replace part of the Ionmonkey JIT as it matures, but that seems a ways off for now.
 

JoeRambo

Senior member
Jun 13, 2013
959
720
136
- Apple is used to shipping emulators, JITs, and similar machinery that can handle old binaries. Apple doesn't have much interest in supporting this long-term. But they will provide such support for the first few years. People's old x86-64 apps will work (not as fast as before, but they will work) for a year or so, while people who rely on them find an alternative.
Completely wrong, x86-64 emulation is not possible due to patents and copyrights and Intel will obviously enforce. Emulation is possible only for x86 code and even then I think there are some subtle limitations like AVX?
And Yeah, just like You just pointed out, Mac Catalina has exactly zero 32bit software to emulate.
 
  • Like
Reactions: ryan20fun

soresu

Golden Member
Dec 19, 2014
1,571
783
136
Completely wrong, x86-64 emulation is not possible due to patents and copyrights and Intel will obviously enforce.
SIMD ISA such as SSE and AVX aside, x64 itself (or more appropo AMD64) is the remit of AMD and not Intel.

x86-32 is all on Intel.
 

soresu

Golden Member
Dec 19, 2014
1,571
783
136
I would have thought the 32 bit x86 patents would have expired by now?
A bit over my head, though you would hope so.

However, the numerous extra SIMD ISA used with x64 is still likely to be under patent for quite some time - I wouldn't be surprised if Intel keep pushing new ISA extensions on top of what exists merely to retain control.
 

Steelbom

Senior member
Sep 1, 2009
338
7
81
So you don't have noticed that Apple A13 in a freakin phone is as powerful as fastest desktop x86 cpus. That's why whole discussion - Apple could emulate x86 with their desktop ARM cpu and have still almost comparable performance to fastest x86 cpus and with native ARM code have the fastest desktop machine easily. It's so much better than x86 cpus that question actually is why Apple haven't done the switch yet.
Yeah I'm not convinced. The A13 is very powerful however comparing it to Intel/AMD is not so easy. There's a lot of different scenarios to account for.

I'd definitely need to see ARM CPUs competing against Intel/AMD in a wide range of benchmarks and being on par with them.
 

soresu

Golden Member
Dec 19, 2014
1,571
783
136
Yeah I'm not convinced. The A13 is very powerful however comparing it to Intel/AMD is not so easy. There's a lot of different scenarios to account for.

I'd definitely need to see ARM CPUs competing against Intel/AMD in a wide range of benchmarks and being on par with them.
Part of the problem is that many of the real workloads that Intel/AMD CPU's get used for are simply not there to compare against at the moment.

Do we have a native CineBench/Cinema 4D version on any ARM platform to compare with?

Can we run games dev tools like the Unreal UDK and Unity engines natively on any ARM systems?

Video encoding is another good one, some open source encoders have NEON code, but I imagine that there are none as well optimised as their SSE/AVX back ends.

Even though several high end AAA games have graced the Switch, it uses the first gen v8.0-A core announced 7 years ago, not to mention it's probably not the easiest thing to get an FPS read out with?

In short benchmarks are good, but we need to see a more varied array of software to compare with x86 systems - preferably on Android, iOS, Windows and Linux (though I admit this is asking the impossible).
 

thunng8

Member
Jan 8, 2013
135
28
101
Part of the problem is that many of the real workloads that Intel/AMD CPU's get used for are simply not there to compare against at the moment.

Do we have a native CineBench/Cinema 4D version on any ARM platform to compare with?

Can we run games dev tools like the Unreal UDK and Unity engines natively on any ARM systems?

Video encoding is another good one, some open source encoders have NEON code, but I imagine that there are none as well optimised as their SSE/AVX back ends.

Even though several high end AAA games have graced the Switch, it uses the first gen v8.0-A core announced 7 years ago, not to mention it's probably not the easiest thing to get an FPS read out with?

In short benchmarks are good, but we need to see a more varied array of software to compare with x86 systems - preferably on Android, iOS, Windows and Linux (though I admit this is asking the impossible).
Adobe Premiere Rush, Adobe Lightroom CC.

From my experience Rush and Lightroom CC are super fast on my iPad Pro 2018. In fact, Lightroom CC is slightly faster than my i7-8700 mac mini at exporting A7RIII Raw to jpeg and about the same responsiveness at just adjustments and panning through the photo at 100%.

I don't have experience in Rush, but according to laptopmag, it is faster than any of their tested laptops at video encoding.


Adobe Photoshop is launching on ipad (hopefully soon) so that should be a good reference point for comparison.
 

soresu

Golden Member
Dec 19, 2014
1,571
783
136
I don't have experience in Rush, but according to laptopmag, it is faster than any of their tested laptops at video encoding.
I'm not sure that Premiere Rush is directly comparable to Premiere Pro CC - it uses the same Mercury engine compiled for Vulkan that PP CC does, but I think the UI is a different beast (a lot of the Adobe codebases are old and unwieldy, it was probably easier to decouple the Mercury parts and write a new UI from scratch).

As to video encoding, that is a tricky thing to compare with there, especially if we don't know if/what encoder ASIC's are being used in place of the CPU (they very likely are given power constraints of most ARM based systems).

If it's an ASIC, you aren't comparing ARM to x86 at all, but rather various enc ASIC IP's.
 

beginner99

Diamond Member
Jun 2, 2009
4,705
1,104
136
I don't see Apple ever using non Intel/AMD CPUs in their products. The app compatibility issue isn't worth it.
I agree but for different reasons. The reasons are market size and market segments. While macbook market might be big enough (not sure) for a custom chip, you still limit yourself to that 1 chip. So how to you differentiate between a macbook air and a macbook pro besides body/screen size? Very little incentive to get the bigger, more expensive product.

But the real issue then are macpro. That market is way, way too small to justify an own chip but using the same as in macbooks doesn't work either. Even with a chiplet strategy, the "IO die" would probably be to costly to make this worth it.

In summary apples laptop/desktop market is far to small to allow them to make enough custom ARM chips to serve the same market as today. If Apple goes ARM, the macpro and and high performance mac is dead. Of course this is entirely possible but not very likely.

Apple does this by IPC, not frequency
Apple does it by having "huge" cores and "huge" die sizes.

It's a fact that get's easily forgotten how big Axx cores (bigger than skylake) and the whole SOC actually are. And i have said this a lot on these forums already. This works fine, if your newest SOC goes only in devices that cost >$700. Intel on the other hand still has far greater volume and needs to sell chips profitable in $300 craptops. Hence die size matters much, much more. We can see this with their 14nm supply issues right now. It's not because of demand but because of AMD having to ship >4-core dies meaning much lower chip output in terms of units while needing more wafers. So the trade-off is not just IPC vs frequency. It also involves die size.
 
  • Like
Reactions: Failnaught

the2199

Junior Member
Oct 17, 2019
13
4
11
Yes, no, and yes! It will of course be using Explosion-Big and Firebolt-Little, running at 20 GHz and 10 GHz on TSMC's N5 Super node. It will wreck everything in all existence, past-present-future. It will make you money for free, and cure all problems with its massive beyond-human brain NPU. Buy one today at the Apple Store, but before you do that be sure to buy a pass of usage for $999*. *Comes with a monthly charge of $999.
man you don't know how correct you are.
 

the2199

Junior Member
Oct 17, 2019
13
4
11
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 weeping and wailing THIS YEAR (every year there's a big weeping and wailing...) is about Catalina dropping all 32-bit compatibility.
Apple has switched from 68K to PPC to x86 (to ARM on iDevices). They have switched from 32 to 64-bits multiple times. Every one of those transitions was smooth. Most people never even noticed. Of course there is that very particular internet personality who is still whining five years later how some transition killed his cat and ate his dog... Do you want to base your analysis of the future on Mr Grumpy, or on the lived experience on most users?

(b) Why don't most users notice? Because
- most users only use Apple apps. I cannot stress how important this is. Apple apps cover most of what people want, and they are very good. And Apple apps will transition to ARM COMPLETELY when Apple transitions. Apple is not MS, randomly leaving bits and pieces of the OS to rot away and never recompiling them.

- most Apple developers are used to change. If they're not, they're bankrupt. Apple tells them years in advance to adopt some technologies and stop using others, and if they refuse to do so THEIR APPS STOP WORKING. (Which includes, as a side effect, that people stop paying for them...) If you ship a GL app today, you're an idiot. If you ship a Carbon app today, it won't work on Catalina. If you ship a PPC assembly app, well, good luck being part of you little community of three other fanatics living in the past. Apple developers have apps written in high level languages, not assembly. So they retarget by recompiling.

- Apple has long experience in how to allow their developers to easily create fat binaries that run on multiple architectures. They'll have a version of Xcode that does this as appropriate (probably announced at WWDC next year) and any developer that's not actually dead will be shipping fat binaries by the time the consumer ARM Macs ship.

- Apple is used to shipping emulators, JITs, and similar machinery that can handle old binaries. Apple doesn't have much interest in supporting this long-term. But they will provide such support for the first few years. People's old x86-64 apps will work (not as fast as before, but they will work) for a year or so, while people who rely on them find an alternative.

(c) Why is this all true for Apple but not Microsoft? Because, repeat after me kids, APPLE IS NOT MICROSOFT!
I'm not interested in arguing about the values of perpetual compatibility and caution vs perpetual change and risk taking. Both have their place, both attract different personalities. It's just a fact that MS is one, Apple is the other. One consequence is that when Apple makes a change like this, it goes all in. Once Apple has decided on ARM Macs, the entire line will be ARM Macs within a year. Within ~three years the old x86 Macs will stop getting new APIs. After ~five years they'll stop getting OS updates, after ~seven years they'll stop getting Security updates. Meanwhile MS still can't decide 20 years later whether it wants to fully support .NET and CLR or not. It remains wishy-washy about its ARM support.
This has consequences. It means that Apple developers are used to rebuilding every year, whereas many Wintel developers never even bother trying to compile for ARM. It means few Apple users are running code that was compiled more than a year ago --- because such code, even if it's still sorta compatible doesn't work well on the newest devices; and because the kinds of developers who don't update their code frequently don't make any money on Macs.

(d) This may come as a shock to you, but the number of people who actually give a damn about Windows running on their Macs is miniscule. Why would they? Everything they want exists in Mac form. Sure, if you hang out in certain places it sounds like this is a super-important issue --- just like if you hang out in certain places everyone will insist that gaming on Linux is like, totally, the economic foundation of the computer entertainment industry...

(e) For those people who absolutely insist on still running Windows on their Macs, here's another surprise: It's no longer 1995, and we have new technologies!
If you require x86+Windows in the modern world, the way you will get it is through a PC in a thumb drive that will communicate with the host Mac's virtualized IO and screen. Basically what Parallels does today, but with the x86 code running on a thumb PC and communicating via USB-C. Apple probably won't even do the work, they'll just let Parallels or VMWare write the code and drivers for both ends and sell the thumb PCs; all Apple will do is work with them if there are any particular technical issues that come up. Expect to see one or both of them demo-ing such a solution when Apple announces the ARM Macs to consumers.
NO-ONE is going to bother with some sort of hydra chip that either executes both ARM and x86 code, or even that puts an x86 core on the ARM SoC.


There is a constant thread going through the people who say Apple can't do this: they are people who haven't studied the history of Apple, and who don't use Apple products very much. They look at this from the point of view of how it would fall out if MS did this. But, what did I say, kids, APPLE IS NOT MS!
Apple USERS are not MS users -- different expectations, different software on their machines.
Apple DEVELOPERS are not MS developers -- used to change, used to supporting multiple OSs and ISAs.


As for why Apple would do this

(a) performance. Apple ALREADY matches the best performance Intel has in their "standard" cores. Look at the numbers. The phone cores do this under phone constraints (most significantly a current constraint). The iPad cores tend to run 5..10% higher performance partially because the current constraint is not so strict, partially because they have wider memory. Obviously the Mac cores would be at the very least the iPad cores, with that wider memory, and with even less severe current constraints.
Apple does this by IPC, not frequency, and if you insist that frequency matters, all you're showing is your ignorance. Intel built themselves a massive hole (that they now apparently can't get out of) because they obsessed over frequency too much (apparently learning NOTHING from how the same obsession failed with the P4).
The one place Apple still lags Intel in a measurable way, for some tasks, is code that can use wide vectors (ie AVX-512). Presumably Apple will soon (maybe even next year) have SVE which takes care of that.

(b) SMT. Another sure sign of the ignorant.
SMT is a DUD. It gives 25% extra performance (so your 4 cores have the throughput of five cores -- for some types of code) at the cost of enormous validation and security headaches.
There are ways to add SMT-like functionality that are much smarter than SMT (in particular forget the "symmetric" part, have fibers that are user-level controlled, not OS controlled, so they never cross protection boundaries) and I certainly hope that if ARM or Apple ever go down the "SMT-like" path, they do that, not Intel-style SMT.
But for now, the ARM/Apple "answer" to SMT is small cores. If you need extra throughput, use the small cores. An A12X (4 large, small cores) has the throughput of ~5 large cores --- same, effectively as SMT"s 25% boost. Different ways to solve the same problem of optionality --- how do I ship a system that maximizes for all of latency, throughput, AND power? SMT gives you some flexibility for the first two, big.little gives you that same flexibility but for all three.

(c) Control. Look at what Apple has done with control of their own SoC. Obviously continual performance improvements.
Much better security. (Including IO security.)
Continually adding features to GPU, plus adding NPU, plus now adding what's apparently for on-machine learning (AMX).
Other functionality we don't even really know yet (U1).

Against that, with Intel all they get is more of the same, year after year. Intel turnaround times are SO slow. Upgrades appear to have actually stopped. Security remains an on-going issue.

Sure Apple can try to deal with some of this through heroic interventions like adding the T1 then T2 chips to retrofit some security. But god, what a pain!
Look at things like how long Apple wanted to use LPDDR4 in Macs --- but couldn't because Intel. I'm sure at least part of the delay for the new Mac Pros was that Apple kept hoping (or being promised by Intel) that soon Intel would be shipping something with PCIe4. But no, still waiting on that.
you are dead wrong for example x264 the video encoder for h.264 or (AVC) is fine-tuned for x86 assembly. you can run x264 on any other (ISA) it will run just fine but it will not as fast compare to x86. there is a difference between code running on the cpu and code running on the cpu and using it to it fullest. take google new av1 decoder, for example, it created with arm on mined not for x86 you can compile it for x86 but the performance is so slow compared to other decoders see how LIBGAV1 is so slow
 

Nothingness

Platinum Member
Jul 3, 2013
2,158
406
126
That is because a single core does not use close to the power available to desktop CPUs from TDP perspective. So a much lower rated mobile CPU does achieve similar performance in single core indeed. However if you are running all cores, it suddenly shows that the desktop TDP is actually required for high performance.
This is what I wrote :)

My take is 8xA13 @3GHz < 15W. Not sure where you got the idea from that a single A13 core uses 3W?
Easy: look at the power consumption published by Andrei:
429.mcf is at 3.79W while 470.lbm is at 6.27W. So there's a 2.5W difference and you will agree that it's unlikely a core running a program at full speed consumes less than 0.5W. So 3W looks like a good approximation of the lower bound of max power consumption of a core.

In this case it would be much less efficient than say Cortex A76...which consumes roughly 750mW@2.8GHz.
Where did you get this A76 figure from? Again looking at Andrei results, for SD855 I see 458.sjeng at 1.68W and 470.lbm at 3.44W. That'd be about 2W.

Likewise Micrsoft put 4xCortex A76@3GHz + 4Cortex A55@??GHz into a 7W TDP machine (Surface Pro X).
You really think that all the 4 big cores can ever run at full speed at the same time? And that this TDP will be sustained? Or like Intel max power consumption can exceed 7W for short periods of time?

Does not really matter how many critical pathes you have - they all benefit equally from higher voltage. Given that the most critical path allows 2.6GHz at something like 0.8V VCC shows how much frequency headroom there is.
0.8V at max frequency? Where does that come from?

Look at this curve, and let's start talking about increasing voltage and TDP :)



And this is without significant binning - the fastest chips are most likely much better.
Oh yes binning. How much does that bring to SD855 derivatives? 0.2 GHz? :D

I have this SD845 board in front of me. I'm looking at a way to put a fan on it because it keeps on throttling. Locking frequency make it reach 100°C with a single core running. If I don't lock frequencies this thing throttles within a few seconds. Yes that's a smartphone chip with a heatspreader.
 
  • Like
Reactions: spursindonesia

Nothingness

Platinum Member
Jul 3, 2013
2,158
406
126
The level of ignorance in this thread would be shocking if it weren't depressing.
Let's state some basics:
Maynard, you know you're a pain with your condescending tone? And it's funny you didn't notice that I was playing the devil's advocate.

(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 weeping and wailing THIS YEAR (every year there's a big weeping and wailing...) is about Catalina dropping all 32-bit compatibility.
Apple has switched from 68K to PPC to x86 (to ARM on iDevices). They have switched from 32 to 64-bits multiple times. Every one of those transitions was smooth. Most people never even noticed. Of course there is that very particular internet personality who is still whining five years later how some transition killed his cat and ate his dog... Do you want to base your analysis of the future on Mr Grumpy, or on the lived experience on most users?
Hint: compare the performance of the chips when the switch happened. Then project the required performance of the Apple ARM chip. As I already wrote I personally don't care about legacy or Windows, so I'd be more than happy with the level of performance they have achieved.

I'm too lazy (and sane) to read the rest of your rant. It's probably disgustingly full of blind adoration for Apple which prevents any form of civilized discussion (as you repeatedly proved on Realworldtech).

I just want Apple to bring a MacOS X ARM machine with Xcode to market, and they technically already are in a position to do that.
 
  • Like
Reactions: the2199

Nothingness

Platinum Member
Jul 3, 2013
2,158
406
126
However, the numerous extra SIMD ISA used with x64 is still likely to be under patent for quite some time - I wouldn't be surprised if Intel keep pushing new ISA extensions on top of what exists merely to retain control.
Yeah but Intel themselves make sure these instructions are not required by fusing them off in many of their chips. It's fun to see they still don't have AVX everywhere, not even in some of their Coffee Lake CPUs.
 

ASK THE COMMUNITY