3 ms·
Itanium was a really badly designed architecture, which a lot of people skip over when they try to draw analogies to it. It was a worst of three worlds, in that
by Veedrac 4y ago
Itanium was a really badly designed architecture, which a lot of people skip over when they try to draw analogies to it. It was a worst of three worlds, in that it was big and hot like an out-of-order, it had the serial dependency issues of an in-order, and it had all the complexity of fancy static scheduling without that fancy scheduling actually working.
There have been a small number of attempts since Itanium, like NVIDIA's Denver, which make for much better baselines. I don't think those are anywhere close to optimal designs, or really that they tried hard enough to solve in-order issues at all, but they at least seem sane.
- speed_spread 4y agoWould Itanium have been better served with bytecode and a modern JIT? Also, doesn't RISC-V kinda get back on that VLIW track with macro-ops fusion, using a very basic instruction set and letting the compiler figure out the best way to order stuff to help target CPU make sense of it?
- Veedrac 4y agoThose are all very different things. It is probably possible to argue that using a JIT would have solved some of Itanium's compilation issues, like it would make it easier to make compilation decisions about where to do software data miss handling, but I don't think it would have made the hardware fundamentally more sensible, or all that performant. RISC-V isn't really anything like VLIW, it is about as close to a traditional RISC as anything gets nowadays, and macro-op fusion is just a simple front end trick that doesn't overly influence whether the back end is in-order or out-of-order (or whatever else).
- nine_k 4y agoI heard that the desire to make x86 emulation performant on Itanium made things really bad, compared to a "clean" VLIW architecture.