The trick to understanding that is to look at the history of the personal computer and the demands placed on the CPU and supporting chipset that evolved with the changing demands of the platform over time.
The ARM systems evolved from 'system on chip' or SoC designs where everything was on one chip. And even the latest ARM server designs don't have anything like the notion of an ARM server system where you can choose from a variety of CPU skus and drop them into a baseboard socket.
That isn't to say that they won't eventually get to something like that, it is only to stress that ARM systems design is still a 3 - 6 years behind personal computer systems design. And to date it isn't getting pushed very hard to close that gap.
The problem is that the ARM64 architecture is completely different from x86-64, which almost every desktop application is compiled for exclusively.
Remember when Microsoft launched an ARM Surface? It had a special version of Windows, and almost nothing would run on it, as very few applications are compiled for Windows on ARM.
Not true for Windows, especially old closed source software.
Edit: found it,
Windows just isn't the same, lots of devs making software the same way the made it 15+ years ago and not wanting or even caring enough to change no matter what the benefits.
I agree the issues are related, but if us people in open source can switch in an afternoon and you people in closed sourced land can't ever switch it highlights a problem.
If Windows on ARM allowed generic binaries, almost everything in the Windows ecosystem would be on ARM. For Windows.
That wasn't the reason. It was because Windows RT was artificially locked-down to only allow sandboxed "apps" from the Windows App Store to run. There's not much of a use-case for only glorified web-service clients on a machine with a desktop UI regardless of the ISA they're compiled for.
Had MS allowed arbitrary ARM code to run on the Surface RT, free of sandbox restrictions, I think the platform would still be alive today - probably as a successor to Windows CE for kiosk applications.
(Though there is now finally a non-locked-down version of Windows 10 for ARM... so let's see...)
https://www.theverge.com/2017/5/31/15711334/microsoft-window...
Every motherboard has it's own size, it's own closed bios supporting only some kinds of memory (if at all, due to on die memory of most soc), which is fine for embedded use but leaves a lot to be desired if you try to use it as a "desktop pc" replacement.
During the era where desktop PCs are becoming anachronistic?
https://channel9.msdn.com/Events/Build/2017/P4171
As for "never reaching the same performance" as desktop Intel/AMD chips, I would say that depends. It's not that they can't do it with ARM chips, is that nobody has bothered to do it until now, because there was no point with so few UWP apps. The market would be way too small. What would be the point in making a Core i7-level ARM chip just for the Surface RT? The risk would be too big.
But now that Microsoft opened up the PC market to ARM -- truly -- ARM chip makers can begin to make some real desktop-class ARM chips. Chips that require 15, 30, 45, or even 90 watts of power.
But I do think this will happen gradually over several years, because first they need to see how ARM chips work under Windows 10 this time around and how people accept them. Then if that goes well, they need to start designing those 15-90W ARM chips, and then start selling them.
Someone like Qualcomm needs to be sure that if it does design a 90W ARM chip that's highly competitive with a desktop class Intel or AMD chip (at least in terms of performance/dollar), more than 10 million people will buy it.
Why is that? I mean what is preventing anyone to just compile those apps to arm64?