12 ms·

ARM or x86? ISA Doesn’t Matter (2021)

222 points by NavinF 3y ago

dtx1 3y ago
yeah, no. Tooling support, driver support and general Optimization matters. So does platform maturity. 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.
- circuit10 3y ago
  Having an Oracle Cloud Free Tier ARM VPS it’s surprising how much just works, I think the only thing I couldn’t run was Chrome Remote Desktop (yes, I want to remote into my VPS sometimes, for example it’s the easiest way to leave a GUI program running in the background without leaving my PC on) and only a few other things needed extra steps. But it’s probably a lot different on desktop or if you’re running different types of programs
  - wolf550e 3y ago
    Some libraries have x86 SIMD code but no ARM SIMD code, so benchmarking real world use cases you compare SIMD vs scalar code and x86 is much faster. Server side libraries for ARM are a less mature situation than x86.
- rektide 3y ago
  We don't know, is the only good answer. We haven't done much trying in the past 10 years. Intel's Lakefield was doing quite well in the tablet/MID space. It also had the disadvantages of both comparatively ancient Atom-esque cores- far worse than Intel's new E cores-and a massive massive huge Skylake core. Oh and a replayed decade old desktop iGPU too. 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.
- hedora 3y ago
  These benchmarks suggest arm has been at single threaded performance parity on server since 2020: https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/5 https://www.anandtech.com/show/15578/cloud-clash-amazon-grav... (Apple Silicon blows them away on laptops, of course.)
  - tyingq 3y ago
    I imagine some of the remaining gap might be places where inline ASM or things like SIMD, AVX, etc, exist. Where there's been more years and a larger set of people optimizing that ASM for x86/64 servers.
    - GeekyBear 3y ago
      > the remaining gap might be places where inline ASM or things like SIMD, AVX, etc, exist 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. https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/
- kaelinl 3y ago
  This isn't the point of the article. 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.
  - Jasper_ 3y ago
    Yeah, ARM's big advantage is that they are willing to make absolutely zero margin on chips, which allows them to play both ends of the spectrum. They can make Celeron-tier chips that don't take any power and practically given away for free and use that as evidence of ARM's superiority in things like the M1 and supercomputers. 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.
  - IshKebab 3y ago
    I'm not sure I buy that. x86 chips have targeted laptops for decades, yet they were absolutely walloped by Apple's ARM chips. IIRC a big part of that is that the ARM ISA has 2/4 byte instructions whereas x86 can be crazy sizes which made it easier for Apple to have 8 instruction decoders. At least that's the best theory I heard for why it is so fast.
- jsheard 3y ago
  > You don't want your phone to run x86 (and it won't for a while) 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.
  - kelnos 3y ago
    I think that's the point, though: why didn't they stick? Was it a price/performance/power issue, which would point to ARM being somehow "better" on those dimensions, or was it something incidental, like production availability, or even just perhaps a lack of desire at Intel to aggressively pursue that market?
    - amluto 3y ago
      At least some of the attempts in question had, ahem, interesting ideas for how to combine baseband and AP on one chip. (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.)
  - rsaxvc 3y ago
    You could even get an AMD chip in your XPPhone https://www.umpcportal.com/products/XPPhone/XPPhone https://www.umpcportal.com/products/XPPhone/XPPhone :p
  - eloisant 3y ago
    The biggest issue is that ARM was already king, so x86 was an exception that wasn't always accounted for. So there was occasional incompatibilities and no real benefit to balance them.
- dehrmann 3y ago
  It sounds like Atom could have found a home in phones.
isidor3 3y ago
It is interesting to me how both instruction sets have converged on splitting operations into simpler micro ops. The author briefly mentions RISC-V as having "better" core instructions, but it makes me wonder if having the best possible instructions would even help that much. If you made a CPU that directly ran off of some convergent microcode, would you then lose because of bandwidth of getting those instructions to the chip? Or is compressing instruction streams already a pretty-well-solved problem if you're able to do it from a clean slate, instead of being tied to what instruction representations a chip happened to be using many years ago?
- circuit10 3y ago
  > If you made a CPU that directly ran off of some convergent microcode I think that’s the original idea behind RISC
  - mafribe 3y ago
    Microcode is often attributed to [1] from 1952. [1] M. V. Wilkes, J. B. Stringer, Micro-programming and the design of the control circuits in an electronic digital computer.
    - kwhitefoot 3y ago
      It's arguable that Babbage's design for the Analytical Engine included microcode. See, i.a., https://www.fourmilab.ch/babbage/glossary.html https://www.fourmilab.ch/babbage/glossary.html
      - mafribe 3y ago
        Interesting, I had no idea. Wilkes doesn't cite Babbage, oh dear!
  - isidor3 3y ago
    Yes, and obviously ARM didn't chose the instructions in its reduced set optimally, if the best implementations require those instructions to be split into smaller ones. But that doesn't really speak to if that's because it's just better to pack instructions that way, or because these implementations of ARM and x86 just need to do it to be performant in spite of deficiencies in their instruction sets.
