https://www.anandtech.com/show/15578/cloud-clash-amazon-grav...
(Apple Silicon blows them away on laptops, of course.)
This was one of the takeaways back in 2017 when Cloudflare sampled Qualcomm's very early Centriq ARM server chips.
> At Cloudflare we use an improved version of the library, optimized for 64-bit Intel processors, and although it is written mostly in C, it does use some Intel specific intrinsics. Comparing this optimized version to the generic zlib library wouldn’t be fair. Not to worry, with little effort I adapted the library to work very well on the ARMv8 architecture, with the use of NEON and CRC32 intrinsics. In the process it is twice as fast as the generic library for some files.
Intel's Lakefield was doing quite well in the tablet/MID space. It also had the disadvantage of comparatively ancient Atom-eaque cores- far worse than Intel's new E cores-and a massive massive huge Skylake core.
ARM is no longer behind by all that much on single threaded. On geekbench a m2 can do 1916 points, a 7950 2300points. Slightly bigger gap on Cinebench, 1580 Vs 2050. A big part of the gap here is almost certainly the Hz being so different.
We just don't know. There's old beliefs we have held but we had so little evidence for these biases then. X86 rarely tried to be really tiny, had so much more to learn if it was to succeed. ARM rarely tried to be big, and has been learning. There's scant evidence there are real limiting factors for either.
The article is commenting on CPU design: area efficiency, power efficiency, design cost, etc. They're proposing that the reason x86 CPUs have historically beat ARM CPUs in performance, and the reason ARM CPUs have historically beat x86 CPUs in power efficiency, has nothing to do with the design of the ISA itself. You could build an ARM CPU to beat an x86 CPU in high performance computing, or vice versa. They're saying that the format of the instructions and the particular way the operations are structured isn't the driving factor. Instead, it's just a historical arteract of how the ISAs were used.
In other words, yes, there are plenty of ecosystem reasons that these two (and potentially, more) families of chips are better for some things vs. others, but if the two companies swapped their ISAs 30 years ago we might see exactly the same ecosystem just with different instruction formats.
Even as Intel is declining, it still makes way, way more money than ARM does. If Intel wanted to play in the lose-money business, it could make something to kick the pants off of ARM's chips. It just would rather not.
It's easily forgotten but there were Android phones which used Intel x86 processors, such as the early Asus Zenfones. They didn't stick though.
(x86 has a truly atrocious thing called SMM (“system management mode”). It is not directly exposed to anything except firmware and malware, so it could be changed in backwards-incompatible ways without breaking existing software, but for some reason neither Intel nor AMD seems willing to do so. For desktop and server workloads, this isn’t really a big deal. For something like an iPhone, it would be a major non-selling-point.
Also, x86 interrupt latency is awful, and this is an ISA issue. x86 cannot currently compete in any application where this matters. FRED may improve this if the implementation is good enough.)
So there was occasional incompatibilities and no real benefit to balance them.
You don't want your phone to run x86 (and it won't for a while) and though possible its a pain to deal with an arm server at the moment because some random library you use just won't be compatible. And If single threaded performance matters, ARM is behind by a decade.