IOS is an OS from one company that is made for a few specific products from that one company. You cant evenly compare an open platform to a narrow closed market like that.
Yes Apple SoC seems to be 64bit-only for years, that simplify their own design and gives more efficiency.
As 64bit ARM ISA as nothing in common with 32bit ARM ISA, contrary to the x86 and AMD64, they basically started with a blank page, profiting from experience of various preceding 64bit ISA, I feel it was the right way to go.
ARMv8 makes execution of AArch32 optional. Apple may have been responsible for that as they were involved in the spec of ARMv8 and AArch64 - they would have known they'd want to drop 32 bit code as soon as it was practical.
Apple is a founding partner with an architectural license. They can change anything they wish on the CPU design, then have it fabricated. I thought this was known because of the wildly different core design from Apple. They take the ISA they pick and choose and add/delete what they need. They actually help ARM in the long run as seeing how Apple uses 64bit and finds solutions to their issues, because as stated above 64bit was blank slate for ARM. I'm very fairly certain of this, but if you know something I don't? (I might not..)
An architectural license allows them to implement the ISA, but they can't delete things from it. They are able to add things to it (i.e. TSO, their AMX instructions, etc.) but it still has to pass ARM's conformance tests to show it is capable of running ARM code.
They were able to "delete" AArch32 because ARMv8 allows that. ARMv9 goes further and makes AArch32 a special license addition or something like that - basically Aarch32 is deprecated with ARMv9 and will probably go away entirely with ARMv10.
No, they were not able to "delete" AArch32. They can disallow AArch32 codes execution in their OS just like Google Pixel 7-series, they cannot remove the support from hardware.
And Apple did not add anything to ARM ISA. AMX is masked as a co-processor only available through frameworks, it doesn't directly execute any code other than a "firmware".
TSO is not an instruction. It's a **mode**. It pertains to HOW the CPU reorders L/S queue. It has nothing to do with the ISA.
Yes TSO is a mode, which requires a setting IN THE ISA to be able to enable it. That setting does not exist on ARM CPUs, only on Apple Silicon implementations.
abr2 found what I didn't have time to look for in the ARMv8 architecture reference manual proving your ridiculous claim that ARMv8 required AArch32 support was wrong. Now you're picking on nits trying to twist my words as if I was claiming TSO is an instruction. Give it up you are wrong, everyone knows it, go away quietly instead of making yourself look like even a bigger fool.
And your understanding of ARMv9 is abysmal at best. ARMv9-A made Aarch32 EL0 optional, it wasn't possible in ARMv8-A. There is no special license or "something like that".
It has been possible an architecturally permissible since ARMv8.0 to create an AArch64 only implementation. If AArch32 is not supported at a particular exception level then setting the M[4] bit in the SPSR and executing an ERET instruction to that level will produce an illegal exception return exception. Combined with designing the system to only reset in to AArch64 at the highest implemented exception level gives you an AArch64 only design.
This tangentially referred to in rule R-tytwb in section D1.3.4 of revision J.a of the ARM Architecture Reference Manual.
A conformant ARMv8.x implementation can (but it not mandated to) implement AArch32 at any exception level.
A conformant ARMv9.x implementation may only implement AArch32 at EL0. This is documented in section 3.1 of revision J.a of the ARM Architecture Reference Manual.
There are even documented ARMv8.1 processors out there which are AArch64 only for example the Cavium ThunderX2
D1.20.2 Support for Exception levels and Execution states Subject to the interprocessing rules defined in Interprocessing on page D1-2525, an implementation of the Arm architecture could support: • AArch64 state only. • AArch64 and AArch32 states. • AArch32 state only.
@dotjaz - You don’t know what you’re talking about. The Apple A7 chip supported both A32 and A64 instruction set. By the A11 (in 2017), Apple dropped A32 instruction set and was 64bit only.
> I'm very fairly certain of this, but if you know something I don't? (I might not..)
You are clearly wrong, no ARM licensees can alter ARM ISA in any way. That's the fundation of ARM's licensing terms. And that's the sole reason Apple's AMX extention is masked as undocumented "co-processor" not available to anyone. Even if you knew nothing about the fundamental licensing terms, you should be able to figure that out because if this.
Jesus. The levels of delusion that are required to write a comment like this. You really think that (a) ARM is going to make a big deal about Apple being, in some legalistic sense, "non-compliant" AND (b) that Apple gives a fsck?
Exactly who do you think gets hurt if Apple are not allowed to call APPLE SILICON (note that branding...) Arm Compliant?
So much of this nonsensical 64Bit bs. Esp in the name of security, News Flash - Qualcomm EDL mode exists and thankfully it helps the folks to unlock their Bootloaders.
The whole 64Bit thing killed the passion on Android. Google just enforces it brutally by n-1 where n being the latest API SDK, thus making all the old apps go obsolete. Windows and x86 excels massively just because of this, Apple did it because they always want to control everything which they do, and the stupid Google just copies them in hoping to make same but they killed all fun on android now, the UI is so boring garbage and the whole Filesystem nerfs - Scoped Storage, lack of proepr SD Card app support and a ton of other APIs blacklisted. Limited the scope of foreground and background apps utilizing the hardware of a phone.
What's the use of the ARM processor devices, when your latest and greatest X4 ARM phone will be outdated in 1 year and goes to dumpster after 2-3 years max. Non Removable, non serviceable, no longevity of the OS / HW / Software. Locked like chastity belt for the User tinkering when the core OS, the Kernel runs Linux. A big L to consumers and all that Environment jabber is literally just a worthless cacophony. Literally you have latest V30 class Micro SDs and SD Association even had PCIe / NVMe SSD class but since not a single $1000-$2000 Android phone pushes forward for a real computer in pocket, its rather a spybox and a mere 2FA device with some Navigation, Social Media, Camera attached.
All this ARM tech is only useful if your device Software API can open it up properly and used a proper pocket computer. But that ship has sailed. All that X4 processing power and multi core non homogeneous compute wasted on basic consumables.
It is not related to the UI, it is related to the worst practices in ARM, Apple.
Disposable goods, non compute focused, rather a simplistic tool for the Technological dependency rather than using it like a computer and most importantly, owning your own data in the case of an ARM powered smartphone - Filesystem, Applications control Etc. None of these are present in iOS. And they are now incorporated into the Android heavily from the UI, Design philosophy, Technology.
Axing 32Bit OS / Applications and forcing everyone to be on the Playstore mandated policies gives an edge to Android on axing the power user features, i.e targeting latest OS SDK means you are restricted heavily to an OS and its jail. Also they are hiding applications now on Playstore. That means old apps are now hard to find, and good apps do not work on latest OS (Timey app for eg), and lot of examples. Plus now modern Android blocks you even on Sideload notifying the SDK target version in normal terms such as this app won't work properly because Android 14 and up do not allow Android 6 below apps.
Windows enjoys the superior user retention and proper computing because of it's legacy support, A Windows 3.1 .exe will work on Windows 10. But on Apple it's all outdated and even hardware, any x86 processor from Core2Quad which lacks SSE4 and AVX2 still runs modern games which utilize these features but can be made to work because of the power of x86 and Windows. That's how a superior computer is born but not guardrails and heavy restriction and placing consumer in the dark in the name of technology BS.
Legacy support is overrated for vast majority of the user base, even on windows. its also a thing that can be achieved with emulation for the niche use cases. Most of the argument you gave had little to non to do with 32 bit support. This legacy support costs in silicon space, complexity and software upkeep - all of those resources can be used for actually useful things that will benefit most users.
Intel is thinking about being 64bit-only too, with the X86S project.
This is an interesting way, as 16bit and 32bit compatibility could be offered through software emulation in a VM (their proposal), naturally with impact on performances.
I hope that project doesn't fly but looking at modern Intel with their ARM clone of P+E to worst now P+E+LPE cores they may break the whole 32Bit Application world.
Only HPC market can stop it but looking at how Windows 10 is now being retired by 2030 max (LTSC 1809 maximum lifecycle) add maybe ESU channel like Win7 to 2033 at best, after that I think Windows will also copy Apple hard they are already doing it hardcore as Windows 11 is the Win10S branched out because those internal designers are cultists of the Applesque systems lock down and uber simplification of power user nature, this makes entire generations of young population being dumbed down by the basic structure of the OS + Technology rather than innovative and explorative thinking process of the older era (XP, 7 etc)
Windows 10 is the last Microsoft OS that has real support of all the older Windows applications, 11 discarded a lot of Shell32 / Win32 systems and ruined the NTKernel in the process and the CPU schedulers. They sabotaged the entire explorer.exe too, and with the modern fad AI introduction into the OS the telemetry will explode into exponential factor and with the complete dumbing down of the OS and the process, Atomization of the human thinking will lead to regressive computation. Really unfortunate.
Emulation means there will be a performance penalty.
At least Gavin addressed the mini-elephant in the room for the small cores (thanks!): still no out-of-order design. Instead, an ALU is removed "for greater efficiency". By now, I am suspecting that ARM and Apple have some kind of understanding that ARM little cores won't, under any circumstance, be allowed to come anywhere close to challenging Apple's efficiency cores in Perf/W. Apple's efficiency cores have about twice the IPC of the little ARM cores and all at about the same power draw. Which made the impossible come true: I am now rooting for Qualcomm to kick ARM's butt, both in court and in SoCs.
Oh FFS, always the conspiracy theories! It’s really much simpler — Apple’s small cores are much larger than ARM’s small cores. ARM seems to be thinking that their mid cores (A720) can play the role of Apple’s small cores, and that may be to some extent true in that Apple can split work between big and small in a way that Android cannot, given that Apple knows much more about what each app is doing (better API for specifying this, and much more control of the OS and drivers).
Much more interesting is how this is all about essentially catching up to Apple’s M series. Which is fine, but if you look at what Apple is doing, the action is all at the high end. I’ve said it before and will say it again; Apple has IBM-level performance in its sights. The most active work over the past three years is all about “scalability” in all its forms, how to design and connect together multiple Max class devices to various ends. The next year or two will be wild at the Apple high end!
However, I still welcome the development of a smaller and slower ARM core, if it means small power draw and small silicon area. There is a market for that outside of phones; in embedded devices, watches, wearables, and ultra low power gadgets.
We used to have something like Cortex-A7 (tiny), Cortex-A9 (small), Cortex-A17 (medium). Then we had Cortex-A35 (tiny), Cortex-A53 (small), Cortex-A73 (medium). But we never got a successor for the Cortex-A35, so perhaps a very undervolted Cortex-A520 will work. Just like how ARM justified using an overclocked Cortex-A515 as a legitimate successor to the Cortex-A53 range.
Almost all the attention goes to the (Medium) cores. It's their bread and butter. From the development of (2016) Cortex-A73, A75, A76, A77, A78, A710, A720 (2023).
But as you said, the exciting things are happening at the high-end (LARGE) cores. It's started with the creation of a new category in the X1, X2, X3, X4 designs. They seem unfit in phones, okay in tablets, and necessary for ARMbooks. Even then, their performance is somewhere far from Apple's M1/M2/M3 and unfit to tackle AMD Zen3 / Intel 11th-gen x86 cores. Let alone their newest variants.
"Even then, their performance is somewhere far from Apple's M1/M2/M3 and unfit to tackle AMD Zen3 / Intel 11th-gen x86 cores."
without sufficient support for desktop OS on desktop performance CPUs it reduces possibilities to binary translation/multiarch binaries and ISA specific OS from vendors, but not on ARM generally having a free choice for Windows/Linux/Unix variants that suit individual needs (work&development/media/gaming)
I also forgot to mention, we've had leaks for more than a year about ARMv9 and their Second-Gen cores. They were promised with a sizeable performance improvement at a reduced power draw.
Turns out the rumours were not correct. Well sort of. We assumed the advances came just from the architecture but that's not it. We're seeing a modest improvement in the architecture, and the benefits coming from a number of other factors. They're relying on a new DynamIQ setup, more cache, faster memory, all mixing together to have an overall notable improvement. Going 64bit-only in microcode will have unseen benefits too. And the elephant in the room is the jump to TSMC-3NM node shrink, which will likely have frequency increases.
So comparing the QC 8g1 (Samsung 5nm) to the (TSMC-5nm) QC 8g1+ and QC 8g2 (+5nm-TSMC) and (TSMC-3NM) QC 8g3 will be a mixed bag.
A TCS23 (X4+720+520) with 1+5+2 configuration, only yields a +27% performance uplift at the same power, compared to TCS22 (X3+715+510) in 1+3+4 cluster.
Something is miscalculated there!!!
They either mean: 1) TCS23 vs TCS23, with only difference being different configuration 2) TCS22 vs TCS22, with only difference being different configuration 3) TCS22 vs TCS23, and they meant PLUS an extra +27% performance on top of the architectural improvements 4) It's not a typo, and they really did mean you ONLY get +27% uplift total. Which doesn't make sense since they claimed the X4 uses -40% less energy than X3, whilst the A720 uses -20% less energy than A715, and the A520 uses -22% less energy than A530. Logically speaking if you just multiply the efficiency gains by the core quantities you get an impressive figure. Unless you divide that by the total cores, that gives you an average drop by -23% energy, but that's not the total. Unless the engineers or the marketers are utterly incompetent there at ARM, and they meant this -23% figure gets increased to -27% figure (+4% efficiency gain) just based on the cluster configuration difference. That's not a great improvement, it's negligible, and not substantial enough to require a new silicon stamp (which explains MediaTek).
There are so many factors changing like more L2 cache, supporting more L3 cache, faster memory, better processes and they don't tell you anything about what the differences are.
If they said X3 with x cache, y DRAM on process z was compared to X3 with x cache, y DRAM on process z then you could assume the performance uplift was due to their architecture. But they are turning all those knobs so who knows what improvement comes from the core versus what is around the core and what node it is on.
I got that, but the architecture has been rather since the Cortex-A78. Just like how there was a long period of time since the release of the Cortex-A57 compared to the Cortex-A72. That extra time let ARM make a lot of big architectural improvements. In fact, it was pretty lengthy that we got Custom Cores developed by the likes of Nvidia, Qualcomm, Samsung, all which were vastly superior to the Cortex-A57 and they matched the subsequent release of the Cortex-A72.
My biggest concern is the mistakes in their slides. If you have a 1+3+4 TCS22 design, and you do nothing but change the A510 to A520, you should see an upgrade of 22% per core. So 22% x4 should see a +88% uptick in performance. Now compare that to the mere 27% upgrade they said if you upgraded all the core types (X4 / A720 / A520) and you went with a larger chipset with the 1+5+2 design. Something is clearly amiss.
Another solution to the riddle is they are using the problematic silicon from Samsung-5nm. Making a comparison between the flawed QC 8g1, against a new chipset using the same node, but upgrading the Core-types and the Cluster-design. Even then it's a bad excuse, because that would mean its barely competing against the 6-month old QC 8g2 (on TSMC node), and we collectively just ignore the existence of the MediaTek Dimensity chipsets.
I think we will have to wait to hear the announcement of next-gen chips for 2024, in the form of QC 8g3 and MTK D9400. Let's see their claimed battery life improvement, their performance improvement, and deduce the efficiency from there. Look at which silicon they're building upon (TSMC 4nm vs 5nm). And finally look at the in depth reviews from the likes of Anandtech/Andrei, Geekerwan, and Golden Reviewer.
ARM MTE and PAC are two different things, and I find it really silly to see them touted for use together. MTE steals eight pointer bits that would have been used for PAC, and on some implementations the bits for PAC would then be as few as 3.
You would better pick one or the other, depending on your protection scheme.
So Arm are still years behind Apple? And possibly will be slower than Nuvia too? I guess this just helps QUalcomm, as smaller companies have no choice. Either use slow off the shelf parts, or pay QCOMM for their superior chip (assuming Nuvia is as good as claimed.).
Blame some of the mainland China android forks. They've spent years trying to pretend 64 bit only was never going to happen and were nowhere near ready when last years x3 dropped support for 32 bit code.
I think the GPU is becoming the more critical part in phones... I hate to downplay CPU advances, but what does being faster than an X1 really get you on mobile these days?
GPUs, on the other hand, are the bottleneck for running local AI. Flagships can already run 7B LLMs and other generative models reasonably well, but every ounce of extra GPU speed allows for significantly better inference. They are also the bottleneck for VR/AR and ports of PC/console games.
The real advance for CPU might be locking the performance in place but lowering the power usage. Which is why we're hearing about Dimensity 9300 supposedly packing four Cortex-X4 cores and four Cortex-A720 cores, with no presence of Cortex-A520. In a smartphone SoC.
Shouldn't these flagships being using their dedicated AI accelerators instead of the GPU for inference?
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
52 Comments
Back to Article
tipoo - Sunday, May 28, 2023 - link
6 years after iOS went 64 bit only. I'm guessing the cores have also been 64 bit only there for a while?goatfajitas - Monday, May 29, 2023 - link
IOS is an OS from one company that is made for a few specific products from that one company. You cant evenly compare an open platform to a narrow closed market like that.iAPX - Monday, May 29, 2023 - link
Yes Apple SoC seems to be 64bit-only for years, that simplify their own design and gives more efficiency.As 64bit ARM ISA as nothing in common with 32bit ARM ISA, contrary to the x86 and AMD64, they basically started with a blank page, profiting from experience of various preceding 64bit ISA, I feel it was the right way to go.
dotjaz - Monday, May 29, 2023 - link
No it's not, Apple is not allowed to modify ARM ISA. If it's ARMv8 compliant, it CANNOT possibly be 64bit only.Doug_S - Monday, May 29, 2023 - link
ARMv8 makes execution of AArch32 optional. Apple may have been responsible for that as they were involved in the spec of ARMv8 and AArch64 - they would have known they'd want to drop 32 bit code as soon as it was practical.dotjaz - Tuesday, May 30, 2023 - link
That's factually UNTRUE, Aarch32 execution is mandatory in **hardware implementation**, Aarch64 **OS** can choose not to execute Aarch32 codesDoug_S - Tuesday, May 30, 2023 - link
Sorry but you are wrong, ARMv8 specifically makes support for AArch32 optional for hardware implementations.Jaybird99 - Monday, May 29, 2023 - link
Apple is a founding partner with an architectural license. They can change anything they wish on the CPU design, then have it fabricated. I thought this was known because of the wildly different core design from Apple. They take the ISA they pick and choose and add/delete what they need. They actually help ARM in the long run as seeing how Apple uses 64bit and finds solutions to their issues, because as stated above 64bit was blank slate for ARM. I'm very fairly certain of this, but if you know something I don't? (I might not..)Doug_S - Monday, May 29, 2023 - link
An architectural license allows them to implement the ISA, but they can't delete things from it. They are able to add things to it (i.e. TSO, their AMX instructions, etc.) but it still has to pass ARM's conformance tests to show it is capable of running ARM code.They were able to "delete" AArch32 because ARMv8 allows that. ARMv9 goes further and makes AArch32 a special license addition or something like that - basically Aarch32 is deprecated with ARMv9 and will probably go away entirely with ARMv10.
dotjaz - Tuesday, May 30, 2023 - link
No, they were not able to "delete" AArch32. They can disallow AArch32 codes execution in their OS just like Google Pixel 7-series, they cannot remove the support from hardware.And Apple did not add anything to ARM ISA. AMX is masked as a co-processor only available through frameworks, it doesn't directly execute any code other than a "firmware".
TSO is not an instruction. It's a **mode**. It pertains to HOW the CPU reorders L/S queue. It has nothing to do with the ISA.
Doug_S - Tuesday, May 30, 2023 - link
Yes TSO is a mode, which requires a setting IN THE ISA to be able to enable it. That setting does not exist on ARM CPUs, only on Apple Silicon implementations.abr2 found what I didn't have time to look for in the ARMv8 architecture reference manual proving your ridiculous claim that ARMv8 required AArch32 support was wrong. Now you're picking on nits trying to twist my words as if I was claiming TSO is an instruction. Give it up you are wrong, everyone knows it, go away quietly instead of making yourself look like even a bigger fool.
dotjaz - Tuesday, May 30, 2023 - link
And your understanding of ARMv9 is abysmal at best. ARMv9-A made Aarch32 EL0 optional, it wasn't possible in ARMv8-A. There is no special license or "something like that".Chelgrian - Tuesday, May 30, 2023 - link
It has been possible an architecturally permissible since ARMv8.0 to create an AArch64 only implementation. If AArch32 is not supported at a particular exception level then setting the M[4] bit in the SPSR and executing an ERET instruction to that level will produce an illegal exception return exception. Combined with designing the system to only reset in to AArch64 at the highest implemented exception level gives you an AArch64 only design.This tangentially referred to in rule R-tytwb in section D1.3.4 of revision J.a of the ARM Architecture Reference Manual.
A conformant ARMv8.x implementation can (but it not mandated to) implement AArch32 at any exception level.
A conformant ARMv9.x implementation may only implement AArch32 at EL0. This is documented in section 3.1 of revision J.a of the ARM Architecture Reference Manual.
There are even documented ARMv8.1 processors out there which are AArch64 only for example the Cavium ThunderX2
https://en.wikichip.org/wiki/cavium/thunderx2
"Only the 64-bit AArch64 execution state is support. No 32-bit AArch32 support."
abr2 - Tuesday, May 30, 2023 - link
From:Arm® Architecture Reference Manual
Armv8, for Armv8-A architecture profile
[2021 version]
D1.20.2 Support for Exception levels and Execution states
Subject to the interprocessing rules defined in Interprocessing on page D1-2525, an implementation of the Arm architecture could support:
• AArch64 state only.
• AArch64 and AArch32 states.
• AArch32 state only.
techconc - Thursday, June 8, 2023 - link
@dotjaz - You don’t know what you’re talking about. The Apple A7 chip supported both A32 and A64 instruction set. By the A11 (in 2017), Apple dropped A32 instruction set and was 64bit only.dotjaz - Tuesday, May 30, 2023 - link
> I'm very fairly certain of this, but if you know something I don't? (I might not..)You are clearly wrong, no ARM licensees can alter ARM ISA in any way. That's the fundation of ARM's licensing terms. And that's the sole reason Apple's AMX extention is masked as undocumented "co-processor" not available to anyone. Even if you knew nothing about the fundamental licensing terms, you should be able to figure that out because if this.
name99 - Monday, May 29, 2023 - link
Jesus. The levels of delusion that are required to write a comment like this.You really think that
(a) ARM is going to make a big deal about Apple being, in some legalistic sense, "non-compliant" AND
(b) that Apple gives a fsck?
Exactly who do you think gets hurt if Apple are not allowed to call APPLE SILICON (note that branding...) Arm Compliant?
Wereweeb - Tuesday, May 30, 2023 - link
Lmao apple fanboys still as hilarious and ignorant as alwaysSilver5urfer - Sunday, May 28, 2023 - link
So much of this nonsensical 64Bit bs. Esp in the name of security, News Flash - Qualcomm EDL mode exists and thankfully it helps the folks to unlock their Bootloaders.The whole 64Bit thing killed the passion on Android. Google just enforces it brutally by n-1 where n being the latest API SDK, thus making all the old apps go obsolete. Windows and x86 excels massively just because of this, Apple did it because they always want to control everything which they do, and the stupid Google just copies them in hoping to make same but they killed all fun on android now, the UI is so boring garbage and the whole Filesystem nerfs - Scoped Storage, lack of proepr SD Card app support and a ton of other APIs blacklisted. Limited the scope of foreground and background apps utilizing the hardware of a phone.
What's the use of the ARM processor devices, when your latest and greatest X4 ARM phone will be outdated in 1 year and goes to dumpster after 2-3 years max. Non Removable, non serviceable, no longevity of the OS / HW / Software. Locked like chastity belt for the User tinkering when the core OS, the Kernel runs Linux. A big L to consumers and all that Environment jabber is literally just a worthless cacophony. Literally you have latest V30 class Micro SDs and SD Association even had PCIe / NVMe SSD class but since not a single $1000-$2000 Android phone pushes forward for a real computer in pocket, its rather a spybox and a mere 2FA device with some Navigation, Social Media, Camera attached.
All this ARM tech is only useful if your device Software API can open it up properly and used a proper pocket computer. But that ship has sailed. All that X4 processing power and multi core non homogeneous compute wasted on basic consumables.
rpg1966 - Monday, May 29, 2023 - link
Could you explain how the UI is affected by the bitness of the OS?Silver5urfer - Monday, May 29, 2023 - link
It is not related to the UI, it is related to the worst practices in ARM, Apple.Disposable goods, non compute focused, rather a simplistic tool for the Technological dependency rather than using it like a computer and most importantly, owning your own data in the case of an ARM powered smartphone - Filesystem, Applications control Etc. None of these are present in iOS. And they are now incorporated into the Android heavily from the UI, Design philosophy, Technology.
Axing 32Bit OS / Applications and forcing everyone to be on the Playstore mandated policies gives an edge to Android on axing the power user features, i.e targeting latest OS SDK means you are restricted heavily to an OS and its jail. Also they are hiding applications now on Playstore. That means old apps are now hard to find, and good apps do not work on latest OS (Timey app for eg), and lot of examples. Plus now modern Android blocks you even on Sideload notifying the SDK target version in normal terms such as this app won't work properly because Android 14 and up do not allow Android 6 below apps.
Windows enjoys the superior user retention and proper computing because of it's legacy support, A Windows 3.1 .exe will work on Windows 10. But on Apple it's all outdated and even hardware, any x86 processor from Core2Quad which lacks SSE4 and AVX2 still runs modern games which utilize these features but can be made to work because of the power of x86 and Windows. That's how a superior computer is born but not guardrails and heavy restriction and placing consumer in the dark in the name of technology BS.
Eliadbu - Monday, May 29, 2023 - link
Legacy support is overrated for vast majority of the user base, even on windows. its also a thing that can be achieved with emulation for the niche use cases. Most of the argument you gave had little to non to do with 32 bit support. This legacy support costs in silicon space, complexity and software upkeep - all of those resources can be used for actually useful things that will benefit most users.TheinsanegamerN - Wednesday, May 31, 2023 - link
LMAO legacy support is the only reason windows still exists.iAPX - Monday, May 29, 2023 - link
Intel is thinking about being 64bit-only too, with the X86S project.This is an interesting way, as 16bit and 32bit compatibility could be offered through software emulation in a VM (their proposal), naturally with impact on performances.
Silver5urfer - Monday, May 29, 2023 - link
I hope that project doesn't fly but looking at modern Intel with their ARM clone of P+E to worst now P+E+LPE cores they may break the whole 32Bit Application world.Only HPC market can stop it but looking at how Windows 10 is now being retired by 2030 max (LTSC 1809 maximum lifecycle) add maybe ESU channel like Win7 to 2033 at best, after that I think Windows will also copy Apple hard they are already doing it hardcore as Windows 11 is the Win10S branched out because those internal designers are cultists of the Applesque systems lock down and uber simplification of power user nature, this makes entire generations of young population being dumbed down by the basic structure of the OS + Technology rather than innovative and explorative thinking process of the older era (XP, 7 etc)
Windows 10 is the last Microsoft OS that has real support of all the older Windows applications, 11 discarded a lot of Shell32 / Win32 systems and ruined the NTKernel in the process and the CPU schedulers. They sabotaged the entire explorer.exe too, and with the modern fad AI introduction into the OS the telemetry will explode into exponential factor and with the complete dumbing down of the OS and the process, Atomization of the human thinking will lead to regressive computation. Really unfortunate.
Emulation means there will be a performance penalty.
stephenbrooks - Monday, May 29, 2023 - link
I'm interested by the ARM laptop direction (the 10 X4 plus 4 mid-core design). That could run a full OS like Windows or Linux.eastcoast_pete - Monday, May 29, 2023 - link
At least Gavin addressed the mini-elephant in the room for the small cores (thanks!): still no out-of-order design. Instead, an ALU is removed "for greater efficiency". By now, I am suspecting that ARM and Apple have some kind of understanding that ARM little cores won't, under any circumstance, be allowed to come anywhere close to challenging Apple's efficiency cores in Perf/W. Apple's efficiency cores have about twice the IPC of the little ARM cores and all at about the same power draw. Which made the impossible come true: I am now rooting for Qualcomm to kick ARM's butt, both in court and in SoCs.name99 - Monday, May 29, 2023 - link
Oh FFS, always the conspiracy theories!It’s really much simpler — Apple’s small cores are much larger than ARM’s small cores. ARM seems to be thinking that their mid cores (A720) can play the role of Apple’s small cores, and that may be to some extent true in that Apple can split work between big and small in a way that Android cannot, given that Apple knows much more about what each app is doing (better API for specifying this, and much more control of the OS and drivers).
Much more interesting is how this is all about essentially catching up to Apple’s M series. Which is fine, but if you look at what Apple is doing, the action is all at the high end. I’ve said it before and will say it again; Apple has IBM-level performance in its sights. The most active work over the past three years is all about “scalability” in all its forms, how to design and connect together multiple Max class devices to various ends. The next year or two will be wild at the Apple high end!
Kangal - Monday, May 29, 2023 - link
Thank you!However, I still welcome the development of a smaller and slower ARM core, if it means small power draw and small silicon area. There is a market for that outside of phones; in embedded devices, watches, wearables, and ultra low power gadgets.
We used to have something like Cortex-A7 (tiny), Cortex-A9 (small), Cortex-A17 (medium). Then we had Cortex-A35 (tiny), Cortex-A53 (small), Cortex-A73 (medium). But we never got a successor for the Cortex-A35, so perhaps a very undervolted Cortex-A520 will work. Just like how ARM justified using an overclocked Cortex-A515 as a legitimate successor to the Cortex-A53 range.
Almost all the attention goes to the (Medium) cores. It's their bread and butter. From the development of (2016) Cortex-A73, A75, A76, A77, A78, A710, A720 (2023).
But as you said, the exciting things are happening at the high-end (LARGE) cores. It's started with the creation of a new category in the X1, X2, X3, X4 designs. They seem unfit in phones, okay in tablets, and necessary for ARMbooks. Even then, their performance is somewhere far from Apple's M1/M2/M3 and unfit to tackle AMD Zen3 / Intel 11th-gen x86 cores. Let alone their newest variants.
back2future - Tuesday, May 30, 2023 - link
"Even then, their performance is somewhere far from Apple's M1/M2/M3 and unfit to tackle AMD Zen3 / Intel 11th-gen x86 cores."without sufficient support for desktop OS on desktop performance CPUs it reduces possibilities to binary translation/multiarch binaries and ISA specific OS from vendors, but not on ARM generally having a free choice for Windows/Linux/Unix variants that suit individual needs (work&development/media/gaming)
Kangal - Monday, May 29, 2023 - link
I also forgot to mention, we've had leaks for more than a year about ARMv9 and their Second-Gen cores. They were promised with a sizeable performance improvement at a reduced power draw.Turns out the rumours were not correct. Well sort of. We assumed the advances came just from the architecture but that's not it. We're seeing a modest improvement in the architecture, and the benefits coming from a number of other factors. They're relying on a new DynamIQ setup, more cache, faster memory, all mixing together to have an overall notable improvement. Going 64bit-only in microcode will have unseen benefits too. And the elephant in the room is the jump to TSMC-3NM node shrink, which will likely have frequency increases.
So comparing the QC 8g1 (Samsung 5nm) to the (TSMC-5nm) QC 8g1+ and QC 8g2 (+5nm-TSMC) and (TSMC-3NM) QC 8g3 will be a mixed bag.
Kangal - Monday, May 29, 2023 - link
A TCS23 (X4+720+520) with 1+5+2 configuration, only yields a +27% performance uplift at the same power, compared to TCS22 (X3+715+510) in 1+3+4 cluster.Something is miscalculated there!!!
They either mean:
1) TCS23 vs TCS23, with only difference being different configuration
2) TCS22 vs TCS22, with only difference being different configuration
3) TCS22 vs TCS23, and they meant PLUS an extra +27% performance on top of the architectural improvements
4) It's not a typo, and they really did mean you ONLY get +27% uplift total. Which doesn't make sense since they claimed the X4 uses -40% less energy than X3, whilst the A720 uses -20% less energy than A715, and the A520 uses -22% less energy than A530. Logically speaking if you just multiply the efficiency gains by the core quantities you get an impressive figure. Unless you divide that by the total cores, that gives you an average drop by -23% energy, but that's not the total. Unless the engineers or the marketers are utterly incompetent there at ARM, and they meant this -23% figure gets increased to -27% figure (+4% efficiency gain) just based on the cluster configuration difference. That's not a great improvement, it's negligible, and not substantial enough to require a new silicon stamp (which explains MediaTek).
1x40% + 5x20% + 2x22% = 184% / 8 = 23%
Doug_S - Monday, May 29, 2023 - link
There are so many factors changing like more L2 cache, supporting more L3 cache, faster memory, better processes and they don't tell you anything about what the differences are.If they said X3 with x cache, y DRAM on process z was compared to X3 with x cache, y DRAM on process z then you could assume the performance uplift was due to their architecture. But they are turning all those knobs so who knows what improvement comes from the core versus what is around the core and what node it is on.
Doug_S - Monday, May 29, 2023 - link
Ugh I meant X3 compared to X4 of course.Kangal - Tuesday, May 30, 2023 - link
I got that, but the architecture has been rather since the Cortex-A78. Just like how there was a long period of time since the release of the Cortex-A57 compared to the Cortex-A72. That extra time let ARM make a lot of big architectural improvements. In fact, it was pretty lengthy that we got Custom Cores developed by the likes of Nvidia, Qualcomm, Samsung, all which were vastly superior to the Cortex-A57 and they matched the subsequent release of the Cortex-A72.My biggest concern is the mistakes in their slides.
If you have a 1+3+4 TCS22 design, and you do nothing but change the A510 to A520, you should see an upgrade of 22% per core. So 22% x4 should see a +88% uptick in performance. Now compare that to the mere 27% upgrade they said if you upgraded all the core types (X4 / A720 / A520) and you went with a larger chipset with the 1+5+2 design. Something is clearly amiss.
Another solution to the riddle is they are using the problematic silicon from Samsung-5nm. Making a comparison between the flawed QC 8g1, against a new chipset using the same node, but upgrading the Core-types and the Cluster-design. Even then it's a bad excuse, because that would mean its barely competing against the 6-month old QC 8g2 (on TSMC node), and we collectively just ignore the existence of the MediaTek Dimensity chipsets.
I think we will have to wait to hear the announcement of next-gen chips for 2024, in the form of QC 8g3 and MTK D9400. Let's see their claimed battery life improvement, their performance improvement, and deduce the efficiency from there. Look at which silicon they're building upon (TSMC 4nm vs 5nm). And finally look at the in depth reviews from the likes of Anandtech/Andrei, Geekerwan, and Golden Reviewer.
iphonebestgamephone - Wednesday, May 31, 2023 - link
Techtechpotato instead of anandtech/andreiFindecanor - Monday, May 29, 2023 - link
ARM MTE and PAC are two different things, and I find it really silly to see them touted for use together.MTE steals eight pointer bits that would have been used for PAC, and on some implementations the bits for PAC would then be as few as 3.
You would better pick one or the other, depending on your protection scheme.
syxbit - Monday, May 29, 2023 - link
So Arm are still years behind Apple? And possibly will be slower than Nuvia too?I guess this just helps QUalcomm, as smaller companies have no choice. Either use slow off the shelf parts, or pay QCOMM for their superior chip (assuming Nuvia is as good as claimed.).
DanNeely - Thursday, June 1, 2023 - link
Blame some of the mainland China android forks. They've spent years trying to pretend 64 bit only was never going to happen and were nowhere near ready when last years x3 dropped support for 32 bit code.Arnulf - Monday, May 29, 2023 - link
"up for the 6/8-wide dispatch with of the X3"From ... width
Ryan Smith - Monday, May 29, 2023 - link
Thanks!GC2:CS - Tuesday, May 30, 2023 - link
Mediatek dimensity 93004xx4 + 4x A720 no little cores. 50% lower power, beats next gen Apple CPU (A17).
First time one ever with more than 3 X CPU’s ?
https://m.gsmarena.com/mediatek_dimensity_9300_tip...
iphonebestgamephone - Tuesday, May 30, 2023 - link
8cx gen 3 - 4x x1 + 4x a78tipoo - Thursday, June 1, 2023 - link
Given that A17 isn't out yet, how do we know?Zoolook - Sunday, June 4, 2023 - link
4 X4s would make for a very big chip, I doubt it, but we'll see, A17 is on N3 and Dimensity 9300 will be on N4P so also doubt that.NextGen_Gamer - Tuesday, May 30, 2023 - link
Is there going to be another follow-up article about the new Immortalis-G720 GPU?brucethemoose - Tuesday, May 30, 2023 - link
^I think the GPU is becoming the more critical part in phones... I hate to downplay CPU advances, but what does being faster than an X1 really get you on mobile these days?
GPUs, on the other hand, are the bottleneck for running local AI. Flagships can already run 7B LLMs and other generative models reasonably well, but every ounce of extra GPU speed allows for significantly better inference. They are also the bottleneck for VR/AR and ports of PC/console games.
nandnandnand - Tuesday, May 30, 2023 - link
The real advance for CPU might be locking the performance in place but lowering the power usage. Which is why we're hearing about Dimensity 9300 supposedly packing four Cortex-X4 cores and four Cortex-A720 cores, with no presence of Cortex-A520. In a smartphone SoC.Shouldn't these flagships being using their dedicated AI accelerators instead of the GPU for inference?
TheinsanegamerN - Wednesday, May 31, 2023 - link
AI accelerators are just that, accelerators. You still need heavy compute power, and that comes from GPUs.nandnandnand - Wednesday, May 31, 2023 - link
I don't think an iGPU is significantly more powerful than an AI accelerator.Ryan Smith - Thursday, June 1, 2023 - link
Yes, there will be. The embargo lining up with Computex stretched us a bit thin, so the GPU stuff has been punted to next week.ikjadoon - Saturday, June 3, 2023 - link
LOVE to read an in-depth article like this on AnandTech again!Give us more!!