Stuff like this, https://www.amazon.de/-/en/Microsoft-Corporation/dp/15723171...
Traditionally x86 has been built powerful and power hungry and then designers scaled the chips down whereas it's the opposite for ARM.
For whatever reason, this also makes it possible to get much bigger YoY performance gains in ARM. The Apple M4 is a mature design[0] and yet a year later the M5 is CPU +15% GPU +30% memory bandwidth +28%.
The Snapdragon Elite X series is showing a similar trajectory.
So Jim Keller ended up being wrong that ISA doesn't matter. Its just that it's the people in the ISA that matter, not the silicon.
[0] its design traces all the way back to the A12 from 2018, and in some fundamental ways even to the A10 from 2016.
... the rest is history.
I would need some strong evidence to make me think it isn't the ISA that makes the difference.
We will see how big improvement is it's successor panther lake in January on 18A node
>I would need some strong evidence to make me think it isn't the ISA that makes the difference.
It is like saying that Java syntax is faster than C# syntax.
Everything is about the implementation: compiler, jit, runtime, stdlib, etc
If you spent decades of effort on peformance and ghz then don't be shocked that someone who spent decades on energy eff is better in that category
Basically, x86 uses op caches and micro ops which reduces instruction decoder use, the decoder itself doesn't use significant power, and ARM also uses op caches and micro ops to improve performance. So there is little effective difference. Micro ops and branch prediction is where the big wins are and both ISAs use them extensively.
If the hardware is equal and the designers are equally skilled, yet one ISA consistently pulls ahead, that leads to the likely conclusion that the way the chips get designed must be different for teams using the winning ISA.
For what it's worth, the same is happening in GPU land. Infamously, the M1 Ultra GPU at 120W equals the performance of the RTX 3090 at 320W (!).
That same M1 also smoked an Intel i9.
Cameras used on x86-64 usually just work using that usb webcam standard driver (what is that called again? uvcvideo?). But these smartphone-land cameras don't adhere to that standard, they probably don't connect using USB. They are designed to be used with the SoC vendor's downstream fork of Android or whatever, using proprietary blobs.
It does not matter whether you are a believer in horses for courses when it comes to ISA, or a believer in "frontend ISA does not matter because it's all translated away anyways": when buyers don't want what you have, you are out. And buyers are more like a stampeding herd than like rational actors when it comes to ISA choice. I'd see offering CPU for multiple ISA as an important hedge against the herd changing direction.
Not by a long shot.
Over a decade ago, one of my college professors was an ex-intel engineer who worked on Intel's mobile chips. He was even involved in an Intel ARM chip that ultimately never launched (At least I think it never launched. It's been over a decade :D).
The old conroe processors were based on Intel's mobile chips (Yonah). Netburst didn't focus on power efficiency explicitly so and that drove Intel into a corner.
Power efficiency is core to CPU design and always has been. It's easy create a chip that consumes 300W idle. The question is really how far that efficiency is driven. And that may be your point. Lunar Lake certainly looks like Intel deciding to really put a lot of resource on improving power efficiency. But it's not the first time they did that. The Intel Atom is another decades long series which was specifically created with power in mind (the N150 is the current iteration of it).
I'm not saying the skill of the design team makes zero difference, but it's ludicrous to say that the ISA makes no difference at all.
The claims about the M1 Ultra appear to be marketing nonsense:
https://www.reddit.com/r/MachineLearning/comments/tbj4lf/d_a...
Had been arm so weighted by backwards compatibility i doubt it would be so good as it is.
I really think intel/amd should draw a line somewhere around late 2000 and drop compatibility with stuff that slow down their processors.
I love the saying "i dont trust benchmarks that i didn't fake myself"
It might be the same with x86 and power-efficiency (semantics being the issue), but there doesn’t seem to be a consensus on that.
Acorn won the bid to make the original BBC home computer, with a 6502-based design.
Acorn later designed their own 32-bit chip, the ARM, to try to leapfrog their competitors who were moving to the 68000 or 386, and later spun off ARM as a separate company.
Java and C# are very similar so that analogy might make sense if you were comparing e.g. RISC-V and MIPS. But ARM and x86 are very different, so it's more like saying that Go is faster than Javascript. Which... surprise surprise it is (usually)! That's despite the investment into Javascript implementation dwarfing the investment into Go.
ISA is just ISA
The efficiency came solely from the frontend which is a lot heavier on x86, and stay up longer because decoding is way more complex. The execution units were the same (at least mostly, I think, might be misremembering) so once you are past the frontend there's barely any difference in power efficiency.
Which I think reinforces your argument: there were non-standard x86 platforms, but thankfully they died out. Given the situation of the home computer industry during the 8 and 16-bit eras, it is a small miracle that we ended up having an open industry standard.
AFAIK you needed to pay a license fee to write programs using Jazelle instructions (so you needed to weigh whether the speedup of Jazelle was cheaper than just buying a more powerful CPU), and the instruction set itself was also secret, requiring an NDA to get any documentation (so no open source software could use it, and no open toolchains supported it).
I remember being very disappointed when I found out about that