5 ms·

It's not at all clear that better ways exist for general purpose code. A lot of time and effort has been spent by major players, with very little to success to

It's not at all clear that better ways exist for general purpose code. A lot of time and effort has been spent by major players, with very little to success to show for it. Intel, quite infamously, tried to make "something better" work with several generations of Itanium and failed impressively against the reality that a sufficiently smart compiler cannot be made to work. You can't blame any of the big players for holding back - Intel, MS, and HP were "all in" on Itanium as the 64-bit future - if it could have been made to work, it would have been widely adopted. At the same time, Transmeta was building a X86-on-VLIW, which, guess what, also failed to be a competitive product. Nvidia, of course, decided to pick up from where Transmeta left off to build what ended up being an aarch64-on-VLIW design. In both cases, the hope was that the low-level translation would allow the benefits of a VLIW architecture while avoiding the "sufficiently smart compiler is impossible" problem, and in both cases performance just wasn't good enough to be competitive.

Veedrac 6y ago
> A lot of time and effort has been spent by major players This really isn't the case IMO. Itanium is one attempt 20 years ago, it didn't try to rewrite the world (compatibility with standard C code is a huge crutch; GPUs couldn't exist in that environment for example), and the design sucked. And for 20 years since it has been sufficient to invoke the name to scare away any attempt of actually trying something new, even when they don't make the same mistakes, or even work anything like Itanium. > Transmeta It's in the name: the most significant part of the design was all the effort spent on compatibility with the dominant paradigm, running stock x86 code! That hugely limits what you can do.
- cpgxiii 6y ago
  Itanium was not one attempt, it was several generations of trying to make the concept work. And it didn't. > And for 20 years since it has been sufficient to invoke the name to scare away any attempt of actually trying something new, even when they don't make the same mistakes, or even work anything like Itanium. People have been invoking Itanium for the last 20 years because that's what you do with expensive, painful lessons. Just like "branch delay slots are bad" (MIPS et al) or "no sub-word-size-access is bad" (Alpha) or "there's such a thing as too-relaxed memory ordering" (Alpha) or "putting too much magic in the ISA is bad" (iAPX 432), some lessons don't need to be repeatedly revisited and repeated. I get that the Mill team wants to prove everyone wrong, but the only way to show that is working hardware and that doesn't exist (and given the time they've been working, probably won't ever). > compatibility with standard C code is a huge crutch; GPUs couldn't exist in that environment for example Except, guess what, Cuda and OpenCL look exactly like C in many ways. The major features they don't support (well) are dynamic memory allocations and branchy code - good luck trying to make an architecture work that can't efficiently handle malloc. People have tried a lot of different language+hardware architectures over the years, and all of them have been outperformed by OoO machines. > compatibility with the dominant paradigm, running stock x86 code If either Transmeta or Nvidia could have made a standout VLIW architecture, they would have had plenty of business. Defense and HPC customers have absolutely no problem with esoteric architectures so long as the performance is good enough. You could build the craziest architecture, and if you can show it'll be a winner, the DoE will buy it.
  - Veedrac 6y ago
    > Itanium was not one attempt It was one ISA, and a terrible one at that, which is my point. > Except, guess what, Cuda and OpenCL look exactly like C in many ways. You're missing my point, which is about rewriting the world. C's syntax is not the problem.
    - cpgxiii 6y ago
      > It was one ISA, and a terrible one at that Except, you know, the whole point of VLIW designs was that by offloading complexity to the compiler and runtime you'd be less limited by hardware design decisions and be able to improve with time. Provide real examples of how Itanium could have been done better. > You're missing my point, which is about rewriting the world No, I'm not. "Compatibility with standard C code" means memory allocations and branches. That's it. Most "real" OSs need an MMU, but there are a few research systems that don't. You should also keep in mind that lots of different models have been tried. Compiled machine code? Done. JIT-recompiled machine code? Done. GC'd Lisp on hardware? Done. GC'd ada on hardware? Done. GC'd JVM on hardware? Done. Binary translation to "better" hardware? Done, lots of different times. "Rewrite the world" has been tried a fair number of times before, and it didn't win out. You're also totally missing the point that several architectures, x86/x86_64 most notably, have succeeded because ISA and hardware implementation aren't locked together tightly. Processor designers and users are not nearly as constrained together as you believe.
      - Veedrac 6y ago
        > Except, you know, the whole point of VLIW It's really indicative of the problem I'm talking about that so many people think the options are either a standard, Intel Core-style OoO or Itanium-style VLIW. Not only is VLIW a massive range of potential things, and Itanium is not the natural implementation of it, but I never even said we should go with VLIWs! I'm personally more enamoured with CG-OoO style hierarchical reordering, though were rewriting the world possible I'd do something that exposed more of that to software (probably microthread style). > Provide real examples of how Itanium could have been done better. Although Itanium seems like a dead-end strategy to me, three things it got really wrong were: * software data misprediction recovery, * overly large register files, * compiler target locks in uarch decisions. (Please mind that it's been a while since I looked at the Itanium ISA.) The Mill is sort of what Itanium would be with all the rough edges sanded over, though it's sort of a moot point since the Mill will never exist outside of talks. Again, static schedules aren't the approach I'd advocate for, since there are some things they just can't do.

Veedrac 6y ago

> A lot of time and effort has been spent by major players This really isn't the case IMO. Itanium is one attempt 20 years ago, it didn't try to rewrite the world (compatibility with standard C code is a huge crutch; GPUs couldn't exist in that environment for example), and the design sucked. And for 20 years since it has been sufficient to invoke the name to scare away any attempt of actually trying something new, even when they don't make the same mistakes, or even work anything like Itanium. > Transmeta It's in the name: the most significant part of the design was all the effort spent on compatibility with the dominant paradigm, running stock x86 code! That hugely limits what you can do.

cpgxiii 6y ago
Itanium was not one attempt, it was several generations of trying to make the concept work. And it didn't. > And for 20 years since it has been sufficient to invoke the name to scare away any attempt of actually trying something new, even when they don't make the same mistakes, or even work anything like Itanium. People have been invoking Itanium for the last 20 years because that's what you do with expensive, painful lessons. Just like "branch delay slots are bad" (MIPS et al) or "no sub-word-size-access is bad" (Alpha) or "there's such a thing as too-relaxed memory ordering" (Alpha) or "putting too much magic in the ISA is bad" (iAPX 432), some lessons don't need to be repeatedly revisited and repeated. I get that the Mill team wants to prove everyone wrong, but the only way to show that is working hardware and that doesn't exist (and given the time they've been working, probably won't ever). > compatibility with standard C code is a huge crutch; GPUs couldn't exist in that environment for example Except, guess what, Cuda and OpenCL look exactly like C in many ways. The major features they don't support (well) are dynamic memory allocations and branchy code - good luck trying to make an architecture work that can't efficiently handle malloc. People have tried a lot of different language+hardware architectures over the years, and all of them have been outperformed by OoO machines. > compatibility with the dominant paradigm, running stock x86 code If either Transmeta or Nvidia could have made a standout VLIW architecture, they would have had plenty of business. Defense and HPC customers have absolutely no problem with esoteric architectures so long as the performance is good enough. You could build the craziest architecture, and if you can show it'll be a winner, the DoE will buy it.
- Veedrac 6y ago
  > Itanium was not one attempt It was one ISA, and a terrible one at that, which is my point. > Except, guess what, Cuda and OpenCL look exactly like C in many ways. You're missing my point, which is about rewriting the world. C's syntax is not the problem.
  - cpgxiii 6y ago
    > It was one ISA, and a terrible one at that Except, you know, the whole point of VLIW designs was that by offloading complexity to the compiler and runtime you'd be less limited by hardware design decisions and be able to improve with time. Provide real examples of how Itanium could have been done better. > You're missing my point, which is about rewriting the world No, I'm not. "Compatibility with standard C code" means memory allocations and branches. That's it. Most "real" OSs need an MMU, but there are a few research systems that don't. You should also keep in mind that lots of different models have been tried. Compiled machine code? Done. JIT-recompiled machine code? Done. GC'd Lisp on hardware? Done. GC'd ada on hardware? Done. GC'd JVM on hardware? Done. Binary translation to "better" hardware? Done, lots of different times. "Rewrite the world" has been tried a fair number of times before, and it didn't win out. You're also totally missing the point that several architectures, x86/x86_64 most notably, have succeeded because ISA and hardware implementation aren't locked together tightly. Processor designers and users are not nearly as constrained together as you believe.
    - Veedrac 6y ago
      > Except, you know, the whole point of VLIW It's really indicative of the problem I'm talking about that so many people think the options are either a standard, Intel Core-style OoO or Itanium-style VLIW. Not only is VLIW a massive range of potential things, and Itanium is not the natural implementation of it, but I never even said we should go with VLIWs! I'm personally more enamoured with CG-OoO style hierarchical reordering, though were rewriting the world possible I'd do something that exposed more of that to software (probably microthread style). > Provide real examples of how Itanium could have been done better. Although Itanium seems like a dead-end strategy to me, three things it got really wrong were: * software data misprediction recovery, * overly large register files, * compiler target locks in uarch decisions. (Please mind that it's been a while since I looked at the Itanium ISA.) The Mill is sort of what Itanium would be with all the rough edges sanded over, though it's sort of a moot point since the Mill will never exist outside of talks. Again, static schedules aren't the approach I'd advocate for, since there are some things they just can't do.