A historical note: Windows XP 64-bit Edition that was mentioned in the article, was Itanium-specific. It was based on XP kernel while Windows XP x64 Edition (for AMD64 architecture) was based on Windows Server 2003 kernel. Because of that, Windows XP x64 Edition had some significantly different performance characteristics compared to other Windows XP editions. If anything, it was closer to Vista than XP in some aspects.
In approx. 2000 to 2002, 2003 or around then, there was a theoretical dream that Itanium based workstations would become a real mass market thing, but it obviously never caught on.
Intel never made Itanium CPUs cheap enough to realistically purchase and Itanium motherboards never became a thing from the top-10 sized Taiwanese motherboard makers (the same companies that were making really nice boards for the 1 GHz to 1.2 GHz socketed Pentium 3 with 512KB cache and the first generations of Pentium 4).
Also the performance sucked. This was before AMD64 existed on the corporate desktop or home desktop.
It wasn't really Itanium that killed RISC-based unix-like competitors, but just generally price. People realized you could do a shit-ton of clever things on a x86 platform, Pentium 3 class server on a $2500 1U or 2U rackmount machine. This is in the single core cpu era.
Running FreeBSD or OpenBSD or Linux and you didn't need to spend $14,000 on a SGI or Sun or HP or IBM AIX machine or similar. People didn't buy Itanium for the same reasons they didn't buy $14,000 Suns, except weird low volume enterprise customers. The death of the old-unix-like RISC machines in the market was due to broadly everything in the early i686-class Xeons, Pentium 2/3, early Opterons, etc.
Edit: this is my direct personal experience, but FreeBSD or Linux in 2002 was already far ahead of a legacy unix in terms of usability and ability to customize things. The legacy vendors were stuck in a model of software that literally came in a physical box on a CD-ROM and was rarely updated. And you had to pay out the ass for it. I remember having a FreeBSD system with KDE 2.x desktop in 2002 and it was far more usable than anything Sun or SGI.
Paper-Itanium is unfairly blamed / credited with that, but it's not exactly true. The vertically integrated RISC/UNIX minicomputer companies were not on economically viable trajectories. x86 systems were undercutting their high margin workstation and server business, subsidized by enormous volumes in PC market needed to sustain increasing silicon manufacturing and design costs of new generations. The RISCs were forced to keep retreating to higher margin, lower volume, more specialized, higher performance markets which was really their only option by that point but it was also exactly the wrong direction to go in for long-term viability in the face of these prevailing trends.
Intel had their foundries and CPU cores paid for by video gamers and receptionists and students typing up their assignments and people looking at porn at 14.4kbps. Servers and workstations were pretty much gravy and every year there was less their systems couldn't do compared to the big iron.
Those computers pretty much sold themselves, contrast with every $20k workstation or $100k server that the unix guys had to explain why they were worth 5x the grey box on the desk.
SGI was struggling to make their MIPS chips and were pretty quickly finished off when nvidia started making GPUs. Itanium originated at HP as a PA-RISC replacement. They owned DEC Alpha when they killed it but arguably DEC didn't have a big base of legacy software at that point. IBM and Sun stood for a lot longer, mainly I would say largely due to locked in customers/data on Oracle and DB2 databases and proprietary software, rather than the merits of their hardware.
If Itanium never happened, 64-bit x86 server chips would have done the same thing to MIPS, Alpha, PA-RISC, SPARC, PowerPC. Might have happened even sooner from Intel since they allegedly sandbagged efforts in that direction to protect Itanium.
Alpha cancellation happened before HP/Compaq merger, when it was purely Compaq decision.
At the time some partnerships were slowly reducing the base costs of making Alpha machines (with K7 Athlon motherboards and EV6 Alpha being essentially signal compatible but not pinout compatible - you could reuse the chips and most of the design).
Compaq however... was not interested, for various reasons.
In any case the economics were more or less the same as Alpha as for the others. They couldn't support integrated silicon manufacturing. It wasn't even just the manufacturing (which could be outsourced although arguably not as competitively as integrated shops like Intel until TSMC really hit its stride). Or the logic and physical design. But the software development and ecosystem support costs were ballooning too. Alpha like the rest of them just never made sense unless they could make competitive cheap systems that were compatible, and by the time efforts like Windows ports and x86 emulation came along, it was already too late.
I think you're right overall that Itanium is used too often as the reason why all the RISC platforms died/were cancelled, as if they would have had healthy futures had Itanium simply not existed, but I do wonder about Alpha.
I wasn't around at the time, so I don't know what availability and pricing actually looked like, but unlike the other RISC platforms, Alpha was actually available on PC-like systems, with PCI and ISA busses, and x86 emulation at the firmware layer, allowing regular PC peripherals like VGA cards to work. Windows and, significantly, Linux, had pretty superb support for Alpha.
It's not enough to suggest that it had a chance "in any reality", but it seems like a much more potent competitor than PowerPC or SPARC or MIPS, it only because of the platform and OS support. Both Windows and Linux had pretty capable x86 emulation software layers too, and not just at the very end!
> I think you're right overall that Itanium is used too often as the reason why all the RISC platforms died/were cancelled, as if they would have had healthy futures had Itanium simply not existed, but I do wonder about Alpha.
Alpha had no fundamental differences that would have enabled it to avoid the same problem as the others IMO.
> I wasn't around at the time, so I don't know what availability and pricing actually looked like, but unlike the other RISC platforms,
No that's not true, other RISCs had similar, even before Alpha was on the designboard. They all did RISC workstations, Sun, SGI, even HP and IBM. IBM most famously went into PowerPC with Apple and Motorola early on, and then also did CPUs for several games consoles.
IBM probably of all of them understood the commoditization fight and they tried to put up a fight, but even they couldn't keep ahead of it. Alpha couldn't have.
> Alpha was actually available on PC-like systems, with PCI and ISA busses, and x86 emulation at the firmware layer, allowing regular PC peripherals like VGA cards to work. Windows and, significantly, Linux, had pretty superb support for Alpha.
Just too expensive to produce for what it did. Why would you use it for a Windows or Linux machine if you could do the same with a Pentium or K6 that actually ran your games and word processors and other stuff.
Windows on Alpha and FX!32 were reasonably solid options, as was the general health of the Alpha ecosystem. The platform also was not overextended in dot-com boom as much as let's say Sun. Windows port was also pretty early, even if it was 32bit limited.
The big benefit for EV6 was that it had actual parts commonality with PC, and I do not mean few I/O chips like some of the others (SuperIO, network, etc.) but northbridge - anyone making a K7 motherboard could make an Alpha motherboard, and Samsung became first vendor selling both CPUs and complete systems with non-Compaq chips.
FX!32 was not good. DEC's own paper only provided results for "Byte Benchmark" (nbench) which is a few trivial compute kernels. Even that most favorable test they could find showed 500MHz 21164A performed about the same as a Pentium Pro 200, the core that would the next year be in consumer CPUs. It was also NT only, at the time not used for PCs. It's just not enough to be "as good" in a scenario like that where not only are you are massively disadvantaged by costs, but you have to break into existing markets.
EV7 and EV8 development did not go well either, costs and complexity was blowing out, EV7 slipped 18 months and planned 130nm shrink was not able to hit performance targets. EV8 was enormous and expensive totally unsuited to mass market commodity bottoms-up path of Intel, and exemplifies their retreat into high end niche rather than accept and embrace commoditization.
AMD licensed the EV6 bus, but of course there was no socket/pin compatibility between AMD and Alpha parts. So they still didn't have commodity motherboards, though that would only be one small part of the puzzle if they did have.
FX!32 was good compared to what was available elsewhere (including for Itanium IIRC). I am not saying it had to compete with fully with x86 on consumer desktops from beginning, but it would have been more stable position, especially with known upcoming work on 64bit-clean NT5.
EV7 I am interested in more details because I want to know if the slippage was part of the original development run, or the post-Itanium one when it was restarted by HP. EV8 was admittedly dead in the water but I would say not so much for technical reasons as much as for direction options available (vs. following the samsung partnership to bring more AlphaPC-like systems)
The motherboard difference was slight between K7 and EV6 parts from my understanding if there was a will to commit to large scale production (arguably EV67 could be probably made into pin-compatible packaging even). But admittedly small part.
> The vertically integrated RISC/UNIX minicomputer companies were not on economically viable trajectories.
Well, actually one survived, and is making a fruity company quite happy, which also survived the 16 and 8 bit vertically integrated home computer companies.
The successful merge of NeXT and Apple, meant PC OEMs now dream of margins of those days hence why building desktops has become a niche market, everything is vertically integrated across laptops, tablets and phones and smart devices.
That alternative timeline means Intel would actually bother creating 64-bit x86 server chips instead of Itanium, because on their roadmap they were never expecting AMD to come out with an alternative.
Yes NeXT/Apple survive, although they commodity m68k CPUs, not quite your traditional UNIX minicomputer. Those were IBM, Sun, HP, DEC, maybe SGI. Designed their own ISAs, CPUs, interconnect fabric, 3 of them did their own silicon manufacturing.
One does still survive though, that's IBM's POWER / AIX. Still actively developed, though there is the feeling of 'when' rather than 'if' for them too.
Apple (or NeXT) were never vertically integrated back then. In the last 6 years with Apple making their own CPUs for OSX you could call them a vertically integrated UNIX shop. Not minicomputer though, which is from my post you replied to. Apple was not a vertically integrated vendor that survived bottom-up attack, they attacked Intel from bottom up via mobile/smartphone cores in a similar way Intel did to the minicomputers.
> If Itanium never happened, 64-bit x86 server chips would have done the same thing to MIPS, Alpha, PA-RISC, SPARC, PowerPC.
If AMD had launched amd64 server chips those vendors onboard we might have had a different 64-bit x86 market. And those vendors would have had a chance to succeed or fail on their own merits instead of due to dead end chip.
AMD did launch amd64 server chips. The first ones were Opteron, first (and only until Nehalem) x86 with ODMC, glueless multiprocessor up to 8-way (though that was a bit flakey, 4-way was decent), and first dual core. It destroyed Intel's CPUs in many measure of performance for server workloads.
Before Intel's decade of humiliation with their 10nm fiasco and before Zen, AMD had a hell of a time getting ISVs and IHVs on board in the server space with producing them, certifying them, etc.,. Which wasn't entirely irrational, Intel was much more mature in a lot of ways in their hardware and software stacks, they were a big company, perceived as less risky, etc.
So it's not too surprising that those companies didn't jump to Opteron. Some did consider it, mind you. Though AMD went through doldrums of their own after Opteron (with Core2/Nehalem-ish era) where they shat the bed with their cores and were pretty handily beaten by Intel for quite a long while until Zen came along -- so that is possibly some vindication for the risk adverse by not going all in on Opteron.
Already at launch, and also during the next few years, until Intel fought back with Core 2 (but in servers the Core 2 descendants became better than Opterons only in 2009, with the Nehalem Xeons), Opteron was immensely better than the UltraSPARC CPUs used in the Sun servers. Only the Fujitsu SPARC CPUs were somewhat competitive, even if still significantly weaker. The Intel Pentium 4 Xeons were also worse, despite higher clock frequencies.
But as you say, the inertia in servers is huge, so Opteron gained market share very slowly, despite being by far the most performant server CPU that was available.
Where I worked at that time, we had big server farms with Sun or Fujitsu servers, which were disliked by design engineers like myself for their slowness. We had to make great efforts to convince the management to buy a few Opteron-based servers. Of course, after we got them they ran circles around the Sun or Fujitsu servers, a single dual-socket Opteron could be much faster than an 8-socket Sun server whose cost was many times greater.
At a previous job circa 2008-12, we were a sun shop and moved from spark to x86 Solaris. It screamed at sustained, high-concurrency loads and our workloads benefited from the trinity of Solaris' threading, ZFS tiered storage, and zones/containers. By the time the Intel Nehalem chips became available to use, our DB loads screamed, too. There were edge cases where the sparc chips were better, but not at the price points offered. Linux was competitive at a performance level (though we always saw some issues if the machines were pegged for sustained amounts of time), but production containerization in those days was VMWare, which was enough of a performance hit to not be worth it.
Yep, those vendors could conceivably been onboard and using launching on Opteron (if there was no Itanium and Intel was seen as the common enemy). They might have given AMD some help with the validation, RAS etc too.
Of course in the alternative history Intel might have done something else in place of IA64 that competed with amd64...
> Itanium motherboards never became a thing from the top-10 sized Taiwanese motherboard makers
Supermicro and pretty sure Tyan offered Itanium motherboards.
From what I remember the Itanium was always harped on as too complex and too power hungry for mainstream while offering abysmal x86 emulation which soured its adoption. It had a niche in certain industries like HPC and high reliability. AMD's x64 architecture launched only 2 years after Itanium launched and pretty much destroyed any future for Itanium.
I vividly remember the months after AMD64 came out when tech companies were dumping their specialty RISC server hardware (mostly Sun, but some other stuff too) and replacing them with commodity AMD boxes. It was felt like a monumental shift.
Yeah, that was real soon now in the mid-90s – I remember reading Byte in high school and they’d be talking about how Alpha, MIPS, etc. workstations were doomed and then it kept getting pushed back – maybe 98/99, early in the next century, … and then AMD launched x86-64 and everyone just stopped pretending Itanium was ever going to happen.
Between 2000 and 2003, I used Windows Server as desktop at work, after a short period of dual booting between Windows 2000 and Red-Hat Linux, which I stop doing when routinely rebooting into Windows for support started being a frequent habit.
Thus I fully switched to Windows Server to be able to check the same issues as the customers had, and since we only supported big iron UNIX during those years, I would anyway use telnet / X Windows to connect to those machines.
It's pretty simple. There was a point in the early 2000s (especially pre-AMD x64) when it was pretty broadly assumed that Itanium from Intel was going to inevitably win given that a 64-bit transition was inevitable (correct) and that it would happen on Intel's terms (incorrect).
I ran Windows XP x64 Edition on a computer for a while and some software didn't like it. Since it was technically NT 5.2 (Server 2003) and not NT 5.1 (XP), some programs/installers would complain that it wasn't compatible. So, it was cool to have a 64-bit Windows XP, it was annoying to get stuff to run on it.
Watching my mate explain to his father for the 100th time that the game wont run on his 64 bit Itanium workstation despite it running windows did eventually get old.
I wonder if people are able to get Windows Server 2008 R2 to run on this yet as well. That was the last Windows OS to support Itanium, and it received updates until January 14, 2020.
I think HP had a big investment in Itanium and even sued Oracle to get them to keep supporting Itanium (they had contractually agreed to it, but Itanium was such a dead end...)
They had bet 100% on it killing PA-RISC and DEC Alpha. They ported HP-UX, OpenVMS and NonStop to it. All 3 of them were tangled up in long running enterprise and government contracts.
They since discontinued HP-UX, offloaded OpenVMS and ported NonStop to x86-64.
Itanium was essentially (incompatible) PA-RISC 3 - it originated as HP project and the direction to totally replace HPPA with Itanium was there from the start.
Non-Stop got ported early on because they needed some hardware and clients were locked down.
OpenVMS customers however balked about shifting to Itanium given that it was often slower than their existing Alpha boxes, leading to HP being forced to finish EV7 work and release another generation of Alpha chips (funnily enough, EV7 might have forked and lived on in Opteron/K8...)
They did, IIRC back in the late 00s they were also paying IBM to port software to HP-UX on Itanium, because I remember I was given a machine to play with and was asked to produce builds of some components.
From what I remember the only drama was that there was a missing pthread_ API implementation on the platform, might have been pthread_gettime or something.
Compared to the HP-UX on PA-RISC box I had access to at the time, the performance was amazing!
I'm rather surprised that they did end. After all, Itanium is one of few architectures (also the Russian Ebrus comes to mind) which doesn't exhibit the SPECTRE vulnerability.
I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore
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
So I feel like I need to write a blog post about this, but succinctly I think there's a good argument to be made that the issue wasn't the compiler despite popular wisdom. I don't even think it was the nature of unpredictable memory access times either as the itanium has a ton of special architectural hardware to handle unpredictable memory accesses (a lot of which are essentially some of the primitives that an OoO core uses for internal bookkeeping, just exposed architecturally).
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.
It was also planned for a world where high-end CPUs were differentiated by their ability to run floating-point-heavy workloads with relatively predictable memory access patterns.
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.
I worked for a company that had a fairly large OpenVMS installation and had to make the transition from Alpha to Itanium. It required a considerable amount of work and the early iterations of Itanium did not provide a clear performance improvement over the final Alpha EV7z that we had been using in some GS1280s.
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.
I think I read at one point alpha had a 64bit cpu in the 90s that could have hit 1ghz but some bug held it back. I am having so much trouble finding these articles and stories about processors these days with AI and shitified Google.
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.
I think the "Jim Keller" story around Zen is a bet on modularity, core-complexes, then chiplets. Smaller, less monolithic designs and a clean re-design of the x86 cores for compacity, ease of validation and scalability (in core count).
I recall opening up the Itanium manual, and by the end of the architecture description, just despairing of the thought of trying to write a compiler for it. Itanium, I think, was ultimately a victim of its weirdness: it's too weird to really comfortably write assembly by hand; the compilers weren't really capable with its weirdness, so "regular" code was worse off than you'd normally expect. Raymond Chen has pointed out in several articles how the hardware took advantage of C's UB to do some really weird things--and this is an era where most developers expected UB to really be just implementation-defined behavior.
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.
I wonder if most people kept them around just so they don't have to port their apps or migrate to something new.
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
There was also a long piece by a former Intel chip designer who was incredulous about how much the Itanium team was promising numbers based on a very few hand-scheduled routines for FPU-limited code. I think there’s a solid argument that the design just wasn’t based on a correct understanding of what most CPUs did and over-indexed on the most performance-sensitive HPC code. I once helped run some HPC code on a test Itanium system and even there it was just so easy to fall out of the only patterns which performed well and end up slower than older Pentiums even before factoring price into the evaluation.
> 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".
> 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.
It's doubly funny knowing that basically nobody bothers doing these kinds of workloads on CPU if they can help it. And everything you have to do to get GPU floating point performance also makes GPUs really, really bad for normal CPU code. Hell, at one point AMD actually was shipping VLIW for shader code...
> It's doubly funny knowing that basically nobody bothers doing these kinds of workloads on CPU if they can help it.
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.
Yes, but even farther back. Apparently the Pentium Pro team was forked off to work on Itanium in the mid 90s. At that point a GPU was at best just the rasterizer and ROP phases from an acceleration perspective.
I think that’s really illustrating how the problem isn’t what they expected: nobody was doing GPU computing in the 90s and when it became huge that was specialized for certain classes of work and involved custom toolchains. The fact that even AMD’s VLIW ended up diverging on later models makes me think Itanium was doomed even if it had shipped on time and budget.
People have tried all kinds of techniques for VLIW, including techniques that are much better than a purpose built AI, AI isn't a magic silver bullet. Fundamentally there's no reason you can't analyse a piece of code to death, and maximally extract parallelism out of it
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
From memory, Glasgow University CS had serious buy in to VLIW models of computation for a while, predating Itanium. There was good reason for believing it might have some interesting behaviours. I think they worked on languages targetting it, data models, things like reversible computation, long lived processes.
The so-called "SIMT programming model" is a term from the obfuscated jargon that NVIDIA has introduced for CUDA, where they have renamed almost all traditional terms used for decades in the computing literature.
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.
It was neat to live through the era where CPUs constantly got faster and they were willing to try such oddball stuff.
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.
Even if the magical Itanium compiler did exist, Itanium would have still lost to AMD64. As soon as you introduce anything that doesn't behave in a statically predictable manner (multitasking, or virtualization, or even an application that processes unpredictable input like a web backend or database), your performance drops down to a fraction of what a similarly priced AMD64 chip could do. VLIW is great for some very specific workloads like HPC, but Intel should have never tried to replace x86 with it.
> Ironically, it died around the time LLMs/AI started becoming good.
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.
Yeah, in an alternative timeline AMD would not had the opportunity to come up with AMD64, and we had to suck up Itanium no matter what, and maybe they would be improved.
A historical note: Windows XP 64-bit Edition that was mentioned in the article, was Itanium-specific. It was based on XP kernel while Windows XP x64 Edition (for AMD64 architecture) was based on Windows Server 2003 kernel. Because of that, Windows XP x64 Edition had some significantly different performance characteristics compared to other Windows XP editions. If anything, it was closer to Vista than XP in some aspects.
I would love to read the Microsoft PM spec for this product. Who in the world were they making it for?
Itanium never made it into the consumer-class hardware that was XP’s audience. AFAIK, Intel never even published a roadmap for that to happen!
Maybe a proof of concept they shipped as a demonstration of loyalty to Intel?!
In approx. 2000 to 2002, 2003 or around then, there was a theoretical dream that Itanium based workstations would become a real mass market thing, but it obviously never caught on.
Intel never made Itanium CPUs cheap enough to realistically purchase and Itanium motherboards never became a thing from the top-10 sized Taiwanese motherboard makers (the same companies that were making really nice boards for the 1 GHz to 1.2 GHz socketed Pentium 3 with 512KB cache and the first generations of Pentium 4).
Also the performance sucked. This was before AMD64 existed on the corporate desktop or home desktop.
It totally worked! Took out like four decent risc competitors with just a little FOMO
It wasn't really Itanium that killed RISC-based unix-like competitors, but just generally price. People realized you could do a shit-ton of clever things on a x86 platform, Pentium 3 class server on a $2500 1U or 2U rackmount machine. This is in the single core cpu era.
Running FreeBSD or OpenBSD or Linux and you didn't need to spend $14,000 on a SGI or Sun or HP or IBM AIX machine or similar. People didn't buy Itanium for the same reasons they didn't buy $14,000 Suns, except weird low volume enterprise customers. The death of the old-unix-like RISC machines in the market was due to broadly everything in the early i686-class Xeons, Pentium 2/3, early Opterons, etc.
Edit: this is my direct personal experience, but FreeBSD or Linux in 2002 was already far ahead of a legacy unix in terms of usability and ability to customize things. The legacy vendors were stuck in a model of software that literally came in a physical box on a CD-ROM and was rarely updated. And you had to pay out the ass for it. I remember having a FreeBSD system with KDE 2.x desktop in 2002 and it was far more usable than anything Sun or SGI.
Paper-Itanium is unfairly blamed / credited with that, but it's not exactly true. The vertically integrated RISC/UNIX minicomputer companies were not on economically viable trajectories. x86 systems were undercutting their high margin workstation and server business, subsidized by enormous volumes in PC market needed to sustain increasing silicon manufacturing and design costs of new generations. The RISCs were forced to keep retreating to higher margin, lower volume, more specialized, higher performance markets which was really their only option by that point but it was also exactly the wrong direction to go in for long-term viability in the face of these prevailing trends.
Intel had their foundries and CPU cores paid for by video gamers and receptionists and students typing up their assignments and people looking at porn at 14.4kbps. Servers and workstations were pretty much gravy and every year there was less their systems couldn't do compared to the big iron.
Those computers pretty much sold themselves, contrast with every $20k workstation or $100k server that the unix guys had to explain why they were worth 5x the grey box on the desk.
SGI was struggling to make their MIPS chips and were pretty quickly finished off when nvidia started making GPUs. Itanium originated at HP as a PA-RISC replacement. They owned DEC Alpha when they killed it but arguably DEC didn't have a big base of legacy software at that point. IBM and Sun stood for a lot longer, mainly I would say largely due to locked in customers/data on Oracle and DB2 databases and proprietary software, rather than the merits of their hardware.
If Itanium never happened, 64-bit x86 server chips would have done the same thing to MIPS, Alpha, PA-RISC, SPARC, PowerPC. Might have happened even sooner from Intel since they allegedly sandbagged efforts in that direction to protect Itanium.
Alpha cancellation happened before HP/Compaq merger, when it was purely Compaq decision.
At the time some partnerships were slowly reducing the base costs of making Alpha machines (with K7 Athlon motherboards and EV6 Alpha being essentially signal compatible but not pinout compatible - you could reuse the chips and most of the design).
Compaq however... was not interested, for various reasons.
Oh you must be right, I mix up my time lines.
In any case the economics were more or less the same as Alpha as for the others. They couldn't support integrated silicon manufacturing. It wasn't even just the manufacturing (which could be outsourced although arguably not as competitively as integrated shops like Intel until TSMC really hit its stride). Or the logic and physical design. But the software development and ecosystem support costs were ballooning too. Alpha like the rest of them just never made sense unless they could make competitive cheap systems that were compatible, and by the time efforts like Windows ports and x86 emulation came along, it was already too late.
I think you're right overall that Itanium is used too often as the reason why all the RISC platforms died/were cancelled, as if they would have had healthy futures had Itanium simply not existed, but I do wonder about Alpha.
I wasn't around at the time, so I don't know what availability and pricing actually looked like, but unlike the other RISC platforms, Alpha was actually available on PC-like systems, with PCI and ISA busses, and x86 emulation at the firmware layer, allowing regular PC peripherals like VGA cards to work. Windows and, significantly, Linux, had pretty superb support for Alpha.
It's not enough to suggest that it had a chance "in any reality", but it seems like a much more potent competitor than PowerPC or SPARC or MIPS, it only because of the platform and OS support. Both Windows and Linux had pretty capable x86 emulation software layers too, and not just at the very end!
> I think you're right overall that Itanium is used too often as the reason why all the RISC platforms died/were cancelled, as if they would have had healthy futures had Itanium simply not existed, but I do wonder about Alpha.
Alpha had no fundamental differences that would have enabled it to avoid the same problem as the others IMO.
> I wasn't around at the time, so I don't know what availability and pricing actually looked like, but unlike the other RISC platforms,
No that's not true, other RISCs had similar, even before Alpha was on the designboard. They all did RISC workstations, Sun, SGI, even HP and IBM. IBM most famously went into PowerPC with Apple and Motorola early on, and then also did CPUs for several games consoles.
IBM probably of all of them understood the commoditization fight and they tried to put up a fight, but even they couldn't keep ahead of it. Alpha couldn't have.
> Alpha was actually available on PC-like systems, with PCI and ISA busses, and x86 emulation at the firmware layer, allowing regular PC peripherals like VGA cards to work. Windows and, significantly, Linux, had pretty superb support for Alpha.
Just too expensive to produce for what it did. Why would you use it for a Windows or Linux machine if you could do the same with a Pentium or K6 that actually ran your games and word processors and other stuff.
Windows on Alpha and FX!32 were reasonably solid options, as was the general health of the Alpha ecosystem. The platform also was not overextended in dot-com boom as much as let's say Sun. Windows port was also pretty early, even if it was 32bit limited.
The big benefit for EV6 was that it had actual parts commonality with PC, and I do not mean few I/O chips like some of the others (SuperIO, network, etc.) but northbridge - anyone making a K7 motherboard could make an Alpha motherboard, and Samsung became first vendor selling both CPUs and complete systems with non-Compaq chips.
FX!32 was not good. DEC's own paper only provided results for "Byte Benchmark" (nbench) which is a few trivial compute kernels. Even that most favorable test they could find showed 500MHz 21164A performed about the same as a Pentium Pro 200, the core that would the next year be in consumer CPUs. It was also NT only, at the time not used for PCs. It's just not enough to be "as good" in a scenario like that where not only are you are massively disadvantaged by costs, but you have to break into existing markets.
EV7 and EV8 development did not go well either, costs and complexity was blowing out, EV7 slipped 18 months and planned 130nm shrink was not able to hit performance targets. EV8 was enormous and expensive totally unsuited to mass market commodity bottoms-up path of Intel, and exemplifies their retreat into high end niche rather than accept and embrace commoditization.
AMD licensed the EV6 bus, but of course there was no socket/pin compatibility between AMD and Alpha parts. So they still didn't have commodity motherboards, though that would only be one small part of the puzzle if they did have.
FX!32 was good compared to what was available elsewhere (including for Itanium IIRC). I am not saying it had to compete with fully with x86 on consumer desktops from beginning, but it would have been more stable position, especially with known upcoming work on 64bit-clean NT5.
EV7 I am interested in more details because I want to know if the slippage was part of the original development run, or the post-Itanium one when it was restarted by HP. EV8 was admittedly dead in the water but I would say not so much for technical reasons as much as for direction options available (vs. following the samsung partnership to bring more AlphaPC-like systems)
The motherboard difference was slight between K7 and EV6 parts from my understanding if there was a will to commit to large scale production (arguably EV67 could be probably made into pin-compatible packaging even). But admittedly small part.
> The vertically integrated RISC/UNIX minicomputer companies were not on economically viable trajectories.
Well, actually one survived, and is making a fruity company quite happy, which also survived the 16 and 8 bit vertically integrated home computer companies.
The successful merge of NeXT and Apple, meant PC OEMs now dream of margins of those days hence why building desktops has become a niche market, everything is vertically integrated across laptops, tablets and phones and smart devices.
That alternative timeline means Intel would actually bother creating 64-bit x86 server chips instead of Itanium, because on their roadmap they were never expecting AMD to come out with an alternative.
Yes NeXT/Apple survive, although they commodity m68k CPUs, not quite your traditional UNIX minicomputer. Those were IBM, Sun, HP, DEC, maybe SGI. Designed their own ISAs, CPUs, interconnect fabric, 3 of them did their own silicon manufacturing.
One does still survive though, that's IBM's POWER / AIX. Still actively developed, though there is the feeling of 'when' rather than 'if' for them too.
I did not count AIX / Solaris in, because they are always some racks in a server room, or the whole IBM / Unisys / Fujitsu for that matter.
I was only thinking about UNIX workstations, those under/besides the desk.
Otherwise you're right, there are few more options available still.
Not true, they all did workstations.
https://en.wikipedia.org/wiki/SPARCstation
https://en.wikipedia.org/wiki/IBM_RS/6000
https://www.reddit.com/r/vintagecomputing/comments/1fz29tx/r...
https://en.wikipedia.org/wiki/SGI_IRIS#MIPS
https://www.openpa.net/systems/hp-9000_720_730_750.html
Apple (or NeXT) were never vertically integrated back then. In the last 6 years with Apple making their own CPUs for OSX you could call them a vertically integrated UNIX shop. Not minicomputer though, which is from my post you replied to. Apple was not a vertically integrated vendor that survived bottom-up attack, they attacked Intel from bottom up via mobile/smartphone cores in a similar way Intel did to the minicomputers.
> If Itanium never happened, 64-bit x86 server chips would have done the same thing to MIPS, Alpha, PA-RISC, SPARC, PowerPC.
If AMD had launched amd64 server chips those vendors onboard we might have had a different 64-bit x86 market. And those vendors would have had a chance to succeed or fail on their own merits instead of due to dead end chip.
AMD did launch amd64 server chips. The first ones were Opteron, first (and only until Nehalem) x86 with ODMC, glueless multiprocessor up to 8-way (though that was a bit flakey, 4-way was decent), and first dual core. It destroyed Intel's CPUs in many measure of performance for server workloads.
Before Intel's decade of humiliation with their 10nm fiasco and before Zen, AMD had a hell of a time getting ISVs and IHVs on board in the server space with producing them, certifying them, etc.,. Which wasn't entirely irrational, Intel was much more mature in a lot of ways in their hardware and software stacks, they were a big company, perceived as less risky, etc.
So it's not too surprising that those companies didn't jump to Opteron. Some did consider it, mind you. Though AMD went through doldrums of their own after Opteron (with Core2/Nehalem-ish era) where they shat the bed with their cores and were pretty handily beaten by Intel for quite a long while until Zen came along -- so that is possibly some vindication for the risk adverse by not going all in on Opteron.
Already at launch, and also during the next few years, until Intel fought back with Core 2 (but in servers the Core 2 descendants became better than Opterons only in 2009, with the Nehalem Xeons), Opteron was immensely better than the UltraSPARC CPUs used in the Sun servers. Only the Fujitsu SPARC CPUs were somewhat competitive, even if still significantly weaker. The Intel Pentium 4 Xeons were also worse, despite higher clock frequencies.
But as you say, the inertia in servers is huge, so Opteron gained market share very slowly, despite being by far the most performant server CPU that was available.
Where I worked at that time, we had big server farms with Sun or Fujitsu servers, which were disliked by design engineers like myself for their slowness. We had to make great efforts to convince the management to buy a few Opteron-based servers. Of course, after we got them they ran circles around the Sun or Fujitsu servers, a single dual-socket Opteron could be much faster than an 8-socket Sun server whose cost was many times greater.
At a previous job circa 2008-12, we were a sun shop and moved from spark to x86 Solaris. It screamed at sustained, high-concurrency loads and our workloads benefited from the trinity of Solaris' threading, ZFS tiered storage, and zones/containers. By the time the Intel Nehalem chips became available to use, our DB loads screamed, too. There were edge cases where the sparc chips were better, but not at the price points offered. Linux was competitive at a performance level (though we always saw some issues if the machines were pegged for sustained amounts of time), but production containerization in those days was VMWare, which was enough of a performance hit to not be worth it.
Yep, those vendors could conceivably been onboard and using launching on Opteron (if there was no Itanium and Intel was seen as the common enemy). They might have given AMD some help with the validation, RAS etc too.
Of course in the alternative history Intel might have done something else in place of IA64 that competed with amd64...
> Itanium motherboards never became a thing from the top-10 sized Taiwanese motherboard makers
Supermicro and pretty sure Tyan offered Itanium motherboards.
From what I remember the Itanium was always harped on as too complex and too power hungry for mainstream while offering abysmal x86 emulation which soured its adoption. It had a niche in certain industries like HPC and high reliability. AMD's x64 architecture launched only 2 years after Itanium launched and pretty much destroyed any future for Itanium.
Had AMD not come out with AMD64, and Itanium would eventually prevail, as there was no other alternative coming from Intel.
I vividly remember the months after AMD64 came out when tech companies were dumping their specialty RISC server hardware (mostly Sun, but some other stuff too) and replacing them with commodity AMD boxes. It was felt like a monumental shift.
It wouldn't, performance was horrible.
Yes it would, when the only way is to press forward, eventually something has to improve.
Yeah, that was real soon now in the mid-90s – I remember reading Byte in high school and they’d be talking about how Alpha, MIPS, etc. workstations were doomed and then it kept getting pushed back – maybe 98/99, early in the next century, … and then AMD launched x86-64 and everyone just stopped pretending Itanium was ever going to happen.
There were Itanium workstations (https://www.openpa.net/systems/hp_i2000.html, https://www.openpa.net/systems/hp_zx2000.html), but of course these quickly crashed and burned with the rest of Itanium
Yeah, I had forgotten that by the Windows XP/Server 2003 era, the latter was definitely a server product, with XP targeting the workstation world.
That still seems weird to me. If I had to rely on a PC for high-end work in that period, I wanted the server SKU.
Between 2000 and 2003, I used Windows Server as desktop at work, after a short period of dual booting between Windows 2000 and Red-Hat Linux, which I stop doing when routinely rebooting into Windows for support started being a frequent habit.
Thus I fully switched to Windows Server to be able to check the same issues as the customers had, and since we only supported big iron UNIX during those years, I would anyway use telnet / X Windows to connect to those machines.
It's pretty simple. There was a point in the early 2000s (especially pre-AMD x64) when it was pretty broadly assumed that Itanium from Intel was going to inevitably win given that a 64-bit transition was inevitable (correct) and that it would happen on Intel's terms (incorrect).
I believe efforts like this were funded by HP. It is why the Itanium was kept around for so long despite being dead on arrival.
I ran Windows XP x64 Edition on a computer for a while and some software didn't like it. Since it was technically NT 5.2 (Server 2003) and not NT 5.1 (XP), some programs/installers would complain that it wasn't compatible. So, it was cool to have a 64-bit Windows XP, it was annoying to get stuff to run on it.
Watching my mate explain to his father for the 100th time that the game wont run on his 64 bit Itanium workstation despite it running windows did eventually get old.
I wonder if people are able to get Windows Server 2008 R2 to run on this yet as well. That was the last Windows OS to support Itanium, and it received updates until January 14, 2020.
EDIT: there was also an additional patch released in May 2020 according to https://en.wikipedia.org/wiki/Windows_Server_2008_R2#Itanium
Wild that shipments of Itaniums didn't end until 2021.
I think HP had a big investment in Itanium and even sued Oracle to get them to keep supporting Itanium (they had contractually agreed to it, but Itanium was such a dead end...)
They had bet 100% on it killing PA-RISC and DEC Alpha. They ported HP-UX, OpenVMS and NonStop to it. All 3 of them were tangled up in long running enterprise and government contracts.
They since discontinued HP-UX, offloaded OpenVMS and ported NonStop to x86-64.
Itanium was essentially (incompatible) PA-RISC 3 - it originated as HP project and the direction to totally replace HPPA with Itanium was there from the start.
Non-Stop got ported early on because they needed some hardware and clients were locked down.
OpenVMS customers however balked about shifting to Itanium given that it was often slower than their existing Alpha boxes, leading to HP being forced to finish EV7 work and release another generation of Alpha chips (funnily enough, EV7 might have forked and lived on in Opteron/K8...)
They did, IIRC back in the late 00s they were also paying IBM to port software to HP-UX on Itanium, because I remember I was given a machine to play with and was asked to produce builds of some components.
From what I remember the only drama was that there was a missing pthread_ API implementation on the platform, might have been pthread_gettime or something.
Compared to the HP-UX on PA-RISC box I had access to at the time, the performance was amazing!
I'm rather surprised that they did end. After all, Itanium is one of few architectures (also the Russian Ebrus comes to mind) which doesn't exhibit the SPECTRE vulnerability.
I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore
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
So I feel like I need to write a blog post about this, but succinctly I think there's a good argument to be made that the issue wasn't the compiler despite popular wisdom. I don't even think it was the nature of unpredictable memory access times either as the itanium has a ton of special architectural hardware to handle unpredictable memory accesses (a lot of which are essentially some of the primitives that an OoO core uses for internal bookkeeping, just exposed architecturally).
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.
It was also planned for a world where high-end CPUs were differentiated by their ability to run floating-point-heavy workloads with relatively predictable memory access patterns.
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.
I worked for a company that had a fairly large OpenVMS installation and had to make the transition from Alpha to Itanium. It required a considerable amount of work and the early iterations of Itanium did not provide a clear performance improvement over the final Alpha EV7z that we had been using in some GS1280s.
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.
EV7 were introduced after customers refused to upgrade to Integrity over crap performance.
If only the Alpha had hung on.
I have an AlphaServer in my collection (DS10.) For a 25+ year old system, it still feels pretty snappy!
I think I read at one point alpha had a 64bit cpu in the 90s that could have hit 1ghz but some bug held it back. I am having so much trouble finding these articles and stories about processors these days with AI and shitified Google.
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.
I think the "Jim Keller" story around Zen is a bet on modularity, core-complexes, then chiplets. Smaller, less monolithic designs and a clean re-design of the x86 cores for compacity, ease of validation and scalability (in core count).
My college was a DEC shop; I learned programming and how to use unix in labs full of dumb X terminals connected to Alpha servers.
Still have a lot of nostalgia for the architecture.
I recall opening up the Itanium manual, and by the end of the architecture description, just despairing of the thought of trying to write a compiler for it. Itanium, I think, was ultimately a victim of its weirdness: it's too weird to really comfortably write assembly by hand; the compilers weren't really capable with its weirdness, so "regular" code was worse off than you'd normally expect. Raymond Chen has pointed out in several articles how the hardware took advantage of C's UB to do some really weird things--and this is an era where most developers expected UB to really be just implementation-defined behavior.
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.
I wonder if most people kept them around just so they don't have to port their apps or migrate to something new.
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
There was also a long piece by a former Intel chip designer who was incredulous about how much the Itanium team was promising numbers based on a very few hand-scheduled routines for FPU-limited code. I think there’s a solid argument that the design just wasn’t based on a correct understanding of what most CPUs did and over-indexed on the most performance-sensitive HPC code. I once helped run some HPC code on a test Itanium system and even there it was just so easy to fall out of the only patterns which performed well and end up slower than older Pentiums even before factoring price into the evaluation.
> 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...
> http://courses.cs.washington.edu/courses/csep590/06au/projec...
This link requires a log-in.
It apparently works with https. Weird. Quite a journey to figure that out.
https://courses.cs.washington.edu/courses/csep590a/06au/proj...
Sorry about that and thanks @monocasa for correcting the link. I’ve had that bookmarked for a decade.
It's doubly funny knowing that basically nobody bothers doing these kinds of workloads on CPU if they can help it. And everything you have to do to get GPU floating point performance also makes GPUs really, really bad for normal CPU code. Hell, at one point AMD actually was shipping VLIW for shader code...
> It's doubly funny knowing that basically nobody bothers doing these kinds of workloads on CPU if they can help it.
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.
Yes, but even farther back. Apparently the Pentium Pro team was forked off to work on Itanium in the mid 90s. At that point a GPU was at best just the rasterizer and ROP phases from an acceleration perspective.
> At that point a GPU was at best just the rasterizer and ROP phases from an acceleration perspective.
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...
I think that’s really illustrating how the problem isn’t what they expected: nobody was doing GPU computing in the 90s and when it became huge that was specialized for certain classes of work and involved custom toolchains. The fact that even AMD’s VLIW ended up diverging on later models makes me think Itanium was doomed even if it had shipped on time and budget.
It's more simple. Online bin packing problem is simpler to solve and has more optimal solutions with smaller chunks
People have tried all kinds of techniques for VLIW, including techniques that are much better than a purpose built AI, AI isn't a magic silver bullet. Fundamentally there's no reason you can't analyse a piece of code to death, and maximally extract parallelism out of it
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
From memory, Glasgow University CS had serious buy in to VLIW models of computation for a while, predating Itanium. There was good reason for believing it might have some interesting behaviours. I think they worked on languages targetting it, data models, things like reversible computation, long lived processes.
The so-called "SIMT programming model" is a term from the obfuscated jargon that NVIDIA has introduced for CUDA, where they have renamed almost all traditional terms used for decades in the computing literature.
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.
I think it died before that, it was just that buried it then.
It was neat to live through the era where CPUs constantly got faster and they were willing to try such oddball stuff.
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.
Itanium was effectively dead once Intel adopted AMD's x86-64. It just remained a zombie for another 15+ years.
Even if the magical Itanium compiler did exist, Itanium would have still lost to AMD64. As soon as you introduce anything that doesn't behave in a statically predictable manner (multitasking, or virtualization, or even an application that processes unpredictable input like a web backend or database), your performance drops down to a fraction of what a similarly priced AMD64 chip could do. VLIW is great for some very specific workloads like HPC, but Intel should have never tried to replace x86 with it.
The lack of licensing to other companies was clearly a POWERFUL incentive.
Imagine how much money they could make if that pesky AMD went away.
IIRC it was major part of intel's roadmap to establish it so that "future" of PC cpus would be locked down to Intel/HP partnership.
And back then VIA was still noticeable competitor!
> Ironically, it died around the time LLMs/AI started becoming good.
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.
[1]https://en.wikipedia.org/wiki/Itanium
[dead]
Might need some background on this one.
Never heard of this one either. FCKGW on the other hand still triggers muscle memory.
I had FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8 memorized too but I used XGCJ6 more often. Mostly for Virtual PCs that I was converting to hyper-v guests.
> Might need some background on this one.
It's a VLK. During early XP days, Volume License Keys were widely accepted and when using them, XP would show as activated.
was there any advantage or special use case for running an itanium windows workstation instead of x86 back then?
More than 3GB of application memory space and more than 4GB overall (including the NT kernel).
At that time, this was starting to become a major issue at the high end of servers and workstations.
And then AMD64 came along and we immediately moved to 8GB servers, taking away the only real Itanium advantage.
Yeah, in an alternative timeline AMD would not had the opportunity to come up with AMD64, and we had to suck up Itanium no matter what, and maybe they would be improved.