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

[ibex333]

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.

 

[ThatBuzzkiller]

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.

 

[DrMrLordX]

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]

@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.

 

[DrMrLordX]

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.

Why is that a "massive issue"?

 

[AkulaMD]

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]

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

 

[DrMrLordX]

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]

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.

 

[DrMrLordX]

Once Microsoft has x86_64 support on ARM

What's the point of that?

 

[Shivansps]

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.

 

[DrMrLordX]

Able to run full Windows software stack on ARM Windows, incluiding all games.

Have you considered the pitfalls of trying to decode x86-64 instructions on an ARM CPU?

 

[soresu]

Once Microsoft has x86_64 support on ARM

Hangover already supports it, albeit with QEMU which isn't the most slick recompiler for that use case to be sure.

https://github.com/AndreRH/hangover

 

[Shivansps]

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]

The Surface and Surface 2 died because the software that runs on Windows did not for Windows on ARM.

 

[TheELF]

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]

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.

 

[Tup3x]

Have you considered the pitfalls of trying to decode x86-64 instructions on an ARM CPU?

Apparently Microsoft has since they are working on it.

 

[DrMrLordX]

Apparently Microsoft has since they are working on it.

Since when? All they're doing is using software.

 

[Tup3x]

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]

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.

 

[Shivansps]

How was it unclear? @Shivansps wants to put decode hardware directly on the CPU.

Never said that.

 

[DrMrLordX]

Once Microsoft has x86_64 support on ARM

Never said that.

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.

 

[Topweasel]

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]

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]

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.