Question Why don't we have a massive push for ARM chips in desktop computers and laptops?

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

ibex333

Diamond Member
Mar 26, 2005
4,086
119
106
Note: The following may sound like idiocy, and I admit, I have no clue what the hell I am talking about, but I think its an interesting discussion nevertheless...


Can someone please explain to a complete noob, in layman terms, WHY cant we start using ARM chips instead of Intel? They sure seem a hell of a lot faster and better than Atoms at least! And in many cases faster than Celerons.

Look, I get it, ARM does not support x86 apps, and forget about 64bit... The instruction sets are different. Yadda, yaddaa, yadda. I heard it all before. But they ported Half Life to Android! They emulated a Playstation 3 on PC! They even got Windows 95 to run on gaming handhelds and managed to run Linux on Android phones! Hell, even iOS can run Android now. An unheard of thing five years ago.

So whats the matter? MAKE x86 apps run naively on ARM CPUs! MAKE the same instructions sets for all CPUs regardless of devices they are used for... Just make it happen. And also, why is it, that ARM CPUs were not designed right from the start, with an ability to run x86 apps?

I am aware, that at least one manufacturer, Hewlett Packard, released a laptop that runs on a Snapdragon CPU. It basically "emulates" x86 apps, and I believe the platform is called "Windows on ARM" or something like that. Because code is not ran naively, but emulated, performance is abysmal, but battery life is fantastic. Whats really tempting to me, is that many times, the graphical capabilities of some high end ARM chips seem to far surpass what Intel offers. The gaming potential is immense. But because smartphones don't have full size keyboards and mice attached to them, and do not have PC like games on them, that potential is very limited. But it does not have to be, if we had something like a giant, dedicated tablet, with a ton of usb ports for peripherals and a huge screen. Something like this could potentially be much better than any console and better than many low end gaming PCs.

Am I missing something here? Am I talking complete nonsense? Lets discuss.
 
Last edited:

DrMrLordX

Lifer
Apr 27, 2000
21,582
10,784
136
That's a mischaracterization of my statement. My main point is that there is a political battle between other ARM vendors, not against ARM Holdings.

Okay, let's start over. Where's the documentary evidence of there being a political battle between ARM vendors over SVE2? Fujitsu arguably started all this (SVE was supposedly their baby), but I see nobody from the other vendors bashing them; filing lawsuits; or trying to influence ARM Holdings to keep the standard out of their designs. Remember, ARM Holdings ultimately decides what will or won't go into their future designs. Infighting between ARM vendors won't really change those plans unless someone changes ARM Holdings' mind about something.

Also, ARM is going to "make money off SVE2" the same way they've always made money. Release new designs and charge licensing fees (or continue charging for design licenses for the shops that want to use them). That's easy.

Do you think having different instruction encoding means different execution units?

My general understanding of it was that the same FMAC would be utilized for NEON or SVE2 instructions, once they had been decoded. x86 CPUs sort of do this already, I think? Older 64-bit SIMD and AVX instructions all get handled by the same FMAC. AMD did this with AVX and XOP on the CPUs that supported both (AMD no longer supports XOP). It would be goofy as hell to have separate NEON and SVE/SVE2 pipes on the same CPU.

Or do you think that decoding units are larger than execution units?

I thought decoding units were tiny. At least on x86, I've been told they are. Shouldn't be much different on ARM.
 

Nothingness

Platinum Member
Jul 3, 2013
2,371
713
136
My general understanding of it was that the same FMAC would be utilized for NEON or SVE2 instructions, once they had been decoded. x86 CPUs sort of do this already, I think? Older 64-bit SIMD and AVX instructions all get handled by the same FMAC. AMD did this with AVX and XOP on the CPUs that supported both (AMD no longer supports XOP). It would be goofy as hell to have separate NEON and SVE/SVE2 pipes on the same CPU.
That's it. An FMA is an FMA no matter whether it's SVE or NEON or AVX so you can share datapaths.

I thought decoding units were tiny. At least on x86, I've been told they are. Shouldn't be much different on ARM.
That's even more the case on ARM. Decoding is not a problem.

