5 ms·

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 i

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.
  - renox 6y ago
    > it didn't win out. It didn't win because 1) making a top performing CPU is very expensive 2) you can only only recoup your investment by selling a lot of CPUs. So you need to be very efficient with the installed base of software.. While in the past this favored x86 / x86-64 compatibility, this is shifting towards ARM compatibility.. Maybe this will favour experimentations? ARM ISA is far less complex to implement so from a technical POV this could help companies trying to experiment.
    - cpgxiii 6y ago
      > So you need to be very efficient with the installed base of software That's only somewhat true. Until the modern era of cloud hyperscalers, fairly weird architectures with poor compatibility were quite successful, especially in HPC and defense markets. Cell and its derivatives were successful for their time. Any number of quirky microcontroller architectures were successful before the Cortex-M family came to dominate (and some still are). Yes, the startup costs are always going to be high, but success in the broader market isn't necessary for a performant architecture to survive. > Maybe this will favour experimentations? I don't think so, if anything the high performance aarch64 designs like Apple's M1 are more similar to x86_64 designs than previous generations. Large caches, wide execution, serious OoO, stronger-than-expected memory ordering. I think more experimentation will come from the RISC-V community targeting more specific applications.
pjmlp 6y ago
CUDA was redesigned to work like C++ actually.

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.
- renox 6y ago
  > it didn't win out. It didn't win because 1) making a top performing CPU is very expensive 2) you can only only recoup your investment by selling a lot of CPUs. So you need to be very efficient with the installed base of software.. While in the past this favored x86 / x86-64 compatibility, this is shifting towards ARM compatibility.. Maybe this will favour experimentations? ARM ISA is far less complex to implement so from a technical POV this could help companies trying to experiment.
  - cpgxiii 6y ago
    > So you need to be very efficient with the installed base of software That's only somewhat true. Until the modern era of cloud hyperscalers, fairly weird architectures with poor compatibility were quite successful, especially in HPC and defense markets. Cell and its derivatives were successful for their time. Any number of quirky microcontroller architectures were successful before the Cortex-M family came to dominate (and some still are). Yes, the startup costs are always going to be high, but success in the broader market isn't necessary for a performant architecture to survive. > Maybe this will favour experimentations? I don't think so, if anything the high performance aarch64 designs like Apple's M1 are more similar to x86_64 designs than previous generations. Large caches, wide execution, serious OoO, stronger-than-expected memory ordering. I think more experimentation will come from the RISC-V community targeting more specific applications.

pjmlp 6y ago

CUDA was redesigned to work like C++ actually.