5 ms·

This is kind of what should happen right? I'm not an expert, but my understanding is that one of the takeaways from the M1 success has been the weaknesses of x

by skohan 6y ago

This is kind of what should happen right? I'm not an expert, but my understanding is that one of the takeaways from the M1 success has been the weaknesses of x86 and CISC in general. It seems as if there is a performance ceiling which exists for x86 due to things like memory ordering requirements, and complexity of legacy instructions, which just don't exist for other instruction sets. My impression is that we have been living under the cruft of x86 because of inertia, and what are mostly historical reasons, and it's mostly a good thing if we move away from it.

sf_rob 6y ago
Isn't most of M1's performance success due to being a SoC / increasing component locality/bandwidth? I think ARM vs x86 performance on its own isn't a disadvantage. Instead the disadvantages are a bigger competitive landscape (due to licensing and simplicity), growing performance parity, and SoCs arguable being contrary to x86 producers' business models.
- UncleOxidant 6y ago
  ARM instructions are also much easier to decode than x86 instructions which allowed the M1 designers to have more instruction decoders and this, IIRC, is one of the important contributors to the M1's high performance.
- erosenbe0 6y ago
  Umm, Intel laptop chips are SoC with onchip graphics, pci4, wifi, usb4, and thunderbolt4 controller, connectivity direct to many audio codec channels, plus some other functionality for dsp and encryption.
kllrnohj 6y ago
> weaknesses of x86 and CISC in general "RISC" and "CISC" distinctions are murky, but modern ARM is really a CISC design these days. ARM is not at all in a "an instruction only does one simple thing, period" mode of operation anymore. It's grown instructions like "FJCVTZS", "AESE", and "SHA256H" If anything CISC has overwhelmingly and clearly won the debate. RISC is dead & buried, at least in any high-performance product segment (TBD how RISC-V ends up fairing here). It's largely "just" the lack of variable length instructions that helps the M1 fly (M1 under Rosetta 2 runs with the same x86 memory model, after all, and is still quite fast).
- setpatchaddress 6y ago
  Most RISCs would fail the "instruction only does one thing" test. ISTR there were instructions substantially more complex than FJCVTZS in the PowerPC ISA. I think it's time for a Mashey CISC vs RISC repost: https://www.yarchive.net/comp/risc_definition.html https://www.yarchive.net/comp/risc_definition.html
- lambda 6y ago
  RISC vs CISC isn't really about instructions doing "one simple thing period." It's about increased orthogonality between ALU and memory operations, making it simpler and more predictable in an out-of-order superscalar design to decode instructions, properly track data dependencies, issue them to independent execution units, and to stitch the results back into something that complies with the memory model before committing to memory. Having a few crazy-ass instructions which either offload to a specialized co-processor or get implemented as specialized microcode for compatibility once you realize that the co-processor is more trouble than it's worth doesn't affect this very much. What ARM lacks are the huge variety of different instruction formats and addressing mode that Intel has; which substantially affect the size and complexity of the instruction decoder, and I'm willing to bet that creates a significant bottleneck on how large of a dispatch and reorder system they can have. For a long time, Intel was able to make up this difference with process dominance, clever speculative execution tricks, and throwing a lot of silicon and energy at it which you can do on the server side where power and space are abundant. But Intel is clearly losing the process dominance edge. Intel ceded the mobile race a long time ago. Power is becoming more important in the data center, which are struggling to keep up with providing reliable power and cooling to increasingly power-hungry machines. And Intel's speculative execution smarts came back to bite them in the big market they were winning in, the cloud, when it turned out that they could cause information leaks between multiple tenants, leading to them needing to disable a lot of them and lose some of their architectural performance edge. And meanwhile, software has been catching up with the newer multi-threaded world. 10-15 years ago, dominance on single threaded workloads still paid off considerably, because workloads that could take advantage of multiple cores with fine-grained parallelism were fairly rare. But systems and applications have been catching up; the C11/C++11 memory model make it significantly more feasible to write portable lock-free concurrent code. Go, Rust, and Swift bring safer and easier parallelism for application authors, and I'm sure the .net and Java runtimes have seen improvements as well. These increasingly parallel workloads are likely another reason that the more complex front-ends needed for Intel's instruction set, as well as their stricter memory ordering, are becoming increasingly problematic; it's becoming increasingly hard to fit more cores and threads into the same area, thermal, and power envelopes. Sure, they can do it on big power hungry server processors, but they've been missing out on all of the growth in mobile and embedded processors, which are now starting to scale up into laptops, desktops, and server workloads. I should also say that I don't think this is the end of the road for Intel and x86. They have clearly had a number of setbacks of the last few years, but they've managed to survive and thrive through a number of issues before, and they have a lot of capital and market share. They have squeezed more life out of the x86 instruction set than I thought possible, and I wouldn't be shocked if they managed to keep doing that; they realized that their Itanium investment was a bust and were able to pivot to x86-64 and dominate there. They are facing a lot of challenges right now, and there's more opportunity than ever for other entrants to upset them, but they also have enough resources and talent that if they focus, they can probably come back and dominate for another few decades. It may be rough for a few years as they try to turn a very large boat, but I think it's possible.
erosenbe0 6y ago
There isn't any performance ceiling issue. Intel ISA operates at a very slight penalty in terms of achievable performance per watt, but nothing in an absolute sense. I would argue it isn't time for Intel to switch until we see a little more of the future as process nodes may shrink at a slower rate. Will we have hundreds of cores? Field programmable cores? More fixed function hardware on chip, or less? How will high-bandwidth high-latency gddr style memory mix with lower-latency lower-bandwidth ddr memory? Will there be on die memory like hbm for cpus?
zucker42 6y ago
M1's success shows how efficient and advanced the TSMC 5 nm node is. Apple's ability to deliver it with decent software integration also deserves some credit. But I wouldn't interpret it as the death knell for x86.