api 3y ago
Decoder complexity matters. ARM with its single instruction width allows arbitrarily parallel decoders with only linear growth in transistor count. X86 with its many widths and formats requires decoders that grow exponentially in complexity with parallelism, consuming more silicon and power to achieve higher levels of instruction level parallelism. It requires a degree of brute force with many possible size branches being explored at once among other expensive tricks. This is one of the major areas where the instruction sets are not equal. ARM has a distinct efficiency advantage.
- jeffbee 3y ago
  Does anyone actually care about this? The x86 decoders are not large on modern implementations, and putting more transistors on dice is a well-solved problem.
  - api 3y ago
    It uses more power. The decoder is like another ALU that is always screaming at 100%. It means you can easily keep up with ARM in speed but not power efficiency.
    - jeffbee 3y ago
      It doesn't seem to matter in practice. Current generation Intel CPUs and the Apple M2 have very similar performance at the same power levels.
      - rowanG077 3y ago
        How did you arrive at that conclusion? Comparing the M2 Max vs 13650HX it's very obvious the M2 Max uses a LOT less power. It's not even close, it's less then HALF the power. The M2 max has a little worse performance. But it manages to beat the Intel in some benchmarks.
        jeffbee 3y ago
tux3 3y ago
The x86 decoders consume a reasonable amount of power, but the trouble is making them wider without affecting that. I have an AMD CPU. Zen CPUs come with a fairly wide backend. But the frontend is what it is (especially early Zen), and without SMT it's essentially impossible to keep all those execution units fed. It's not that 8 x86 decoders wouldn't be a benefit, it's just that more decoders isn't cheap in x86 cores, each extra decoder is a serious cost. If you compare with the big ARM cores, having a wide frontend is not a complex research problem or an impractical cost. 8 wide ARM decode is completely practical. You even have open source superscalar RISC-V cores just publicly available on Github running on FPGAs with 8 wide decode. Large frontends are (relatively) cheap and easy, if you're not x86. So when we notice that the narrower x86 CPU's decode doesn't consume that much (a "drop in the ocean"), that's because it was designed narrower to keep the PPA reasonable! The reason I can't feed my Zen backend isn't because having a wide frontend is useless and I should just enable SMT anyways, it's because x86 makes wide decodes much less practical than competing architectures.
- ip26 3y ago
  It's a trade-off between problems. Variable length instructions are not as trivial to decode wide, so you need more cleverness here. However, fixed length instructions decrease code density, which asks more of the instruction cache. Note Zen4 has a 32 KB L1 instruction cache while the M1 has a 192 KB L1 instruction cache, requiring extra cleverness here instead to handle the higher latency and area. Meanwhile, micro-op caches hide both problems. The are ripple effects to consider as well. The large L1 caches of M1 (320 KB total) put capacity pressure on L2, towards larger sizes and/or away from inclusive policy. See the 12MB shared L2. Meanwhile, the narrower decode of Zen4 puts pressure on things like branch prediction accuracy & mispredict correction latency - if you predicted the wrong codepath, you can't catch up as quickly. See the large branch predictors on Zen4.
  - pclmulqdq 3y ago
    ARM used to find itself on the wrong side of this tradeoff in the era of 4-wide x86 decode units and 4-6 wide ARM decoders. They lost too much perf to cache size for the decoder width to make up for it. It's unclear to me if they will pull ahead on the perf/area game with the era of 8-wide x86 decoders coming.
TheLoafOfBread 3y ago
What does matter is standardization. For example a booting process. When I have x86 image of Windows/Linux, I can boot it on any x86 processor. When I have ARM image, well, then I can boot it on a SoC it is built for and that's big maybe because if outside peripherals are different (i.e. different LCD driver) or lives on different pins of SoC, then I am screwed and will have at best partially working system. Standardization is something what will carry x86 very far into the future despite its infectivity on low power devices.
- nubinetwork 3y ago
  > When I have ARM image, well, then I can boot it on a SoC it is built for ... or lives on different pins of SoC, then I am screwed and will have at best partially working system. That's not even the half of it either... what firmware does the board run? U-boot is nice, but sometimes you aren't lucky and you're stuck with something proprietary. Although if you're extremely lucky, you'll have a firmware that supports efi kernels.
- dehrmann 3y ago
  > When I have x86 image of Windows/Linux, I can boot it on any x86 processor. Where this gets absurd is modern Debian supports i686 and up. You should be able to get a 27-year-old Pentium Pro to boot the same image as a Raptor Lake CPU.
  - sliken 3y ago
    My memory is that the pentium pro had a common memory config of 256MB, way below what modern installers are going to expect. I'm sure you can get linux to install on 256MB, but I doubt it's going to work on the current RHEL/SUSE/Ubuntu installers. Not to mention various drivers have gone without maintainers and pulled from the upstream linux kernel. Not to mention dropping IA32 and related PAE support.
- GeekyBear 3y ago
  > When I have x86 image of Windows/Linux, I can boot it on any x86 processor. This has come with a stack of caveats since the advent of Secure Boot.
