6 ms·

> The reality is that the reasons these chips are fast are either unknown or boring. I suspect that these will one out as we play around with them more, but we

> The reality is that the reasons these chips are fast are either unknown or boring. I suspect that these will one out as we play around with them more, but we don’t have the details right now. I disagree, I think we have plenty of information. This is what happens when a huge proportion of your die isn't doing instruction decoding. x86/amd64 are old and crufty. Lessons have been learned, and had been learned for some time, but people (AMD/Intel) were not brave enough to fix them because they didn't have adequate control of their software ecosystem to say, "Your software from your old computer will not run/will not run as well on your new computer." (For emphasis, let me just put it clearly what I'm claiming: x86 was designed in the 1970s. This is what happens when you use an ISA that was not designed in the 1970s.) Apple, however, does have control of their ecosystem, and they're allowed to be brave, provided they can support their ecosystem. Here's my hot take: Intel tried to be brave with Itanium, but failed because compilers weren't up to the job at the time. That's changed. First things first, we're going to see mainstream desktop-class/laptop-class ARM being extended to linux and Windows. But I also believe that sometime in the next ten years, after all this newfangled high-performance ARM stuff is sorted out, we're also going to see someone give VLIW another shot, and they're going to succeed this time.

atq2119 6y ago
This is what happens when a huge proportion of your die isn't doing instruction decoding. That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs. I'm sure the instruction encoding plays some role, but I suspect what we're seeing is rather down to consistently good micro-architecture execution over the years and Apple being ahead of everybody else on manufacturing process. Compared to the x86 processors that exist today, M1 also benefits from having the memory in-package. Intel tried to be brave with Itanium, but failed because compilers weren't up to the job at the time. Compilers "failed" because VLIW is fundamentally not a particularly useful idea. The main problem for general purpose single-thread performance is memory latency, and VLIW just doesn't help there.
- danmaz74 6y ago
  Doesn't Apple use TSMC manufacturing?
  - ylyn 6y ago
    Yes, and they are the only ones on TSMC 5nm currently.
    - anfilt 6y ago
      That's because apple bought the entire 5nm production capacity/runs for basically for the entire last quarter of 2020. I can tell you some companies were not too pleased about that.
      - chris_j 6y ago
        Which companies?
        fmajid 6y ago
        AMD.
      - joachimma 6y ago
        Is there anything preventing those companies from "ganging" up on Apple and buying capacity jointly? Are they too many and too small? Is it possible to share wafer-space with other companies or does having multiple designs add too much complexity/cost?
        nicoburns 6y ago
        I think Apple essentially outbid them, which it was able to do because it is has both large volume and large profit margins.
      - raverbashing 6y ago
        Ah yeah, Apple has f-you money and it knows how to use it.
djcapelis 6y ago
> we're also going to see someone give VLIW another shot Dunno why people would keep thinking this is a good idea, but if someone wants to try eating it with a new VLIW design yet again, I’m always down for some popcorn. Dynamically finding ILP at instruction dispatch time is always going to be smarter than a compiler trying to guess at compile time. IMO, it’s worth the area. Even if you assume the compiler gets it right and finds tons of ILP, it’ll get it wrong for the next hardware rev when your core inevitably changes and you have to break apart your VLIW instructions and get ILP back dynamically anyway. To say nothing of shared pipelines in an SMT processor, where VLIW basically runs counter to SMT and the only way to know which units are going to be available on a specific cycle is during runtime. > and they're going to succeed this time. I don’t see any reason why VLIW would succeed more in future attempts than in past attempts.
- cakoose 6y ago
  Even if compiler-only ILP is doomed to fail, maybe VLIW optimists are just hoping something useful might come out of everything we've learned? For example, compilers already model the CPU's pipeline and ILP capacity to inform instruction selection. VLIW designs are an attempt to make that cooperation more explicit, similar in spirit to branch/prefetch hints. Maybe there's still a way to do that well? And re: microarchitectural changes in the next hardware rev: https://news.ycombinator.com/item?id=25237056 https://news.ycombinator.com/item?id=25237056 These ideas might ultimately fail, but they seem worth looking in to, at least.
  - djcapelis 6y ago
    I think you are correct that there is a section of the field enchanted by the idea of VLIW and desperately hoping to justify any possible reason why building these chips was less of a bad notion than they’ve turned out to be each and every time. I don’t think we’re really learning much by pretending building a new one is a good idea. Or that the last efforts had much value. No one is saying don’t make progress on compilers. Look around you and you’ll see the things you just referenced already exist in practice in production today. (Among others: compiler/architecture co-design is a well established and fertile area of work. Compiling to intermediate formats which specialize for a device later is in use to some degree in App Store, which keeps programs in an intermediate format and thins binaries down to specific slices on demand for iOS devices, etc.) None of these technologies justify building a new VLIW chip or have frankly much to do with those efforts. The best thing we could learn from the huge amount of effort that’s gone into VLIW architectures is actually learn the lesson that in front of us, demonstrated repeatedly, that unless something substantial changes, VLIW does not produce a better architecture for processor cores and the assumption that it would was wrong.
mpweiher 6y ago
> Intel tried to be brave with Itanium Intel tried to be brave with the 432. And failed. The 8086 was rushed as a stopgap. It was never intended as a serious design. Intel tried to be a little brave with the 286. And failed. Intel tried to be brave with the i860. And failed. Intel tried to be brave with Itanium. And failed. In the meantime Intel have made countless of billions with souped up 8086s. And we're stuck with them. Or were.

atq2119 6y ago

This is what happens when a huge proportion of your die isn't doing instruction decoding. That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs. I'm sure the instruction encoding plays some role, but I suspect what we're seeing is rather down to consistently good micro-architecture execution over the years and Apple being ahead of everybody else on manufacturing process. Compared to the x86 processors that exist today, M1 also benefits from having the memory in-package. Intel tried to be brave with Itanium, but failed because compilers weren't up to the job at the time. Compilers "failed" because VLIW is fundamentally not a particularly useful idea. The main problem for general purpose single-thread performance is memory latency, and VLIW just doesn't help there.

danmaz74 6y ago
Doesn't Apple use TSMC manufacturing?
- ylyn 6y ago
  Yes, and they are the only ones on TSMC 5nm currently.
  - anfilt 6y ago
    That's because apple bought the entire 5nm production capacity/runs for basically for the entire last quarter of 2020. I can tell you some companies were not too pleased about that.
    - chris_j 6y ago
      Which companies?
      - fmajid 6y ago
        AMD.
    - joachimma 6y ago
      Is there anything preventing those companies from "ganging" up on Apple and buying capacity jointly? Are they too many and too small? Is it possible to share wafer-space with other companies or does having multiple designs add too much complexity/cost?
      - nicoburns 6y ago
        I think Apple essentially outbid them, which it was able to do because it is has both large volume and large profit margins.
    - raverbashing 6y ago
      Ah yeah, Apple has f-you money and it knows how to use it.

djcapelis 6y ago

> we're also going to see someone give VLIW another shot Dunno why people would keep thinking this is a good idea, but if someone wants to try eating it with a new VLIW design yet again, I’m always down for some popcorn. Dynamically finding ILP at instruction dispatch time is always going to be smarter than a compiler trying to guess at compile time. IMO, it’s worth the area. Even if you assume the compiler gets it right and finds tons of ILP, it’ll get it wrong for the next hardware rev when your core inevitably changes and you have to break apart your VLIW instructions and get ILP back dynamically anyway. To say nothing of shared pipelines in an SMT processor, where VLIW basically runs counter to SMT and the only way to know which units are going to be available on a specific cycle is during runtime. > and they're going to succeed this time. I don’t see any reason why VLIW would succeed more in future attempts than in past attempts.

cakoose 6y ago
Even if compiler-only ILP is doomed to fail, maybe VLIW optimists are just hoping something useful might come out of everything we've learned? For example, compilers already model the CPU's pipeline and ILP capacity to inform instruction selection. VLIW designs are an attempt to make that cooperation more explicit, similar in spirit to branch/prefetch hints. Maybe there's still a way to do that well? And re: microarchitectural changes in the next hardware rev: https://news.ycombinator.com/item?id=25237056 https://news.ycombinator.com/item?id=25237056 These ideas might ultimately fail, but they seem worth looking in to, at least.
- djcapelis 6y ago
  I think you are correct that there is a section of the field enchanted by the idea of VLIW and desperately hoping to justify any possible reason why building these chips was less of a bad notion than they’ve turned out to be each and every time. I don’t think we’re really learning much by pretending building a new one is a good idea. Or that the last efforts had much value. No one is saying don’t make progress on compilers. Look around you and you’ll see the things you just referenced already exist in practice in production today. (Among others: compiler/architecture co-design is a well established and fertile area of work. Compiling to intermediate formats which specialize for a device later is in use to some degree in App Store, which keeps programs in an intermediate format and thins binaries down to specific slices on demand for iOS devices, etc.) None of these technologies justify building a new VLIW chip or have frankly much to do with those efforts. The best thing we could learn from the huge amount of effort that’s gone into VLIW architectures is actually learn the lesson that in front of us, demonstrated repeatedly, that unless something substantial changes, VLIW does not produce a better architecture for processor cores and the assumption that it would was wrong.

mpweiher 6y ago

> Intel tried to be brave with Itanium Intel tried to be brave with the 432. And failed. The 8086 was rushed as a stopgap. It was never intended as a serious design. Intel tried to be a little brave with the 286. And failed. Intel tried to be brave with the i860. And failed. Intel tried to be brave with Itanium. And failed. In the meantime Intel have made countless of billions with souped up 8086s. And we're stuck with them. Or were.