by skohan 6y ago

sf_rob 6y ago

Isn't most of M1's performance success due to being a SoC / increasing component locality/bandwidth? I think ARM vs x86 performance on its own isn't a disadvantage. Instead the disadvantages are a bigger competitive landscape (due to licensing and simplicity), growing performance parity, and SoCs arguable being contrary to x86 producers' business models.

UncleOxidant 6y ago
ARM instructions are also much easier to decode than x86 instructions which allowed the M1 designers to have more instruction decoders and this, IIRC, is one of the important contributors to the M1's high performance.
erosenbe0 6y ago
Umm, Intel laptop chips are SoC with onchip graphics, pci4, wifi, usb4, and thunderbolt4 controller, connectivity direct to many audio codec channels, plus some other functionality for dsp and encryption.

kllrnohj 6y ago

> weaknesses of x86 and CISC in general "RISC" and "CISC" distinctions are murky, but modern ARM is really a CISC design these days. ARM is not at all in a "an instruction only does one simple thing, period" mode of operation anymore. It's grown instructions like "FJCVTZS", "AESE", and "SHA256H" If anything CISC has overwhelmingly and clearly won the debate. RISC is dead & buried, at least in any high-performance product segment (TBD how RISC-V ends up fairing here). It's largely "just" the lack of variable length instructions that helps the M1 fly (M1 under Rosetta 2 runs with the same x86 memory model, after all, and is still quite fast).

setpatchaddress 6y ago
Most RISCs would fail the "instruction only does one thing" test. ISTR there were instructions substantially more complex than FJCVTZS in the PowerPC ISA. I think it's time for a Mashey CISC vs RISC repost: https://www.yarchive.net/comp/risc_definition.html https://www.yarchive.net/comp/risc_definition.html
lambda 6y ago
RISC vs CISC isn't really about instructions doing "one simple thing period." It's about increased orthogonality between ALU and memory operations, making it simpler and more predictable in an out-of-order superscalar design to decode instructions, properly track data dependencies, issue them to independent execution units, and to stitch the results back into something that complies with the memory model before committing to memory. Having a few crazy-ass instructions which either offload to a specialized co-processor or get implemented as specialized microcode for compatibility once you realize that the co-processor is more trouble than it's worth doesn't affect this very much. What ARM lacks are the huge variety of different instruction formats and addressing mode that Intel has; which substantially affect the size and complexity of the instruction decoder, and I'm willing to bet that creates a significant bottleneck on how large of a dispatch and reorder system they can have. For a long time, Intel was able to make up this difference with process dominance, clever speculative execution tricks, and throwing a lot of silicon and energy at it which you can do on the server side where power and space are abundant. But Intel is clearly losing the process dominance edge. Intel ceded the mobile race a long time ago. Power is becoming more important in the data center, which are struggling to keep up with providing reliable power and cooling to increasingly power-hungry machines. And Intel's speculative execution smarts came back to bite them in the big market they were winning in, the cloud, when it turned out that they could cause information leaks between multiple tenants, leading to them needing to disable a lot of them and lose some of their architectural performance edge. And meanwhile, software has been catching up with the newer multi-threaded world. 10-15 years ago, dominance on single threaded workloads still paid off considerably, because workloads that could take advantage of multiple cores with fine-grained parallelism were fairly rare. But systems and applications have been catching up; the C11/C++11 memory model make it significantly more feasible to write portable lock-free concurrent code. Go, Rust, and Swift bring safer and easier parallelism for application authors, and I'm sure the .net and Java runtimes have seen improvements as well. These increasingly parallel workloads are likely another reason that the more complex front-ends needed for Intel's instruction set, as well as their stricter memory ordering, are becoming increasingly problematic; it's becoming increasingly hard to fit more cores and threads into the same area, thermal, and power envelopes. Sure, they can do it on big power hungry server processors, but they've been missing out on all of the growth in mobile and embedded processors, which are now starting to scale up into laptops, desktops, and server workloads. I should also say that I don't think this is the end of the road for Intel and x86. They have clearly had a number of setbacks of the last few years, but they've managed to survive and thrive through a number of issues before, and they have a lot of capital and market share. They have squeezed more life out of the x86 instruction set than I thought possible, and I wouldn't be shocked if they managed to keep doing that; they realized that their Itanium investment was a bust and were able to pivot to x86-64 and dominate there. They are facing a lot of challenges right now, and there's more opportunity than ever for other entrants to upset them, but they also have enough resources and talent that if they focus, they can probably come back and dominate for another few decades. It may be rough for a few years as they try to turn a very large boat, but I think it's possible.

erosenbe0 6y ago

There isn't any performance ceiling issue. Intel ISA operates at a very slight penalty in terms of achievable performance per watt, but nothing in an absolute sense. I would argue it isn't time for Intel to switch until we see a little more of the future as process nodes may shrink at a slower rate. Will we have hundreds of cores? Field programmable cores? More fixed function hardware on chip, or less? How will high-bandwidth high-latency gddr style memory mix with lower-latency lower-bandwidth ddr memory? Will there be on die memory like hbm for cpus?

zucker42 6y ago

M1's success shows how efficient and advanced the TSMC 5 nm node is. Apple's ability to deliver it with decent software integration also deserves some credit. But I wouldn't interpret it as the death knell for x86.