dehrmann 3y ago
This would explain part of why Apple hasn't been pushing M2 for the data center. Its chips are a better fit for bursty human workloads, not server workloads.
- rowanG077 3y ago
  Apple doesn't see value in going after the server market.
  - XorNot 3y ago
    The consumer might replace their laptop once a year, at a fast cadence, but they don't wake up one day and say "I actually need 3 laptops". Whereas datacenters are now being built constantly, and any future projection would estimate that we're going to keep building more - and if you were unsure before, then the sudden popularity of training AIs and their massive demand for compute should've convinced you. Apple aren't going to leave money on the table (otherwise they'd still be shipping iPhones with chargers and including dongles with laptops): if they're not targeting server markets, it's because their internal modelling is telling them that what they've got is probably at best a peer-capability, rather then some type of vast excession (or would be wiped out easily by another gen of server grade chip releases).
    - pjmlp 3y ago
      Apple already failed twice on the server market, A/UX and Xserve, and decided it wasn't for them. They would have to offer a top option with macOS to make it relevant, as they certainly aren't going to be offering their hardware to run GNU/Linux on top of it. It happened once, with MkLinux, and that is also something that management won't be keen in repeating.
- KerrAvon 3y ago
  Apple Silicon chips aren’t for sale outside Apple, and Apple hasn’t made any products relevant to data centers since they terminated the Xserve line as part of the PowerPC -> Intel transition.
skissane 3y ago
I wonder where we’d be if the idea of CPU-independent bytecode had ever really taken off - for example, the TIMI bytecode of IBM System/38 and AS/400, TenDRA TDF (aka OSF ANDF), WebAssembly. You could have an AOT compiler in the system firmware which the OS invokes, when a program is installed the OS uses AOT to convert it to the actual machine code, about which the OS might know nothing, and could vary incompatibly from CPU to CPU, even among different CPU models in the same family. (Maybe a JIT mode too.) I guess JVM/CIL are somewhat similar, but at a much higher level - I’m not talking about garbage collection or type safety. In some ways that is true of TIMI too - it is designed to support a capability-based operating system, and hence has some rather high-level instructions, although still not as high level as JVM/CIL - it was generally used as a compilation target for non-garbage collected languages such as RPG, COBOL, C/C++, PL/I, Fortran, BASIC, Pascal, etc - and hence lacks a garbage collector.
- tadfisher 3y ago
  Transmeta Crusoe? They chose X86 machine code as their CPU-independent bytecode.
  - zdw 3y ago
    In demos the Transmeta processors was shown to support multiple instruction sets - per https://en.wikipedia.org/wiki/Transmeta#Code_Morphing_Software https://en.wikipedia.org/wiki/Transmeta#Code_Morphing_Softwa... , they demoed pico-Java , and also there were rumors of PowerPC compatibility. Although you're probably right - none of those options made it into a shipping product, only x86.
  - fathyb 3y ago
    I guess today's equivalent VLIW chip would be Tachyum Prodigy, not super confident about it.. https://www.tachyum.com/products/#products-prodigy https://www.tachyum.com/products/#products-prodigy
    - hurpdurpdurp 3y ago
      Nvidia's denver2 cores work this way. Shipped on an android tablet about 10 years ago. Not sure what happened to them after that.
fanf2 3y ago
x86 is not a very CISCy CISC, compared to VAX or 68020. x86 has relatively simple addressing modes and often limits instructions to one memory operand. It would be interesting to see how well a modern VAX or 68k could compete with x86 and ARM.
- ggm 3y ago
  I came here to say much the same. The labels were defined (CISC/RISC) in a time of different costs and CPUs. Roll forward, and both RISC has become more complex and CISC has adopted many features of RISC. I would have loved to see more clear signs of how much L1/L2 cache plays here, and the interconnect between cores. I suspect we're now well down a path where writing code to fit into L1 and writing code to balance load across cores has more importance than anything else. (not a VLSI or ISA person btw)
apatheticonion 3y ago
I look forward to the day when ISA doesn't matter. Picking an ARM laptop because right now the technology is better suited to mobile applications while having an x86 desktop because that's the best technology for that right now seems sensible. Translation layers are constantly improving - maybe soon we will be able to play games and run software with the same level of performance/reliability regardless of the CPU architecture.
drpixie 3y ago
This RISC/CISC debate made a lot of sense when the "guts" of the CPU (decoder, registers, ALU, etc) occupied almost the whole chip (or box of transistors), and when memory and CPU had similar speeds. The situation now is very different. The vast majority of the chip is cache. The trade-off for a much bigger decoder (or register stack, or whatever) is now just a fractionally smaller cache. And on current systems the CPU and memory operate at enormously different speeds - memory is 10+ times slower than the CPU. So to keep the CPU even vaguely busy, we have resorted to enormous caches. And we use large numbers of cores & threads, so that when one thread is waiting for memory, others may be able to run. The old game was max performance from a limited number of gates. The current situation makes such enormous numbers of gates available (even on tiny, cheap chips) that we're playing an altogether different game.
- sweetjuly 3y ago
  While area is now very cheap, power and thermal is more of an issue than ever. Huge d/i caches are doable since they save power, huge arrays of decoders not so much. The CISC-RISC debate wasn't just based on area; everyone back then also saw the direction that scaling was taking us.
- branko_d 3y ago
  > memory is 10+ times slower than the CPU The difference is much greater than that - one uncached RAM access can take hundreds of CPU cycles.
  - deleted 3y ago
    [deleted]
- audunw 3y ago
  The interesting part of RISC vs CISC now isn't the complexity of the instructions or whether they're variable or fixed length. Both ARM and RISC-V has aspects that could be considered CISC-like in that regard. The interesting difference is the memory model of the instructions. What kind of dependencies between instructions you have to keep track of when decoding them. If I understand correctly, that's the thing that makes it very hard to scale x86 wider, as talked about in another top comment in this thread. The decoder doesn't necessarily scale linearly with the width of the decoder. Since ARM and RISC-V hasn't traditionally competed in the very high end ultra-wide superscalar CPU space until recently, it's possible that we're not going to see x86 held back until more advanced ARM/RISC-V manages to scale to a wider architecture than what x86 is reasonably capable of.
titzer 3y ago
> In fact, several workloads saw less power draw with the op cache was disabled. Decoder power draw was drowned out by power draw from other core components, especially if the op cache kept them better fed. That lines up with Jim Keller’s comment. There's a hidden problem here: disabling the opcache couldn't possibly improve the power draw of other components. The system is simply doing less work per unit time because it issues fewer instructions in the same time. This is a common benchmarking problem when the workload isn't fixed, e.g. when a benchmark tries to run as many iterations it can in N seconds. By increasing execution speed (or in this case, decreasing it), you also increase the total amount of work done per unit time.
MobiusHorizons 3y ago
I have wondered something for a while. x86 (32 and 64 bit) have much smaller instruction size on average than RISC ISAs. Given that modern compute performance is heavily affected by cache performance and memory latency, it seems like the smaller codesize could really help with caching performance. Is this actually a factor? Does arm need bigger caches to combat this? Or does the unpredictability of unguessable instruction offsets ruin this in some way? It's obviously only one factor among menay, and ram is often filled with data not just code, but I've wondered about it for a while.
- tuetuopay 3y ago
  If memory serves, the net code density is on par between x86 and ARM. Of course if you take some small code samples, yeah, it's an easy win for x86, but for real world programs, there end up being no measurable difference.
  - renox 3y ago
    > the net code density is on par between x86 and ARM It was similar with Thumb, but now that there's ARMv8, ARM code density has probably decreased.
abainbridge 3y ago
edit: The emphasis is wrong here. The main benefit of a relaxed memory model is that it reduces the amount of work the memory subsystem HW needs to do. Another ISA difference not discussed by the article is the memory model. I expect that the memory model and the degree of reordering permitted by the architecture could have a significant impact on performance. x86 imposes stricter ordering constraints on memory accesses. The choice of this memory model was made long ago, when, I guess, it was felt that this made the behaviour easier to understand for the programmer. In contrast, ARM's memory model permits more reordering of memory accesses, which can lead to potential data races and inconsistent program behavior. However, this greater flexibility can also lead to higher performance, as the processor can execute memory accesses in a more efficient manner by overlapping and reordering them. I can't find any studies that measure the impact of this, but I'd be surprised if it wasn't a significant win for the ARM ISA in many programs.
- tialaramex 3y ago
  For languages like C++ and Rust the memory model is part of the language and so is taken into consideration by the compiler backend too. Code that's explicitly asking for Relaxed (the fastest ordering, which has no benefit on x86) is fairly rare.
  - abainbridge 3y ago
    Hmmm. Fair point. I got this argument from a HW engineer I know. You forced me to think more about what he was saying. His point was actually that the TSO model requires the HW to keep track of more stuff. More stuff uses more energy and adds latency to every memory access. It also limits how many accesses the memory subsystem can handle in parallel. He points out that ARM, RISC-V and even ia64 (Itanium) chose the relaxed model because it is better.
hilbert42 3y ago
Very interesting article. If its assertions and conclusions are correct then it's very useful information. I've been somewhat suspicious of CISC processors with large microcode real estate ever since the days of the Pentium bug, which was, if I recall correctly, when microcode began to quickly increase in complexity. (I'm not a processor designer but it seems to me that with increased size and complexity bugs would be more likely.) Alternatively, RISC seemed too limited, but then I'm viewing this from a programming perspective—not that of processor design. Probably the most interesting aspect of the article was Jim Keller's point about the 'cleanness' of the newer RISC-V architecture, as that may settle the ongoing comparisons and arguments over it and ARM. For people like me who want to see more independent and open hardware architecture available, it'll be interesting to see how that plays out over time.
undersuit 3y ago
The chart of how the A64FX supercomputer chip uses uops is telling: https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021/07/image-1.png?resize=768%2C558&ssl=1 https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021... We're targeting hardware compilers. At this point why not just do the Transmeta route again and abstract that last bits of specialty hardware. The Crusoe emulated things like the x86 MMU on it's VLIW hardware. Example: LDADD is actually 4 operations, the chip emulates an atomic operation for one of the simplest instructions. Things I'd like to happen that are kind of opposites: - To be able to run uops programs. Sure Intel says the decoder is great and they gave up on making Itanium performant through compilation. Give us choice. There's no way the hardware decoding of instructions is always the most performant option. GPU manufactures acknowledged their fallibility with lower level frameworks like DX11 and Vulkan, and I hope we'll continue getting lower and lower level access to their hardware as well. - Maybe the chip manufactures could all support a dual operation mode, their legacy ISAs, and a compatible ISA. Look at all these options we have on the way to a convergent ISA: https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://hackaday.com/2021/03/26/undocumented-x86-instructions-allow-microcode-access/ https://hackaday.com/2021/03/26/undocumented-x86-instruction... The above mentioned Transmeta Crusoe implements an x86 VM. Zilog Z80 is an Intel 8080 with renamed instructions. The Web Assembly route is too high level, it's still running on top of the OS even. Java is cool as is .Net IR, but they also just use assembly. Give me the flexibility of the Gigatron to target two different ISAs : https://hackaday.com/2019/07/02/emulating-a-6502-in-rom/ https://hackaday.com/2019/07/02/emulating-a-6502-in-rom/

222 points by NavinF 3y ago

dtx1 3y ago

yeah, no. Tooling support, driver support and general Optimization matters. So does platform maturity. 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.

circuit10 3y ago
Having an Oracle Cloud Free Tier ARM VPS it’s surprising how much just works, I think the only thing I couldn’t run was Chrome Remote Desktop (yes, I want to remote into my VPS sometimes, for example it’s the easiest way to leave a GUI program running in the background without leaving my PC on) and only a few other things needed extra steps. But it’s probably a lot different on desktop or if you’re running different types of programs
- wolf550e 3y ago
  Some libraries have x86 SIMD code but no ARM SIMD code, so benchmarking real world use cases you compare SIMD vs scalar code and x86 is much faster. Server side libraries for ARM are a less mature situation than x86.
rektide 3y ago
We don't know, is the only good answer. We haven't done much trying in the past 10 years. Intel's Lakefield was doing quite well in the tablet/MID space. It also had the disadvantages of both comparatively ancient Atom-esque cores- far worse than Intel's new E cores-and a massive massive huge Skylake core. Oh and a replayed decade old desktop iGPU too. 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.
hedora 3y ago
These benchmarks suggest arm has been at single threaded performance parity on server since 2020: https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/5 https://www.anandtech.com/show/15578/cloud-clash-amazon-grav... (Apple Silicon blows them away on laptops, of course.)
- tyingq 3y ago
  I imagine some of the remaining gap might be places where inline ASM or things like SIMD, AVX, etc, exist. Where there's been more years and a larger set of people optimizing that ASM for x86/64 servers.
  - GeekyBear 3y ago
    > the remaining gap might be places where inline ASM or things like SIMD, AVX, etc, exist 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. https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/
kaelinl 3y ago
This isn't the point of the article. 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.
- Jasper_ 3y ago
  Yeah, ARM's big advantage is that they are willing to make absolutely zero margin on chips, which allows them to play both ends of the spectrum. They can make Celeron-tier chips that don't take any power and practically given away for free and use that as evidence of ARM's superiority in things like the M1 and supercomputers. 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.
- IshKebab 3y ago
  I'm not sure I buy that. x86 chips have targeted laptops for decades, yet they were absolutely walloped by Apple's ARM chips. IIRC a big part of that is that the ARM ISA has 2/4 byte instructions whereas x86 can be crazy sizes which made it easier for Apple to have 8 instruction decoders. At least that's the best theory I heard for why it is so fast.
jsheard 3y ago
> You don't want your phone to run x86 (and it won't for a while) 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.
- kelnos 3y ago
  I think that's the point, though: why didn't they stick? Was it a price/performance/power issue, which would point to ARM being somehow "better" on those dimensions, or was it something incidental, like production availability, or even just perhaps a lack of desire at Intel to aggressively pursue that market?
  - amluto 3y ago
    At least some of the attempts in question had, ahem, interesting ideas for how to combine baseband and AP on one chip. (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.)
- rsaxvc 3y ago
  You could even get an AMD chip in your XPPhone https://www.umpcportal.com/products/XPPhone/XPPhone https://www.umpcportal.com/products/XPPhone/XPPhone :p
- eloisant 3y ago
  The biggest issue is that ARM was already king, so x86 was an exception that wasn't always accounted for. So there was occasional incompatibilities and no real benefit to balance them.
dehrmann 3y ago
It sounds like Atom could have found a home in phones.

isidor3 3y ago

It is interesting to me how both instruction sets have converged on splitting operations into simpler micro ops. The author briefly mentions RISC-V as having "better" core instructions, but it makes me wonder if having the best possible instructions would even help that much. If you made a CPU that directly ran off of some convergent microcode, would you then lose because of bandwidth of getting those instructions to the chip? Or is compressing instruction streams already a pretty-well-solved problem if you're able to do it from a clean slate, instead of being tied to what instruction representations a chip happened to be using many years ago?

circuit10 3y ago
> If you made a CPU that directly ran off of some convergent microcode I think that’s the original idea behind RISC
- mafribe 3y ago
  Microcode is often attributed to [1] from 1952. [1] M. V. Wilkes, J. B. Stringer, Micro-programming and the design of the control circuits in an electronic digital computer.
  - kwhitefoot 3y ago
    It's arguable that Babbage's design for the Analytical Engine included microcode. See, i.a., https://www.fourmilab.ch/babbage/glossary.html https://www.fourmilab.ch/babbage/glossary.html
    - mafribe 3y ago
      Interesting, I had no idea. Wilkes doesn't cite Babbage, oh dear!
- isidor3 3y ago
  Yes, and obviously ARM didn't chose the instructions in its reduced set optimally, if the best implementations require those instructions to be split into smaller ones. But that doesn't really speak to if that's because it's just better to pack instructions that way, or because these implementations of ARM and x86 just need to do it to be performant in spite of deficiencies in their instruction sets.

api 3y ago

Decoder complexity matters. ARM with its single instruction width allows arbitrarily parallel decoders with only linear growth in transistor count. X86 with its many widths and formats requires decoders that grow exponentially in complexity with parallelism, consuming more silicon and power to achieve higher levels of instruction level parallelism. It requires a degree of brute force with many possible size branches being explored at once among other expensive tricks. This is one of the major areas where the instruction sets are not equal. ARM has a distinct efficiency advantage.

jeffbee 3y ago
Does anyone actually care about this? The x86 decoders are not large on modern implementations, and putting more transistors on dice is a well-solved problem.
- api 3y ago
  It uses more power. The decoder is like another ALU that is always screaming at 100%. It means you can easily keep up with ARM in speed but not power efficiency.
  - jeffbee 3y ago
    It doesn't seem to matter in practice. Current generation Intel CPUs and the Apple M2 have very similar performance at the same power levels.
    - rowanG077 3y ago
      How did you arrive at that conclusion? Comparing the M2 Max vs 13650HX it's very obvious the M2 Max uses a LOT less power. It's not even close, it's less then HALF the power. The M2 max has a little worse performance. But it manages to beat the Intel in some benchmarks.
      - jeffbee 3y ago

tux3 3y ago

The x86 decoders consume a reasonable amount of power, but the trouble is making them wider without affecting that. I have an AMD CPU. Zen CPUs come with a fairly wide backend. But the frontend is what it is (especially early Zen), and without SMT it's essentially impossible to keep all those execution units fed. It's not that 8 x86 decoders wouldn't be a benefit, it's just that more decoders isn't cheap in x86 cores, each extra decoder is a serious cost. If you compare with the big ARM cores, having a wide frontend is not a complex research problem or an impractical cost. 8 wide ARM decode is completely practical. You even have open source superscalar RISC-V cores just publicly available on Github running on FPGAs with 8 wide decode. Large frontends are (relatively) cheap and easy, if you're not x86. So when we notice that the narrower x86 CPU's decode doesn't consume that much (a "drop in the ocean"), that's because it was designed narrower to keep the PPA reasonable! The reason I can't feed my Zen backend isn't because having a wide frontend is useless and I should just enable SMT anyways, it's because x86 makes wide decodes much less practical than competing architectures.

ip26 3y ago
It's a trade-off between problems. Variable length instructions are not as trivial to decode wide, so you need more cleverness here. However, fixed length instructions decrease code density, which asks more of the instruction cache. Note Zen4 has a 32 KB L1 instruction cache while the M1 has a 192 KB L1 instruction cache, requiring extra cleverness here instead to handle the higher latency and area. Meanwhile, micro-op caches hide both problems. The are ripple effects to consider as well. The large L1 caches of M1 (320 KB total) put capacity pressure on L2, towards larger sizes and/or away from inclusive policy. See the 12MB shared L2. Meanwhile, the narrower decode of Zen4 puts pressure on things like branch prediction accuracy & mispredict correction latency - if you predicted the wrong codepath, you can't catch up as quickly. See the large branch predictors on Zen4.
- pclmulqdq 3y ago
  ARM used to find itself on the wrong side of this tradeoff in the era of 4-wide x86 decode units and 4-6 wide ARM decoders. They lost too much perf to cache size for the decoder width to make up for it. It's unclear to me if they will pull ahead on the perf/area game with the era of 8-wide x86 decoders coming.

TheLoafOfBread 3y ago

What does matter is standardization. For example a booting process. When I have x86 image of Windows/Linux, I can boot it on any x86 processor. When I have ARM image, well, then I can boot it on a SoC it is built for and that's big maybe because if outside peripherals are different (i.e. different LCD driver) or lives on different pins of SoC, then I am screwed and will have at best partially working system. Standardization is something what will carry x86 very far into the future despite its infectivity on low power devices.

nubinetwork 3y ago
> When I have ARM image, well, then I can boot it on a SoC it is built for ... or lives on different pins of SoC, then I am screwed and will have at best partially working system. That's not even the half of it either... what firmware does the board run? U-boot is nice, but sometimes you aren't lucky and you're stuck with something proprietary. Although if you're extremely lucky, you'll have a firmware that supports efi kernels.
dehrmann 3y ago
> When I have x86 image of Windows/Linux, I can boot it on any x86 processor. Where this gets absurd is modern Debian supports i686 and up. You should be able to get a 27-year-old Pentium Pro to boot the same image as a Raptor Lake CPU.
- sliken 3y ago
  My memory is that the pentium pro had a common memory config of 256MB, way below what modern installers are going to expect. I'm sure you can get linux to install on 256MB, but I doubt it's going to work on the current RHEL/SUSE/Ubuntu installers. Not to mention various drivers have gone without maintainers and pulled from the upstream linux kernel. Not to mention dropping IA32 and related PAE support.
GeekyBear 3y ago
> When I have x86 image of Windows/Linux, I can boot it on any x86 processor. This has come with a stack of caveats since the advent of Secure Boot.

dehrmann 3y ago

This would explain part of why Apple hasn't been pushing M2 for the data center. Its chips are a better fit for bursty human workloads, not server workloads.

rowanG077 3y ago
Apple doesn't see value in going after the server market.
- XorNot 3y ago
  The consumer might replace their laptop once a year, at a fast cadence, but they don't wake up one day and say "I actually need 3 laptops". Whereas datacenters are now being built constantly, and any future projection would estimate that we're going to keep building more - and if you were unsure before, then the sudden popularity of training AIs and their massive demand for compute should've convinced you. Apple aren't going to leave money on the table (otherwise they'd still be shipping iPhones with chargers and including dongles with laptops): if they're not targeting server markets, it's because their internal modelling is telling them that what they've got is probably at best a peer-capability, rather then some type of vast excession (or would be wiped out easily by another gen of server grade chip releases).
  - pjmlp 3y ago
    Apple already failed twice on the server market, A/UX and Xserve, and decided it wasn't for them. They would have to offer a top option with macOS to make it relevant, as they certainly aren't going to be offering their hardware to run GNU/Linux on top of it. It happened once, with MkLinux, and that is also something that management won't be keen in repeating.
KerrAvon 3y ago
Apple Silicon chips aren’t for sale outside Apple, and Apple hasn’t made any products relevant to data centers since they terminated the Xserve line as part of the PowerPC -> Intel transition.

skissane 3y ago

I wonder where we’d be if the idea of CPU-independent bytecode had ever really taken off - for example, the TIMI bytecode of IBM System/38 and AS/400, TenDRA TDF (aka OSF ANDF), WebAssembly. You could have an AOT compiler in the system firmware which the OS invokes, when a program is installed the OS uses AOT to convert it to the actual machine code, about which the OS might know nothing, and could vary incompatibly from CPU to CPU, even among different CPU models in the same family. (Maybe a JIT mode too.) I guess JVM/CIL are somewhat similar, but at a much higher level - I’m not talking about garbage collection or type safety. In some ways that is true of TIMI too - it is designed to support a capability-based operating system, and hence has some rather high-level instructions, although still not as high level as JVM/CIL - it was generally used as a compilation target for non-garbage collected languages such as RPG, COBOL, C/C++, PL/I, Fortran, BASIC, Pascal, etc - and hence lacks a garbage collector.

tadfisher 3y ago
Transmeta Crusoe? They chose X86 machine code as their CPU-independent bytecode.
- zdw 3y ago
  In demos the Transmeta processors was shown to support multiple instruction sets - per https://en.wikipedia.org/wiki/Transmeta#Code_Morphing_Software https://en.wikipedia.org/wiki/Transmeta#Code_Morphing_Softwa... , they demoed pico-Java , and also there were rumors of PowerPC compatibility. Although you're probably right - none of those options made it into a shipping product, only x86.
- fathyb 3y ago
  I guess today's equivalent VLIW chip would be Tachyum Prodigy, not super confident about it.. https://www.tachyum.com/products/#products-prodigy https://www.tachyum.com/products/#products-prodigy
  - hurpdurpdurp 3y ago
    Nvidia's denver2 cores work this way. Shipped on an android tablet about 10 years ago. Not sure what happened to them after that.

fanf2 3y ago

x86 is not a very CISCy CISC, compared to VAX or 68020. x86 has relatively simple addressing modes and often limits instructions to one memory operand. It would be interesting to see how well a modern VAX or 68k could compete with x86 and ARM.

ggm 3y ago
I came here to say much the same. The labels were defined (CISC/RISC) in a time of different costs and CPUs. Roll forward, and both RISC has become more complex and CISC has adopted many features of RISC. I would have loved to see more clear signs of how much L1/L2 cache plays here, and the interconnect between cores. I suspect we're now well down a path where writing code to fit into L1 and writing code to balance load across cores has more importance than anything else. (not a VLSI or ISA person btw)

apatheticonion 3y ago

I look forward to the day when ISA doesn't matter. Picking an ARM laptop because right now the technology is better suited to mobile applications while having an x86 desktop because that's the best technology for that right now seems sensible. Translation layers are constantly improving - maybe soon we will be able to play games and run software with the same level of performance/reliability regardless of the CPU architecture.

drpixie 3y ago

This RISC/CISC debate made a lot of sense when the "guts" of the CPU (decoder, registers, ALU, etc) occupied almost the whole chip (or box of transistors), and when memory and CPU had similar speeds. The situation now is very different. The vast majority of the chip is cache. The trade-off for a much bigger decoder (or register stack, or whatever) is now just a fractionally smaller cache. And on current systems the CPU and memory operate at enormously different speeds - memory is 10+ times slower than the CPU. So to keep the CPU even vaguely busy, we have resorted to enormous caches. And we use large numbers of cores & threads, so that when one thread is waiting for memory, others may be able to run. The old game was max performance from a limited number of gates. The current situation makes such enormous numbers of gates available (even on tiny, cheap chips) that we're playing an altogether different game.

sweetjuly 3y ago
While area is now very cheap, power and thermal is more of an issue than ever. Huge d/i caches are doable since they save power, huge arrays of decoders not so much. The CISC-RISC debate wasn't just based on area; everyone back then also saw the direction that scaling was taking us.
branko_d 3y ago
> memory is 10+ times slower than the CPU The difference is much greater than that - one uncached RAM access can take hundreds of CPU cycles.
- deleted 3y ago
  [deleted]
audunw 3y ago
The interesting part of RISC vs CISC now isn't the complexity of the instructions or whether they're variable or fixed length. Both ARM and RISC-V has aspects that could be considered CISC-like in that regard. The interesting difference is the memory model of the instructions. What kind of dependencies between instructions you have to keep track of when decoding them. If I understand correctly, that's the thing that makes it very hard to scale x86 wider, as talked about in another top comment in this thread. The decoder doesn't necessarily scale linearly with the width of the decoder. Since ARM and RISC-V hasn't traditionally competed in the very high end ultra-wide superscalar CPU space until recently, it's possible that we're not going to see x86 held back until more advanced ARM/RISC-V manages to scale to a wider architecture than what x86 is reasonably capable of.

titzer 3y ago

> In fact, several workloads saw less power draw with the op cache was disabled. Decoder power draw was drowned out by power draw from other core components, especially if the op cache kept them better fed. That lines up with Jim Keller’s comment. There's a hidden problem here: disabling the opcache couldn't possibly improve the power draw of other components. The system is simply doing less work per unit time because it issues fewer instructions in the same time. This is a common benchmarking problem when the workload isn't fixed, e.g. when a benchmark tries to run as many iterations it can in N seconds. By increasing execution speed (or in this case, decreasing it), you also increase the total amount of work done per unit time.

MobiusHorizons 3y ago

I have wondered something for a while. x86 (32 and 64 bit) have much smaller instruction size on average than RISC ISAs. Given that modern compute performance is heavily affected by cache performance and memory latency, it seems like the smaller codesize could really help with caching performance. Is this actually a factor? Does arm need bigger caches to combat this? Or does the unpredictability of unguessable instruction offsets ruin this in some way? It's obviously only one factor among menay, and ram is often filled with data not just code, but I've wondered about it for a while.

tuetuopay 3y ago
If memory serves, the net code density is on par between x86 and ARM. Of course if you take some small code samples, yeah, it's an easy win for x86, but for real world programs, there end up being no measurable difference.
- renox 3y ago
  > the net code density is on par between x86 and ARM It was similar with Thumb, but now that there's ARMv8, ARM code density has probably decreased.

abainbridge 3y ago

edit: The emphasis is wrong here. The main benefit of a relaxed memory model is that it reduces the amount of work the memory subsystem HW needs to do. Another ISA difference not discussed by the article is the memory model. I expect that the memory model and the degree of reordering permitted by the architecture could have a significant impact on performance. x86 imposes stricter ordering constraints on memory accesses. The choice of this memory model was made long ago, when, I guess, it was felt that this made the behaviour easier to understand for the programmer. In contrast, ARM's memory model permits more reordering of memory accesses, which can lead to potential data races and inconsistent program behavior. However, this greater flexibility can also lead to higher performance, as the processor can execute memory accesses in a more efficient manner by overlapping and reordering them. I can't find any studies that measure the impact of this, but I'd be surprised if it wasn't a significant win for the ARM ISA in many programs.

tialaramex 3y ago
For languages like C++ and Rust the memory model is part of the language and so is taken into consideration by the compiler backend too. Code that's explicitly asking for Relaxed (the fastest ordering, which has no benefit on x86) is fairly rare.
- abainbridge 3y ago
  Hmmm. Fair point. I got this argument from a HW engineer I know. You forced me to think more about what he was saying. His point was actually that the TSO model requires the HW to keep track of more stuff. More stuff uses more energy and adds latency to every memory access. It also limits how many accesses the memory subsystem can handle in parallel. He points out that ARM, RISC-V and even ia64 (Itanium) chose the relaxed model because it is better.

hilbert42 3y ago

Very interesting article. If its assertions and conclusions are correct then it's very useful information. I've been somewhat suspicious of CISC processors with large microcode real estate ever since the days of the Pentium bug, which was, if I recall correctly, when microcode began to quickly increase in complexity. (I'm not a processor designer but it seems to me that with increased size and complexity bugs would be more likely.) Alternatively, RISC seemed too limited, but then I'm viewing this from a programming perspective—not that of processor design. Probably the most interesting aspect of the article was Jim Keller's point about the 'cleanness' of the newer RISC-V architecture, as that may settle the ongoing comparisons and arguments over it and ARM. For people like me who want to see more independent and open hardware architecture available, it'll be interesting to see how that plays out over time.

undersuit 3y ago

The chart of how the A64FX supercomputer chip uses uops is telling: https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021/07/image-1.png?resize=768%2C558&ssl=1 https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021... We're targeting hardware compilers. At this point why not just do the Transmeta route again and abstract that last bits of specialty hardware. The Crusoe emulated things like the x86 MMU on it's VLIW hardware. Example: LDADD is actually 4 operations, the chip emulates an atomic operation for one of the simplest instructions. Things I'd like to happen that are kind of opposites: - To be able to run uops programs. Sure Intel says the decoder is great and they gave up on making Itanium performant through compilation. Give us choice. There's no way the hardware decoding of instructions is always the most performant option. GPU manufactures acknowledged their fallibility with lower level frameworks like DX11 and Vulkan, and I hope we'll continue getting lower and lower level access to their hardware as well. - Maybe the chip manufactures could all support a dual operation mode, their legacy ISAs, and a compatible ISA. Look at all these options we have on the way to a convergent ISA: https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://hackaday.com/2021/03/26/undocumented-x86-instructions-allow-microcode-access/ https://hackaday.com/2021/03/26/undocumented-x86-instruction... The above mentioned Transmeta Crusoe implements an x86 VM. Zilog Z80 is an Intel 8080 with renamed instructions. The Web Assembly route is too high level, it's still running on top of the OS even. Java is cool as is .Net IR, but they also just use assembly. Give me the flexibility of the Gigatron to target two different ISAs : https://hackaday.com/2019/07/02/emulating-a-6502-in-rom/ https://hackaday.com/2019/07/02/emulating-a-6502-in-rom/