Before Apple's M1, ARM was slow and near unusable for x86-class machines. There were some cheap ARM Chromebooks with a much shorter lifespan than their x86-based brethren, and an ARM tablet that Microsoft abandoned, and that's about it.

After the M1, the ARM companies needed to up their game, and Qualcom is rumoured to finally release something competitive to a real x64 chip in the near future. This isn't the first time they've made claims like these, though, and I very much doubt they'll live up to their promise.

Meanwhile, x64 has caught up to Apple in terms of compute power (especially per dollar, which is the reason x64 is so popular), is getting closer and closer to Apple's power consumption levels, and unless the M4 will have dramatically more performance, the ARM overtake will just have been an outlier.

I'm not so sure how long non-Apple ARM will be able to stay competitive given the turnaround x64 has managed to make in just a few short years. It looks like x64 still has plenty of room for improvement, and this proves that the reason compute performance has plateaued was that there was no real competition.

> Before Apple's M1, ARM was slow and near unusable for x86-class machines

You ignore one huge class of x86 systems: servers. AWS Graviton launched 2 years before M1 and had competitive perf.

> This isn't the first time they've made claims like these, though, and I very much doubt they'll live up to their promise.

The difference now is that they actually have a set of customers that would buy a desktop-class chip if they produce one.

I came across an interesting fact about X86,

> currently there are actually no modern x86 CPUs on the market. Both Intel and AMD don't actually use x86 cores, but instead proprietary RISC cores, with microcode that translates the x86 code to RISC code on the fly at execution time.

https://cs.stackexchange.com/questions/132211/what-are-the-a... This cs.stackexchange link is a good read.

Wikipedia also states something similar,

> In the P6 and later microarchitectures, x86 instructions are internally converted into simpler RISC-style micro-operations that are specific to a particular processor and stepping level

https://en.wikipedia.org/wiki/Intel_Microcode

> currently there are actually no modern x86 CPUs on the market.

This feels like one of the stranger "no true Scotsman" arguments I've ever run across.

Even the 8086 had microcode that translated the instructions as generated by the compiler/programmer into the instructions that would be processed: http://www.righto.com/2022/11/how-8086-processors-microcode-...

I would love to know what the person who wrote that stackexchange answer would say in response to the question, "so which x86 processors used 'real' x86 cores?" Because from the very beginning of x86, there's been translation of the front-door opcodes into internal opcodes via microcode.

> Intel and AMD don't use x86 cores but [...] instead translate the x86 code to RISC code on the fly

I used to say this all the time and I've been informed that it's something of a misunderstanding. For example, most RISC-V processors also decompose instructions into multiple μops: https://docs.boom-core.org/en/latest/sections/execution-stag...

So it isn't like there is a literal RISC processor inside the x86 processor with a tiny little compiler sitting in the middle. It's just that the out-of-order execution model requires instructions to be broken up into subtasks which can separately queue at the core's various execution units. Even pipelining instructions still wastes a lot of silicon (while you're doing an integer add the floating point ALU is just sitting there, bored) so breaking things up this way greatly improves parallelism. As I understand it, modern μop-based processor cores can actually have dozens of ALUs, multiple load/store units, virtual->physical address translation units, etc all working together asynchronously to chug through the incoming instructions.

> currently there are actually no modern x86 CPUs on the market. Both Intel and AMD don't actually use x86 cores, but instead proprietary RISC cores, with microcode that translates the x86 code to RISC code on the fly at execution time.

This kind of factoid does more to obscure the truth than it does to illuminate it.

The truth of the matter is that all high-end CPUs do a µop translation, whether or not their frontend is a CISC or RISC ISA. Indeed, the very notion of CISC versus RISC is way overwrought in architecture textbooks, and this probably produces the garbled thinking: since everyone "knows" that CISC can't be superscalar, this means that the Pentium (in making superscalar x86) has to somehow be RISC.

Another thing to note is that there's not really anything called CISC. RISC is the overall term for a family of computer architecture design methodologies arising the 80's that argued for compiler-centric rather than assembler-centric design and simpler instructions, sometimes to the point that you omit hardware and call it a feature (e.g., delay slots). CISC is... everything else; it's a strawman constructed for RISC to compete against rather than a coherent design methodology.

In actual practice, though, RISC v CISC hasn't been relevant for decades. Some of the RISC design ideas have won out: there's generally a high emphasis on instructions that can be selected by the compiler over hand-tuned assembly, for example. But things like delay slots have been generally considered a failure. The architectures that are the most successful--x86 and ARM--are the ones that blur the line between RISC and CISC the most.

Actually, if you scrubbed the x86 assembly away and came up with some new assembly syntax (including new mnemonics of course), you could probably sell the x86 ISA as a "compressed RISC" ISA and get many people to believe you that it was designed as a RISC. x86 doesn't have many instructions that have crazy interrupt rules or multiple memory references (the string instructions are the main exceptions here), and it's this property which turns out to be really key to making something high-performance or not. It would be better for us to be honest about what enables or doesn't enable superscalar architectures rather than trying to argue that somehow x86 cheated its way to success.

Thank you for saying this. The amount of hype RISC gets in unbelievable. It is especially irritating because almost every major RISC design which came out of the 1980s and early 1990s failed in the market. PA RISC is dead. PowerPC, MIPS and Spark are either on life support or only used in cheap low cost or maybe low power products. I believe IBM's Power architecture is still going but I suspect it's slower than AMD's and Intel's x86 chips (IBM does not publish SPEC CPU Benchmark results which is not a good sign).

