• 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."

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

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

ThatBuzzkiller

Golden Member
Nov 14, 2014
1,052
179
106
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.
FMA doesn't even exist on SSE ...

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.
It's actually not that simple. The vast majority of SVE's data processing instructions are destructive compared to NEON so you'd have to implement new wiring in hardware to support to support this. That's assuming no other asymmetry between SVE and NEON such as different precision behaviour which would involve even more modifications as well.

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?
AVX-512 does have predication but it's overhead is small compared to a vector length agnostic model like SVE. Predication is beneficial if you want to avoid large branch misprediction penalties but this cost has to be amortized across larger vectors and introducing predication with a 128-bit vector length makes no sense ...

There's more overhead involved from switching between variable length vectors than moving between a fixed number of lanes and making the hardware do it for you instead of changing the code is bad news ...

What's the point of mixing SSE and AVX? Is AVX lacking instructions that SSE has?
For compatibility ? Is this not obvious ?

ARM never said that SVE2 replaces NEON. Supporting both at the same time is not that costly as long as you share datapaths.
It wouldn't matter because you'd also have to support SVE as well since SVE2 is actually superset of SVE and builds upon it's instruction encoding.

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.
It's a massive issue because ARM Holdings had to make the trade-off between having predication or constructive forms where the destination register is distinct from it's source operands. SVE's instruction set consists of destructive predicated instructions and constructive unpredicated instructions while on AVX-512 nearly all of it's instructions are both predicated and constructive. Instruction encoding has a direct effect on the features of the instruction set.

The life of a compiler is very complicated with SVE in comparison to AVX-512. Having a destructive syntax means that the compiler needs to copy the data in some of the registers leading to increased register pressure. Not having predication makes auto-vectorization more difficult. SVE's instruction encoding could easily run out of space soon to add more features.
 
Last edited:

DrMrLordX

Lifer
Apr 27, 2000
17,132
6,132
136
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).
So they've got A73 SBCs out there now? Huzzah. Maybe we'll have A77 SBCs in . . . 2022? Maybe? Rockchip's 3588 has been pushed back so far, I don't think we'll see it until 2021, and I'm hoping Pine will pick up that for their product line. And that's still going to be A76 unless they decide to surprise us all.
 

Carfax83

Diamond Member
Nov 1, 2010
6,051
850
126
@ThatBuzzkiller, thanks for clearing up the confusion surrounding SVE2 and AVX-512. AVX-512 has been criticized heavily on these forums (usually by ARM proponents) while SVE2 is often seen as superior despite it not even being implemented yet.

I've often wondered that if vector length agnostic models were so much better, why didn't Intel do it on their CPUs? Now I know they had good reasons for not doing so.
 

AkulaMD

Member
May 20, 2017
52
16
51
So they've got A73 SBCs out there now? Huzzah. Maybe we'll have A77 SBCs in . . . 2022? Maybe? Rockchip's 3588 has been pushed back so far, I don't think we'll see it until 2021, and I'm hoping Pine will pick up that for their product line. And that's still going to be A76 unless they decide to surprise us all.
Yes. A73 on 12nm manufacturing process. Was hoping to get my hands on RK3588 but as you said, it has been pushed back. At this rate I'm not too sure if we can see A77 SBC (in volume) even in 2022. Especially considering the economic fallout from COVID-19.
 

ThatBuzzkiller

Golden Member
Nov 14, 2014
1,052
179
106
Why is that a "massive issue"?
It means less opportunities to make a feature rich ISA. Both ARM and x86 have to come to terms with their limited instruction encoding space and they must make the best of it when adding new features. SVE/SVE2 has a limit of 28 bits of encoding space while AVX-512/EVEX has a limit of 32 bits of encoding space ...

With AVX-512, I'm liking that I can just use predication/masking without needing the destination register to overwrite the source operand. It makes for a simpler compiler design too. Sure AVX-512 may not have the opportunity of forward compatibility with wider vectors but in many other ways it is more powerful than SVE/SVE2 from a feature standpoint ...
 
  • Like
Reactions: Carfax83

DrMrLordX

Lifer
Apr 27, 2000
17,132
6,132
136
It means less opportunities to make a feature rich ISA.
I've heard that complaint about barebones RISC-V, but not ARM. SVE being destructive doesn't seem like a big issue either. You wouldn't want to issue NEON and SVE2 instructions at the same time in the same register space, but used seperately, it should be no problem.
 

Shivansps

Diamond Member
Sep 11, 2013
3,221
837
136
That being said, I would love it if manufacturers would use socketed chips and standard form factors.
Once Microsoft has x86_64 support on ARM im convinced they will start selling Windows 10 ARM licenses. With that done they really need to come up with a shared socket, just like what "Socket 7" was. That will be their door into mainstream. Massive catch up game and performance issues will follow, but they need MS to sell ARM licenses of Windows to even start.
 

Shivansps

Diamond Member
Sep 11, 2013
3,221
837
136
What's the point of that?
Able to run full Windows software stack on ARM Windows, incluiding all games. Software -and games- has been moving out of x86 in the last few years to the point they dont even have x86 builds. MS knows they cant fully depend on UWP outside some niche markets on mainstream, they already tried and failed, thats why they enabled x86 software on ARM, x86_64 follows.
 

