I do not understand why ARM is considered lesser technology. RISC was always considered to be better then CISC in many academic circles.
1. Innovator's dilemma: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma
ARM in this case is the underdog, attacking the incumbent x86. It is the lesser tech because it started from "below" (lower value niches not taken by the incumbent which prefers higher profit margins).
2. RISC vs CISC has never been settled. Until Apple (and Amazon super recently) produced their super recent architectures based on ARM, x86 was considered superior. Yes, RISC was theoretically better in the 80s and later 90s, but x86 has been reinvented successfully 2 times (micro-ops and x86_64) and scaled from 0.2MHz to 5Ghz. It's also a mix of CISC and RISC, it's not pure CISC now. Same for ARM, they've added various instructions which bring it closer to CISC.
As far as I can see the only real difference these days is the constant length of instructions for ARM: https://erik-engheim.medium.com/why-is-apples-m1-chip-so-fas...
It’s a bit silly to think of x86 and ARM as being so different these days. Most x86 code looks a lot like it was produced for a RISC chip and ARM has been gaining some more complex instructions and addressing modes. Academics may have felt that RISC was better than CISC for a long time but I don’t think they were predicting the world of today so much as they were incorrectly predicting the near past. If RISC were so much better then we’d have lots of workstations running on modern Alpha or PA-RISC systems. But we don’t see that.
> Academics may have felt that RISC was better than CISC for a long time but I don’t think they were predicting the world of today so much as they were incorrectly predicting the near past.
Plus you know, academics have been known to be wrong. That's why there's even a saying for it: science advances, one funeral at a time. People are emotional and get attached to their pet theories. There are many examples of this.
It's going to be interesting to see how CPU/GPU tech advances the next few years.
Well yes I don't think the x86 BCD instructions are still being used liberally, or AAA, or CONS/SCAS etc
And how specifically are these instructions complex? Do they produce an unusually high number of micro-ops when decided?
Today the most used x86 instructions are not that much different from ARM ones, and in a good number of cases actually even simpler. The simplest way to compare is to simply look at the assembly an optimizing native compiler emits, and lookup for what the emitted instructions are doing.
The micro-ops of processor are actually quite dependent on the ISA. You could do neutral micro-ops, but I doubt this would be very efficient. So you can't really compare the complexity of ISA by the number of micro-ops issued, because among different arch and microarch the micro-ops are themselves more complex on some point and less on others, with tons of similarities with (core instruction set of) the ISAs they implement.
Complex instruction for backward compat, special, or intrinsically difficult operations, are transformed to a potentially very high number of micro-ops, often looked-up in a ROM.
M1 actually also implements the X86 memory model too in HW. It’s only usable for the rosetta applications and comes with perhaps 20% perf penalty. But it’s still way better than emulating it with barriers.
In C++ terms it pretty much means X86 is always seq_cst. With ARM one can actually get benefit of the different memory model options. As an example one can do an atomic access without having to flush the whole store buffer out, which is impossible in X86.
Due to the instruction coding and memory model for multicore I don’t really see X86 dominating anymore in the upcoming decades.
And as the modern OoO cores are so similar internally it’s not even a big deal in the end. AMD shouldn’t have any issues with producing a Zen arm core. Switch the inst decoder and that’s pretty much it (ton of design work for sure). Keep the X86 mem model optional for emulation and binary translation can be almost thought as just making X86 instructions into fixed width ahead of time.
I had always assumed that the looser memory model must have a performance benefit. But this comment from last week argues that it doesn't really buy that much, and that a bigger buffer can eliminate most of the difference: https://news.ycombinator.com/item?id=25263461
If TSO forces flushing of store buffers for every atomic access, that seems like a substantial disadvantage for x86.
Without that the store buffers can be kept unflushed to, as an example, see if one can get a full cacheline or whatnot and only flush then.
The comment is correct that an X86 with heavy reordering backend will beat arm without one. However arm with one does handily beat X86 with one. Case in point: M1
Is the 20% perf hit of TSO mode that you cite an ARM vs. ARM comparison? If so, that would be pretty damning.
Is there an easy way to flip the M1 into TSO mode for benchmarking? I would love to observe this 20% for myself.
I haven’t verified the exact numbers myself. And it will depend on the exact thing you’re running. It’s just on the order of low tens of percents.
TSO cannot be enabled outside of rosetta as it’s not exactly a good arm extension. Perhaps you could do some trickery but Apple likely prevents that.
However you can test it by making something where you know rosetta generates comparable arm assembly from the X86 one and just run comparison that way. Some sort of parallel lockfree algorithm would be the best candidate.
One couldn’t do X86 version of M1, mostly because there is no way of making an instruction decoder that wide for it.
And the performance penalty of M1 when working in TSO mode strongly implies that yes the weaker memory model indeed plays a major role. Not the biggest, but definitely not insignificant. Tens of percents here and tens of percents there combined become a ridiculous perf boost.
It's not. It's microcoded. Like VAX. Which RISC is a response to.
Most chips are "microcoded", at least here and there. The term does not define a whole micro-architecture, esp in modern complex ones, but I'm not really sure how you would implement old school CISC chips without microcode concepts. The 8086 was microcoded: https://www.reenigne.org/blog/8086-microcode-disassembled/. It basically means that "you" program some low level internal details of a chip, e.g. the muxes connecting various buses to execution units. Most of the time the "you" is only the chip designers, and it is stored mostly in a ROM. Sometimes microcoding is accessible by actual software programmers, but it is quite rare.
And modern u-ops are not necessarily like what was done at the time of old-school microcode.
x86 was itself a kind of underdog in that space, losing out in sheer performance and bandwidth to the high-end RISC market, but making up for it by, you know, being cheap enough that "regular people" could go and buy a family computer with an x86 processor.
Intel managed to slowly improve the various deficiencies over time, and produced a processor not only affordable, but also superior to the incumbent RISC chips in all but niche areas.
I think more than the ISA, Apple's M1 manages to be so good at its job for similar reasons to the old RISC chips -- it's built from the ground-up with a pretty specific target application, rather unlike x86, which has to be all things to all people, with legacy support and scaling from laptops to quad socket 3U servers.
(It's split for things like development, now that the M1 is here. Personally I get my development done with 8-core 4+ Ghz x86 chips in Windows/WSL2/Docker, but others are getting development done with Apple Silicon M1 ARM chips!)
Over time the "lesser" technology can become the greater technology for more use cases.
If so, as soon as someone (Apple) makes an ARM chip with sufficient PCIe lanes, then it's only a matter of drivers...
It's a combination of things:
* Apple has not indicated that they'll allow for third-party GPUs
* Apple has not pushed for widespread gaming compatibility
* Game developers prefer to reach the widest audience
Apple would need the M1 successors superior in gaming computation and capable of marrying up to high-performance GPUs, write the drivers necessary AND get broad adoption of Apple gaming to factor into game publishing.
This is all theoretically possible, but it didn't happen while Apple was using roughly the same high-end hardware available to PC gamers, so it's questionable (in my mind) that it'll happen when they are locking down their hardware further, and trying to use all their own hardware for gaming.
That's not the case anymore, but the stereotype will persist for a while.
One of the reasons this new chip is so performant is the "headroom" that this approach has given them.
Apple are the survivors of the vertical integrated home computers, and they only managed to survive by reverse acquisition of NeXT, and diversifying outside of the desktop market.
I don’t think ARM and graphics will long be known for poor performance.
As a fan of AMD, I hope they see the writing on the wall and are planning accordingly. It would not be surprising to see the successors to the PS5 and Xbox Series running on ARM.