Basically, I have noticed that people have been claiming RISC is the best for decades and yet real RISC architectures failed to beat x86's performance. Even worse, most of the RISC workstation and server makers exited the business, went bankrupt, or only sell systems to legacy customers who have not migrated to x86.

By that account, there never has been any x86 CPU, since the OG 8086 had a microcode ROM and translated most instructions into micro-ops.

It seems I make this comment every 6 months or so, but... x86 uops are not at all RISC-style. They are very large (classic RISC uses 32bit encoding, uops are over 100 bits), variable size (classic RISC is fixed style, uops can use multiple slots to encode constants) and can encode load-op (classic RISC separates load and stores from operations).

There is also the fact that RISC-ness is a property of the ISA, so applying it to describe a microarchitecture doesn't make much sense.

edit: reference: https://www.quora.com/Why-are-RISC-processors-considered-fas... (sorry for the quora link)

Also, the more transistors we stuff on to a chip, a process that is still continuing, the less are proportionally dedicated to these decoding pipelines. My impression is that they are already relatively insignificant parts of the chips, though corrections welcome.

I wonder if there's any ISA that could be written against the x86 cores that would be more efficient. In theory the chip could use that as a mode, so the chip itself wouldn't require an entire OS to shift before things could use it. I don't know anywhere near enough about the inside of an x86 core to have even a clue if such a thing would be possible. But it would be an interesting escape hatch from x86. Anyone who can flesh this idea out with knowledge of the x86 core internals is welcome to explain to me why my idea is bad and I should feel bad.

Note that you couldn't directly simplify the architecture by just writing an assembler for the RISC microcode. The reason is that the RISC microcode is much larger than the x86 it is derived from. This on the fly decompression does wonders for cache hit percentage.

There's no RISC microcode.

RISC is about the ISA, which is the interface between software and hardware. It is irrelevant whether the hardware is implemented with microops or hamsters running on wheels.

Yet if the existing microops used in popular CPUs made today were actually exposed as the interface between software and hardware, they would be VLIW ISAs, not RISC ISAs.

The whole "CISC have a RISC inside" idea is thus wrong at many levels, and just left over cultural damage from an Intel PR campaign ("risc vs cisc doesn't matter"), which was very effective at misinforming the tech world.

Note that Intel chips did no-doubt win in the market, but that was despite CISC, rather than thanks to CISC: Intel had a MASSIVE fab advantage, alongside the software moat around Microsoft OSs.

There are two ways to interpret this statement. First is that ISA is completely irrelevant since you can just convert to whatever is best. This is bad for RISC since there is literally no advantage gained by losing backwards compatibility.

The other interpretation is that micro ops are actually a microarchitectural optimization and that RISC processors should use it too. The compressed instruction set of RISC-V is leaning towards that direction. RISC-V processors internally convert RISC-V instructions to RISC-V.

It is kind of hollow to talk about it, since it is hardly clear to say that this is a unique disadvantage or advantage.

>This is bad for RISC since there is literally no advantage gained by losing backwards compatibility.

I respectfully disagree. There's a major advantage of losing backwards compatibility with established ISAs, and that is freedom from licensing.

e.g. The main strength of RISC-V is not even its technical superiority; It is the free license.

OTOH I have been hearing about ARM's rise since a long time now. It's not just performance per watt and even that's just Apple beating everyone. See Windows on ARM.

x64 is here to stay with its incredible ecosystem and OSS friendliness - Coreboot, Intel and AMD GPU drivers, great choice of operating systems and apps with a fairly long usable lifespan even with Windows updates.

There is nothing inherent in the ISA. The moat of x86 is purely backward compatibility and decades of experience of ARM and Intel in building large systems.

ARM has abysmal SIMD support. Not even supporting AVX 256. for reference that is about a 10 year lag behind x86. Neon is not an adequate substitute. Additionally when AVX is used, the power draw of a ARM skyrockets to x86 level defeating the advantage ARM has over x86 while offering worse performance. ARM is good for things that require many threads and are not heavily dependent on incredibly high integer performance per thread. x86 is the dominate in high power, when individual thread power is more important due to application requirements or size limits or if they need to do anything with SIMD. ARM has a lot of push behind it. But it contrary to techbro hype., it is not a drop in replacement for x86 and I dont think it ever will without shooting themselves in the foot making them less efficient.

Focussing on vector length is an error. You should care about throughput and number of different instructions you can retire.

If I have a core with four 128-bit neon vector units, I have the same throughput as an x86 with two AVX2 units or one AVX512 unit. However that 4x128-bit core is actually more flexible than the other two as I can do 4 different things at once, or 4 scalar operations per cycle. (Of course the downside is you spend more frontend resources on decode).

Given that most code isn't vector code, the multiple short vector length approach is actually superior on many common real-world workloads that aren't machine-learning (and CPU is unit-of-last-resort for large ML workloads anyway).

ARM has, optionally,the very capable SVE instruction set, but no consumer chips currently implement it.

The M1 and later big cores can dispatch four NEON FMA instructions per clock, so 512 bits worth of vector math, which compares OK with most Intel or AMD chips (Zen 4 can do two 256-bit MUL and two ADD, and Intel "client" bigcores since Sunny Cove typically do three 256-bit FMA).

>when AVX is used

spoiler: it isn't

Then why did Intel and AMD add it to their chips? My guess is AVX is used for when it is worth the effort. If I had to guess, it is used for scientific computing, maybe video processing (as in movies, TV, etc.), maybe audio processing, etc.