Ironically, it died around the time LLMs/AI started becoming good. I feel like the compiler problems with vliw could be solved to a degree with a purpose built ai
I just think the arch has a similarity to archs like cell where it was planned for a world without the end of dennard scaling and just stopped making sense when we weren't targeting scaling to 10Ghz consumer CPUs and beyond.
The relatively fixed clock period that makes sense post ~2006 also means that the CPU architecture of that made the most sense ~2006 (Tomasulo OoO cores) continues to make sense, with most of the process gains going to just making bigger, wider cores.
The rise of the web—and databases behind it—as the dominant high-end, high-margin workload obsoleted that assumption.
There’s a great presentation floating around where a Compaq-acquired-DEC engineer is trying to justify how great the OpenVMS port from Alpha to Itanium is going, despite benchmarks showing Alpha smoking Itanium running Apache.
Going by my faulty memory, I'd say it wasn't until Tukwila that it was a clear win over Alpha EV7z. By the time Tukwila arrived, it was pretty clear that Itanium's goose was already cooked.
The other one I can't find I swear was a former AMD engineer talking about how Intel bet the farm on one ibm mainframe design but AMD went with an older architecture (under the hood of x86 for both) that was harder to deal with but ultimately runs faster and that's how we got ryzen. Maybe I'm just losing my mind.
Still have a lot of nostalgia for the architecture.
> I said, wait I am sorry to derail this meeting. But how would you use a simulator if you don't have a compiler? He said, well that's true we don't have a compiler yet, so I hand assembled my simulations. I asked "How did you do thousands of line of code that way?" He said “No, I did 30 lines of code”. Flabbergasted, I said, "You're predicting the entire future of this architecture on 30 lines of hand generated code?" [chuckle], I said it just like that, I did not mean to be insulting but I was just thunderstruck. Andy Grove piped up and said "we are not here right now to reconsider the future of this effort, so let’s move on".
https://www.sigmicro.org/media/oralhistories/colwell.pdf
> Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average system-wide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis.
http://courses.cs.washington.edu/courses/csep590/06au/projec...
When the Itanium was developed and introduced (2001), nobody was thinking about general-purpose computations. DirectX 8.0, which introduced Shader Model 1.1 (which was far away from being suitable for GPGPU; Shader Model 1.1 was rather about strongly (also size-)limited programs for the vertex and pixel processing stage), was only introduced in 2000, the first release of CUDA was in 2007, and the first release of OpenCL was in 2009.
For those who are not so deep into GPU architecture:
ROP: Raster Operation Pipeline
> https://en.wikipedia.org/w/index.php?title=Render_output_uni...
This link requires a log-in.
https://courses.cs.washington.edu/courses/csep590a/06au/proj...
I worked at an HP shop, and Itanium ran HP/UX so they kept running their business on their PickBASIC (and whatever database that I've forgotten the name of) system
Combine that with the fact that the hardware development process seems to have been compromised from the start (if you told me the hardware architects never looked at anything other than 30-instruction traces of BLAS kernels, I'd believe you), and the insane hype that was built up for it... it's not surprising that it had an extremely underwhelming launch.
The fundamental issue is that there simply doesn't exist enough information to be able to extract the necessary parallelism without a rewrite, its the same issue as trying to autovectorise. You can do it to some degree, but it doesn't work in practice to be able to fill out a very wide architecture with reasonable efficacy
The SIMT programming model has proven to be much more successful vs trying to autovectorise or mash things into a VLIW architecture
The "SIMT programming model" is the same thing that in 1963 was called "Parallel DO" (from the name of the loop statement in FORTRAN), and later it was more frequently called "Parallel FOR", like in the C/C++ version of OpenMP. In the influential research paper on which later the programming language Occam was based, C.A.R. Hoare referred to the same thing as "an array of processes".
The "SIMT programming model" just means that you write iterative structures where the programmer guarantees that the iterations are independent (unless specified otherwise), so that their order of execution does not matter.
In CUDA it is slightly less obvious than in OpenMP that the so-called "CUDA kernel" is the body of a loop, because the header of the loop is not adjacent, but it is placed elsewhere in the file.
The essential difference between the "SIMT programming model" and writing a "for" loop in C is that the compiler is certain that the iterations are independent. For auto-vectorization, the compiler must prove that they are independent, which can be difficult.
Compiling for a VLIW CPU is in general a much more difficult problem than auto-vectorization (which implements data parallel processing with multiple cores and/or SIMD cores).
A VLIW CPU is able to execute in parallel distinct instructions, not only the same kind of operation like a SIMD CPU, but in most cases there are complex restrictions about what kind of instructions may be combined.
It can be too difficult for a compiler find a schedule for the instructions in such a way that this would allow a maximum number of instructions executed per clock cycle.
Probably the worst part is that it is unlikely to be able to keep busy all execution units without speculative execution of the instructions that are beyond conditional jumps. For these, it is pretty much impossible to guess an optimal schedule at compile-time, because it would change during execution when the same code (in a function or in a loop body) is executed again.
A CPU with dynamic instruction scheduling a.k.a. with out-of-order execution, will change the instruction schedule depending on the predicted branches, with much better chances of keeping busy the execution units.
In HPC applications, where Itanium worked best, it is possible to predict the branches at compile-time quite well, so a compiler has a chance to find an acceptable instruction schedule, unlike in more general-purpose applications, which are hard to predict.
A VLIW CPU also has speculative execution and a branch predictor, because these are needed in any pipelined CPU.
But unlike in an OoOE CPU, the speculative execution handles only complete bundles of instructions that are executed in a given clock cycle. A bundle of instructions may be executed speculatively or not, but the CPU cannot extract speculatively individual instructions from a set of bundles and combine them into a bundle that would occupy all execution units, like in an OoOE CPU.
For such a long time it became “faster and more cores, don’t be different” and just didn’t seem as interesting.
Apple Silicon had been very interesting to me. I’m really hoping to see a stronger ARM push on Windows, both because I know it can be great and because it’s just interesting. Windows has never had to switch architectures (for consumers) or support two at once for any reasonable population.
Also, whatever happened to mill? We used to get posts about them all the time.
And I wonder what would have happened to Power if they had the 3rd party fabs that exist today instead of being stuck with what IBM could make in-house.
Imagine how much money they could make if that pesky AMD went away.
And back then VIA was still noticeable competitor!
What?
I think maybe you are confusing Itanium with something else?
Development on itanium stopped in 2013:
> On 31 January 2013 Intel issued an update to their plans for Kittson: it would have the same LGA1248 socket and 32 nm process as Poulson, thus effectively halting any further development of Itanium processors.[1]
It's true that it shipped until 2021, but I think you had to already have previous orders to get that.