BTW AVX-512 decoding is different from SSE2/AVX/AVX2 (VEX vs EVEX) so I doubt decoding can be shared. So that's the same situation as NEON vs SVE2.

One of the main issues with vector instructions is the size of the register bank in particular when you have out of order execution (for instance Haswell has 144 256-bit AVX registers, that's massive; I wonder how many physical registers Intel AVX-512 chips have). But that obviously applies in the same way to all ISA.
 
  • Like
Reactions: moinmoin

amrnuke

Golden Member
Apr 24, 2019
1,181
1,772
136
In your same link I quoted below. This is kind of why I was wondering if RISC vs CISC (or ARM vs x86 vs MIPS vs RISCV etc) is important these days or not for the efficiency and performance of cpu. Or if its really all about the microarchitecture underneath all of that.
No it's almost entirely microarchitecture and chip design, and most importantly an efficient cache hierarchy. It is fun to consider RISC vs CISC for the purposes of academics and discussion. These days CISC is just a wrapper for the RISC instructions "x86" cores operate on. So an x86 chip is basically fed x86 instructions, uop decodes them to RISC instructions, and the execution units work on the RISC instructions. ARM just does away with much of the uop decode need (though it does still use it).

So the execution units on a Zen2 are fed basically the same instructions execution units on ARM are. The difference is that Zen2 and Intel chips require a uop decode area to translate instructions sent by applications. That uop area is small, but does take up real estate, does become part of the execution of a command, and does take up power. But increasingly in modern chips, that penalty is small and doesn't offset the benefit of native compatibility with x86 applications, which is a huge reason x86 as an ISA still exists - inertia.

Cache hierarchy, size, and speed are very important. I think they are one of the critical differences between A13 Lightning cores and Zen2 cores.
A13 - 128K(*) L1I and L1D, 8MB (well... maybe only 6MB) shared L2, and 16MB SLC (kind of an L3).
Zen2 - 256K L1I and L1D, 4MB L2, and 16MB shared L3 x 2 CCX
They don't look that different.
But Zen2 has 8 cores to feed and A13 only 2 fast cores.
Each A13 Lightning core when running alone has 128K L1I and 128K L1D -- ~6MB L2 -- 16MB SLC
Each Zen2 core when operating on its own has 32K L1I and 32K L1D -- 512KB L2 -- 16MB L3
Those L1 and L2 differences are huge IMO, though I'll leave it up to someone else to do a deep dive.

* unclear to me if 128K refers to one core or both cores combined, let's assume lower)
 
Last edited:

NobleX13

Member
Apr 7, 2020
27
18
41
Another driving force behind why this doesn't exist yet is Intel. They have deep ties (and deep pockets) straight to the boardroom of every major PC OEM on the planet. It's very difficult for AMD to get more than a certain foothold in the big three (HP, Dell, Lenovo) because of the OEM deals that Intel gives to volume customers. It's rumored that a Coffee Lake Core i7 CPU only costs Intel $30 or so to make, and they can pass on tremendous savings to OEMs to drive out competition. That's the advantage of having a monolithic die design in an established 14nm process in fabs that you wholly own.

If AMD has a slow and steady battle to claim a percentage point or two of the OEM market each year, imagine how difficult it must be to get a non-x86 product out there.
 

DrMrLordX

Lifer
Apr 27, 2000
21,582
10,784
136
It's rumored that a Coffee Lake Core i7 CPU only costs Intel $30 or so to make, and they can pass on tremendous savings to OEMs to drive out competition.

While that may be true, Intel has had their pants sued off (in the EU, anyway) over it. Actually what really got them nailed to the wall was threatening to withdraw the discounts if OEMs carried competing products. It cost them less than they saved by stifling competition but still. If they're doing it again in the same fashion (or engaged in more-complicated schemes, like contra revenue) then that would be quite a scandal, especially given all the other circumstances.
 

ThatBuzzkiller

Golden Member
Nov 14, 2014
1,120
260
136
Okay, let's start over. Where's the documentary evidence of there being a political battle between ARM vendors over SVE2? Fujitsu arguably started all this (SVE was supposedly their baby), but I see nobody from the other vendors bashing them; filing lawsuits; or trying to influence ARM Holdings to keep the standard out of their designs. Remember, ARM Holdings ultimately decides what will or won't go into their future designs. Infighting between ARM vendors won't really change those plans unless someone changes ARM Holdings' mind about something.

Also, ARM is going to "make money off SVE2" the same way they've always made money. Release new designs and charge licensing fees (or continue charging for design licenses for the shops that want to use them). That's easy.

I think you misunderstand, ARM vendors don't have to be necessarily pro-active in supporting the proliferation of SVE2 OR against the proliferation of SVE2.

That's what I meant by they "don't care" but it doesn't mean that they're just going to give the green light to ARM Holdings just to silently integrate it into their core designs. You should interpret their behaviour as being noncommittal.

That's it. An FMA is an FMA no matter whether it's SVE or NEON or AVX so you can share datapaths.

That's not how it works otherwise emulation would be trivialized problem.

Just as a simple case there are legacy SSE instructions with REX coding which are incompatible VEX coded SSE. Doing transitions between legacy SSE and VEX coded SSE will incur penalties on Intel systems. Intel had to add state tracking hardware to emulate the state transitions between the different instruction encodings and they see significant performance hits with applications doing this.

SVE2 and NEON have vastly different instruction encoding to each other. The only thing that can be shared between them are the vector registers. SVE/SVE2 introduces several foreign registers like predicate registers, a first fault register, and exception level specific registers. It must mean that SVE/SVE2 has a totally different hardware state tracker and state machine to handle the control flow logic. Can you even mix SVE/SVE2 and NEON instructions within the same kernels like you can with legacy SSE and AVX on x86 ?

Modern compilers have already started emulating hand written MMX assembly into SSE instructions so it's a real possibility that if you wanted to execute NEON instructions on top of SVE2 then you'd have to apply similarly ugly hacks.

That's even more the case on ARM. Decoding is not a problem.

BTW AVX-512 decoding is different from SSE2/AVX/AVX2 (VEX vs EVEX) so I doubt decoding can be shared. So that's the same situation as NEON vs SVE2.

One of the main issues with vector instructions is the size of the register bank in particular when you have out of order execution (for instance Haswell has 144 256-bit AVX registers, that's massive; I wonder how many physical registers Intel AVX-512 chips have). But that obviously applies in the same way to all ISA.

EVEX is just a 4-byte extension to VEX. It's first 3 bytes of encoding are EXACTLY the same as VEX. EVEX is a straight up superset of VEX so practically everything about their hardware implementation can be shared. The same cannot be said for SVE2 which has an incompatible encoding with NEON unless you wanted to use less than ideal solutions like Transmeta CPU designs or emulation.

At that point you might as well just implement dedicated NEON logic instead of employing some less efficient emulation solution which would be far more helpful in mobile devices but at that point why would they even contemplate implementing 2 competing SIMD technology ? ARM vendors aren't going to compromise their own interests just solely for the greater good of the ecosystem. "Profit sharing" is also another issue with SVE2. What if vendor's A and B decided early on to implement SVE2 at a great cost but vendor C decided to withhold doing so for a long while before the functionality gained traction ? Vendor C dominates higher end markets despite having similar unit sales to vendor A or B but Vendor C then decides to finally implement SVE2 and then starts becoming the preferred vendor for using SVE2 applications despite vendor A/B subsidizing the initial cost of standardizing SVE2 for vendor C ? In this way vendor C has effectively 'mooched' off the efforts of vendor A and B by eroding away their potential profits. (It's the exact same dilemma AMD faced when they had to share x86-64 with Intel but then the latter went on to dominating with some of the former's work)

The logic that was used for SVE2 could've been more individually beneficial for the vendors themselves. Qualcomm could've implemented a more sophisticated modem which would've furthered their advantage in mobile connectivity, Apple/Huawei could've implemented some more custom logic as a unique advantage, and Nvidia could've used it to implement a bigger GPU in their Tegra product line. It's naive to assume that a group of corporations will just blindly share their costs/work with each other out of good faith when they are in it to profit for themselves.
 
  • Like
Reactions: Carfax83

DrMrLordX

Lifer
Apr 27, 2000
21,582
10,784
136
I think you misunderstand, ARM vendors don't have to be necessarily pro-active in supporting the proliferation of SVE2 OR against the proliferation of SVE2.

That's what I meant by they "don't care" but it doesn't mean that they're just going to give the green light to ARM Holdings just to silently integrate it into their core designs. You should interpret their behaviour as being noncommittal.

So their resistance to SVE2 manifests itself as being noncommittal? Also, since when did ARM Holdings wait for a green light from anyone to roll out new core designs?
 

moinmoin

Diamond Member
Jun 1, 2017
4,933
7,618
136
SVE2 and NEON have vastly different instruction encoding to each other. The only thing that can be shared between them are the vector registers. SVE/SVE2 introduces several foreign registers like predicate registers, a first fault register, and exception level specific registers. It must mean that SVE/SVE2 has a totally different hardware state tracker and state machine to handle the control flow logic. Can you even mix SVE/SVE2 and NEON instructions within the same kernels like you can with legacy SSE and AVX on x86 ?

Modern compilers have already started emulating hand written MMX assembly into SSE instructions so it's a real possibility that if you wanted to execute NEON instructions on top of SVE2 then you'd have to apply similarly ugly hacks.
As I understand SVE2 should be able to completely replace the use of NEON.

"- SVE2 adds NEON™-style fixed-point DSP/multimedia plus other new features.
- Performance parity and beyond with classic NEON DSP/media SIMD.
"

Slide 11 and 29 (plenty usage, performance etc. comparisons in-between and after).
 

ThatBuzzkiller

Golden Member
Nov 14, 2014
1,120
260
136
So their resistance to SVE2 manifests itself as being noncommittal?

You could describe it that way for the most part.

Also, since when did ARM Holdings wait for a green light from anyone to roll out new core designs?

At the end of the day it's the ARM customers who will demand the bare minimum from ARM Holdings so they can still decide to omit SVE2 if they don't like it.
 

ThatBuzzkiller

Golden Member
Nov 14, 2014
1,120
260
136
As I understand SVE2 should be able to completely replace the use of NEON.

"- SVE2 adds NEON™-style fixed-point DSP/multimedia plus other new features.
- Performance parity and beyond with classic NEON DSP/media SIMD.
"

Slide 11 and 29 (plenty usage, performance etc. comparisons in-between and after).

Doesn't mean that it's a superset of NEON. It just means that ARM Holdings is trying to improve the symmetry of SVE with respect to NEON. SVE initially lacked some DSP/multimedia specific instructions for acceleration and SVE2 exists to extend equivalent functionality as found in NEON.

It's a similar deal between AVX and AVX2. AVX was mostly just extending floating point operations to 256-bit vectors and AVX2 does the same with integer operations.
 

Shivansps

Diamond Member
Sep 11, 2013
3,835
1,514
136
The fact there is not a massive push for ARM outside low power devices is what makes me wonder if ARM is really that power efficient compared to x86 when it is really being pushed to the limits.

For example, AMD new APUs for mobile market, there is a ARM CPU that performs like the 4900HS while using less power? I know there are ARM cpu that may have better IPC or perform better at 2Ghz or so, thats not the point.
 

amrnuke

Golden Member
Apr 24, 2019
1,181
1,772
136
The fact there is not a massive push for ARM outside low power devices is what makes me wonder if ARM is really that power efficient compared to x86 when it is really being pushed to the limits.

For example, AMD new APUs for mobile market, there is a ARM CPU that performs like the 4900HS while using less power? I know there are ARM cpu that may have better IPC or perform better at 2Ghz or so, thats not the point.
They are not there yet. But historically we have seen what we thought were niche low-power uarch designs translated up to high-power chips, e.g. Intel. So we can neither write off Apple's Lightning cores or ARM's A77 as non-scalable, nor can we expect them to replicate Intel's success at doing so. Only time will tell.

However, it's not just that ARM / its ISA has great IPC. Even if you look at raw work done, the A13 core at 2.66 GHz is about even with 9900K at 5.0 GHz on SPECint - not even adjusting for its clock deficit. It is roughly 30% behind in SPECfp without adjusting for clock deficit as well. That's remarkable.

So if we are looking to the future, ARM's Cortex line is about 2 generations behind Apple's Axx chips. That means in a couple of years we should see something with Cortex that can meet the current Zen2 / Intel power. Then again, at that point, ARM is competing against Zen4 and possible widespread process shrink from Intel.

We cannot tell the future, but it's heartening to see the acceleration of processing pushed by AMD and ARM and Apple. Intel is stagnant, but hopefully they too start moving. The competition will only help us consumers.
 
Last edited:
  • Like
Reactions: Tlh97

AkulaMD

Member
May 20, 2017
56
17
81
For example, the Realtek RTD1296 is a 4-core Cortex-A53 which is the small core used in medium range smartphone SoCs.
Sorry to disagree, but in this few years 4-Core ARM Cortext A-53 SoCs (with no big core) has been sitting at the lowest end of the smartphone SoCs range and soon to be replaced totally with it newer brethren, Cortex A-55 that has been in the market for quite sometime now.

But I agree with the rest of your post.
 

DrMrLordX

Lifer
Apr 27, 2000
21,582
10,784
136
You could describe it that way for the most part.

Hmm. Seems like not much opposition then. But enough about that.

At the end of the day it's the ARM customers who will demand the bare minimum from ARM Holdings so they can still decide to omit SVE2 if they don't like it.

They can do a lot of things to modify standard core designs if they like. Unless ARM Holdings does something insane like mandate 512b SVE2 pipes for all their future designs, I don't think ARM vendors will spend much time or expense stripping out decoder blocks just to make sure their SoCs have only NEON. The amount of silicon that will be required to support SVE2 should be trivially small. I could see things getting a little messy on high-end SoCs with "big" cores supporting one or more 256b or 512b SVE2 pipes and "small" cores supporting 128b pipes, but there are (apparently) relatively-simple ways around that.

The fact there is not a massive push for ARM outside low power devices

There kind of is, but only in the server sector. Outside of that, we have Qualcomm doing Win10 on ARM and supposedly Apple moving some of their laptops to ARM in 2021.
 

Nothingness

Platinum Member
Jul 3, 2013
2,371
713
136
Sorry to disagree, but in this few years 4-Core ARM Cortext A-53 SoCs (with no big core) has been sitting at the lowest end of the smartphone SoCs range and soon to be replaced totally with it newer brethren, Cortex A-55 that has been in the market for quite sometime now.

But I agree with the rest of your post.
Sorry, I wasn't clear, I meant the small core of big.LITTLE SoC used in medium range smartphones :)
 

Nothingness

Platinum Member
Jul 3, 2013
2,371
713
136
The fact there is not a massive push for ARM outside low power devices
ARM is definitely getting out of low power devices (AWS, Fujitsu, Qualcomm/MS, etc.). It's not massive but in an established market things take a long time to move no matter what the benefits are (take AMD vs Intel as an example).

is what makes me wonder if ARM is really that power efficient compared to x86 when it is really being pushed to the limits.
I think that pushed to the limit, that's correct. In the same way that an ARM chip pushed to the limit would perform as well as an x86 chip. But that's a theoretical question as it always is the case at limits.

But do you need to push a CPU to limits to have a good CPU? If we're not talking about limits, a core that's not been designed to reach the absolute highest single thread performance will be more power efficient than the one that tries to maximize perf.

For example, AMD new APUs for mobile market, there is a ARM CPU that performs like the 4900HS while using less power? I know there are ARM cpu that may have better IPC or perform better at 2Ghz or so, thats not the point.
Is really 4900HS pushing x86 to the limits? I don't think so. Anyway even if it's not pushing to the limits, I don't think there's a similar ARM CPU on the market, as no SoC maker (outside server of course) has made a chip with such high power requirements.
 

Nothingness

Platinum Member
Jul 3, 2013
2,371
713
136
That's not how it works otherwise emulation would be trivialized problem.
What does emulation have to do with it? Do you mean the semantics of one FMA operation on SSE is not the same as on AVX? Because it is the same on SVE and NEON so you can use the same multiplier.

Just as a simple case there are legacy SSE instructions with REX coding which are incompatible VEX coded SSE. Doing transitions between legacy SSE and VEX coded SSE will incur penalties on Intel systems. Intel had to add state tracking hardware to emulate the state transitions between the different instruction encodings and they see significant performance hits with applications doing this.

SVE2 and NEON have vastly different instruction encoding to each other. The only thing that can be shared between them are the vector registers.
What didn't you understand in the datapath word? I thought its meaning was clear enough: it's the part that does the computation, not the one doing the control. I insist that datapaths can be shared between NEON and SVE2.

SVE/SVE2 introduces several foreign registers like predicate registers, a first fault register, and exception level specific registers. It must mean that SVE/SVE2 has a totally different hardware state tracker and state machine to handle the control flow logic.
Didn't AVX-512 introduce predication? Even if it's in the encoding it has impact on control logic and on datapaths. So is AVX-512 unable to reuse any AVX(2) block?

Can you even mix SVE/SVE2 and NEON instructions within the same kernels like you can with legacy SSE and AVX on x86 ?
What's the point of mixing SSE and AVX? Is AVX lacking instructions that SSE has?

Modern compilers have already started emulating hand written MMX assembly into SSE instructions so it's a real possibility that if you wanted to execute NEON instructions on top of SVE2 then you'd have to apply similarly ugly hacks.
ARM never said that SVE2 replaces NEON. Supporting both at the same time is not that costly as long as you share datapaths.

EVEX is just a 4-byte extension to VEX. It's first 3 bytes of encoding are EXACTLY the same as VEX. EVEX is a straight up superset of VEX so practically everything about their hardware implementation can be shared.
I'll take your word for it, I'm not familiar enough with Intel encoding (and rather be not :D).

The same cannot be said for SVE2 which has an incompatible encoding with NEON unless you wanted to use less than ideal solutions like Transmeta CPU designs or emulation.
Encoding is not an issue. I wonder why you think it matters that much especially when x86 is known to just stink in that department.
 

Shivansps

Diamond Member
Sep 11, 2013
3,835
1,514
136
There kind of is, but only in the server sector. Outside of that, we have Qualcomm doing Win10 on ARM and supposedly Apple moving some of their laptops to ARM in 2021.

Server is different, i would expect a push there first, specially because there is demand for non high power CPUs in server market.

Is really 4900HS pushing x86 to the limits? I don't think so. Anyway even if it's not pushing to the limits, I don't think there's a similar ARM CPU on the market, as no SoC maker (outside server of course) has made a chip with such high power requirements.

Is not, but is a nice example of what x86 can do today in the mainstream market whiout having to go too far.
And thats the point, ARM really need to be better than x86 in high performance and high power in order to BE CONSIDERED as a alternative to x86 on mainstream.

Having a 8C ARM cpu that performs really good at low power, but when demanded it consumes petty much like an x86 cpu to get near the same performance, or it has lower power but less performance. While also having the arch barrier... you cant expect that to prosper outside some niche units.
In server they are going to do better for sure, but not on mainstream.
 
  • Like
Reactions: Thunder 57 and Glo.

Denly

Golden Member
May 14, 2011
1,433
229
106
As a non technical person, my 2c. Another reason is MS's ARM afford or lack of never took off UWP, WP, W10M, RT, WoA just to name a few. For whatever reason user, developer, mega corp(Google) and MS itself(Nadella) want nothing to do with it. If those took off I would imagine there would be alot more ARM devices around.
 

Shivansps

Diamond Member
Sep 11, 2013
3,835
1,514
136
As a non technical person, my 2c. Another reason is MS's ARM afford or lack of never took off UWP, WP, W10M, RT, WoA just to name a few. For whatever reason user, developer, mega corp(Google) and MS itself(Nadella) want nothing to do with it. If those took off I would imagine there would be alot more ARM devices around.

That would help to remove the software stack barrier for new software, but the problem, specially for PC software that runs on PCs and notebooks, is that solutions like UWP have a performance cost (and other limits, like being tied up to MS store).
Other issue is that people tends to use old software as well, some dating back a decade or more.
But MS is doing things right, they are trying to push for UWP for common apps and for anything else they have an optimised emulation subsystem to run x86 executables on ARM CPUs... once MS launches the ability to run x86_64 apps on ARM ill say there is not a software barrier anymore.

But is that is not going to be enoght, ARM needs to get to 3.5-4.5Ghz area with up to 8 big cores and provide equal or better CPU and GPU perf AT lower power, this is key, whiout this no one will ever bother. I would be more than willing to buy a ARM cpu with 6 big cores with similar CPU perf to 4600U and higher GPU perf if power use is lower. (And MS had x86_64 emu ready). But neither ARM cpus or MS is there yet.

The final issue would be drivers, once ARM CPU and MS had done their part, it will come a long, uphill battle with device drivers.

So, its going to take some time.
 
Last edited:

eek2121

Platinum Member
Aug 2, 2005
2,904
3,903
136
The efficiency just isn’t there. I spent a lot of time looking at ARM, specifically Apple’s variants. What I found is that in order for Apple to come close to say, a Ryzen 4600U in terms of overall performance, they would have to have a chip with a 15W TDP, which is the TDP of the 4600U. The 4600U appears to be cheaper (half the cost?) than the A12X or A13, much less any larger variant. However, Apple does not sell their chips to 3rd parties, so there is no way to know how much of that is the “Apple tax”.

Note that I conducted my analysis based on the move from Apple 12 to A12X. My analysis was based on public and private benchmark data, and technical details of the chip itself.

The A13 is a different beast and I am still digging into the nuances of the chip. I am not ready to share the details yet, but I will just say this: Apple had a very good reason for sticking with the A12 for this year’s iPad refresh.

What about the rest of ARM? They are still playing catchup.

That being said, I would love it if manufacturers would use socketed chips and standard form factors.
 

DrMrLordX

Lifer
Apr 27, 2000
21,582
10,784
136
That being said, I would love it if manufacturers would use socketed chips and standard form factors.

Hell even SBCs with soldered chips are fine as long as you can get something recent. Want A72 in an SBC? No? Too bad, it's still nearly impossible to get A76 (much less A77) outside of a phone.
 

chrisjames61

Senior member
Dec 31, 2013
721
446
136
Note: The following may sound like idiocy, and I admit, I have no clue what the hell I am talking about, but I think its an interesting discussion nevertheless...


Can someone please explain to a complete noob, in layman terms, WHY cant we start using ARM chips instead of Intel? They sure seem a hell of a lot faster and better than Atoms at least! And in many cases faster than Celerons.

Look, I get it, ARM does not support x86 apps, and forget about 64bit... The instruction sets are different. Yadda, yaddaa, yadda. I heard it all before. But they ported Half Life to Android! They emulated a Playstation 3 on PC! They even got Windows 95 to run on gaming handhelds and managed to run Linux on Android phones! Hell, even iOS can run Android now. An unheard of thing five years ago.

So whats the matter? MAKE x86 apps run naively on ARM CPUs! MAKE the same instructions sets for all CPUs regardless of devices they are used for... Just make it happen. And also, why is it, that ARM CPUs were not designed right from the start, with an ability to run x86 apps?

I am aware, that at least one manufacturer, Hewlett Packard, released a laptop that runs on a Snapdragon CPU. It basically "emulates" x86 apps, and I believe the platform is called "Windows on ARM" or something like that. Because code is not ran naively, but emulated, performance is abysmal, but battery life is fantastic. Whats really tempting to me, is that many times, the graphical capabilities of some high end ARM chips seem to far surpass what Intel offers. The gaming potential is immense. But because smartphones don't have full size keyboards and mice attached to them, and do not have PC like games on them, that potential is very limited. But it does not have to be, if we had something like a giant, dedicated tablet, with a ton of usb ports for peripherals and a huge screen. Something like this could potentially be much better than any console and better than many low end gaming PCs.

Am I missing something here? Am I talking complete nonsense? Lets discuss.
No compelling reason to.
 

AkulaMD

Member
May 20, 2017
56
17
81
Hell even SBCs with soldered chips are fine as long as you can get something recent. Want A72 in an SBC? No? Too bad, it's still nearly impossible to get A76 (much less A77) outside of a phone.
Can't agree more. The best SBC i can actually find right now is "Odroid N2". The SBC runs on an Amlogic S922X with 4x 1.8GHz -A73 and 2x 1.9GHz -A53 cores. The same goes with "Khadas VIM 3", it runs on another variant of the same Amlogic S922X (A311D).