Shivansps

Diamond Member
Sep 11, 2013
3,221
837
136
Have you considered the pitfalls of trying to decode x86-64 instructions on an ARM CPU?
No, but MS did a good job with running x86 on ARM all things considered, it definately runs way better than any "QEMU" attempt with Wine on Linux. Whats important here is that software do RUN with usable performance. Software will start coming with native builds once Windows 10 ARM become something more than a experiment.
 

Torn Mind

Diamond Member
Nov 25, 2012
5,090
482
126
The Surface and Surface 2 died because the software that runs on Windows did not for Windows on ARM.
 

TheELF

Diamond Member
Dec 22, 2012
3,244
385
126
Software will start coming with native builds once Windows 10 ARM become something more than a experiment.
Native builds will not have much better performance because you do have to use multiple sequential loops of instructions that ARM does have to recreate instructions that x86 x64 have natively.

ARM has been around since the 80ties, it's not an experiment it's a well established thing that is designed for specific things and does these specific things very well.

It's like using a xeon phi as a GPU,if something isn't designed to do something it will do it very badly,there is no way around that.

ARM on mobile will have the same fate that ARM on desktop had at some point desktop CPUs will catch up on the performance per watt front and ARM will be obsolete.
 

DrMrLordX

Lifer
Apr 27, 2000
17,132
6,132
136
No, but MS did a good job with running x86 on ARM all things considered, it definately runs way better than any "QEMU" attempt with Wine on Linux. Whats important here is that software do RUN with usable performance. Software will start coming with native builds once Windows 10 ARM become something more than a experiment.
You're comparing software emulation/virtualization to adding decode hardware to a CPU.
 
  • Haha
Reactions: DisEnchantment

Tup3x

Senior member
Dec 31, 2016
507
375
136
Since when? All they're doing is using software.
I meant in general getting x86-64 applications to work on ARM and obviously it's software. Judging by your comment it was rather unclear what you meant. In any case they are working on getting 64-bit x86 applications to work and they are working on it.
 

DrMrLordX

Lifer
Apr 27, 2000
17,132
6,132
136
I meant in general getting x86-64 applications to work on ARM and obviously it's software. Judging by your comment it was rather unclear what you meant. In any case they are working on getting 64-bit x86 applications to work and they are working on it.
How was it unclear? @Shivansps wants to put decode hardware directly on the CPU. I was responding to his comment. Legal hurdles aside, the differences between a RISC and CISC design mean that it would probably take more than just adding a decode unit to get an ARMv8 CPU to handle x86 instructions "natively".

The big problems I see are that they use different numbers of registers and different numbers of addressing modes. I don't have expert knowledge beyond that, but needless to say, trying to handle x86 "in hardware" on ARM could wind up being a mess.
 

Topweasel

Diamond Member
Oct 19, 2000
5,354
1,540
136
Then what do you mean? They've already got "x86_64 support on ARM" by way of emulation. The only way they could do any better is to execute x86_64 instructions natively. Which is something you'd not want to attempt with an ARM SoC.
No as of right now MS only has 32bit X86 emulation on ARM. He wants MS to get to the point they can do 64bit and its not there yet. I guess it goes both ways. Sure MS does have it "working" but its not as seamless and quick as 32bit on ARM.
 

Topweasel

Diamond Member
Oct 19, 2000
5,354
1,540
136
The Surface and Surface 2 died because the software that runs on Windows did not for Windows on ARM.
Well it was the Surface RT and Surface RT 2. It died for about a dozen reasons. Unlike the Surface X implementation, Surface RT ran a recompiled Windows meant solely for ARM, it was back when ARM CPU's had no where not even close to Atom/Netbook compute power let alone normal CPU's. It was Windows 8 so people didn't like it in general. It required installations only from the store. Since this was running ARM compiled windows, it required ARM compiled programs, in the store front. Which the Windows store has never gotten any real love anyways but back then it was worse and to top if off, again it needed ARM compiled installations on top of its lacklustre uses. But what really killed it was the flux of ARM CPU developers at the time. MS's partner at the time was Nvidia. Their stuff wasn't beeing developed at the same pace as everyone else. No one was creating "tablet" cpu's at the time (this is a little bit before Apples large jump with the X line) and Nvidia wasn't keeping up at all. They had this tendency to fall back, jump ahead, fall back, back then. Intel just released a much faster and less power hungry atom line. So with the Surface 3 they got rid of all the downsides of trying to use ARM at the time.

Surface RT died because it was full of compromises, when compromises weren't needed. That isn't really the case with the Surface X and if MS can come up with a 64bit emulation that doesn't crap the bed, then maybe just maybe we can actually see ARM make inroads on dekstop and windows mobile products.
 

naukkis

Senior member
Jun 5, 2002
423
273
136
No as of right now MS only has 32bit X86 emulation on ARM. He wants MS to get to the point they can do 64bit and its not there yet. I guess it goes both ways. Sure MS does have it "working" but its not as seamless and quick as 32bit on ARM.
Only reason there isn't x86-64 emulation is that Intel does everything it can to prevent that happening.
 

ASK THE COMMUNITY