The United States is like the guy at the party who gives cocaine to
everybody and still nobody likes him.
-- Jim Samuels
Intel spent billions of dollars trying to make Itanic a thing. They schemed with HP to buy and kill Alpha, in spite of the fact that at the time Alpha was in some of the fastest supercomputers in the world. They shot themselves in the foot by avoiding adopting amd64 extensions for so long in their x86 processors and doing other seemingly brain-dead things that only make sense when examined in the light of their desire to push Itanic.
They made deals all across the industry to get people to sign up to support Itanic, and in the end people got a very mediocre CPU that always promised more than it delivered and always cost significantly more for the same amount of performance elsewhere.
In the meanwhile, Alpha is still supported by gcc, has repositories of tens of thousands of current binary packages, and still has options for modern open source OSes. m68k has gcc and clang support. Heck - even VAX has ongoing gcc support.
You can barely give away an Itanic system these days. It truly is a very sad architecture.
OTOH, some people are still having fun with Itanic systems:
>Intel spent billions of dollars trying to make Itanic a thing. They schemed with HP to buy and kill Alpha, in spite of the fact that at the time Alpha was in some of the fastest supercomputers in the world. They shot themselves in the foot by avoiding adopting amd64 extensions for so long in their x86 processors and doing other seemingly brain-dead things that only make sense when examined in the light of their desire to push Itanic.
Intel has failed, or at least failed to distinguish itself, in *every single market* it has entered since IBM chose the 8088 forty years ago: Every non-x86 instructional set CPU, flash memory, antivirus (still perhaps the most mystifying move in Intel history), servers/motherboards, and GPUs come to mind. The most successful non-x86 business for Intel is ... Ethernet cards? Meanwhile, it's embarrassed itself with discrete GPUs at least three separate times. A few years ago buying Nvidia would have been a savvy move; now it can no longer do so, and it's not impossible to imagine Nvidia buying Intel in the future.
Even within the one market Intel does dominate, what saved the company 20 years ago amid Itanic and Pentium 4 was 1) AMD Thunderbird being just as inefficient as Pentium 4 and, more importantly, 2) an Intel Israel skunk works project to improve on the Pentium 3. There is no such out-of-the-blue miracle this time.
>Intel has failed, or at least failed to distinguish itself, in every single market it has entered since IBM chose the 8088 forty years ago:
This is just wrong, unless you mean by "distinguish itself" as "redefine the market" or something superlative like that.
Intel's big successes have been in chips that support their CPUs. Motherboard chipsets (northbridges), WiFi chips (basically the standard in many laptops), etc. Also, their GPUs have been very successful, but only for integrated graphics. Just look at countless corporate laptops over the last 10-15 years: all the parts inside are by Intel: CPU+iGPU, WiFi, USB, etc. Load up Linux on one, and then run "lspci". Corporate laptops have been dominated by Intel for ages.
Also, Intel has done well with a lot of enterprise-grade and server components, like Ethernet adapters.
Yeah, they did miss the high-end GPU market, but for most computers you really don't want a high-end GPU: they're expensive and power-hungry, and far more than you need for using Excel and Word and watching videos on YouTube. Laptops with discrete GPUs have horrible battery life; I'm unfortunately stuck with one of these beasts for my work, when I don't use its capabilities at all, and the battery doesn't last more than 1-2 hours despite the thing weighing a ton. (Someone high-up in the company thought that we "need" these things just because we're devs.)
Aside from wifi chips, you haven't mentioned anything that Intel does that the person to whom you're responding hasn't mentioned. Support chips go with CPUs, and integrated video is also part of their CPUs.
What "enterprise" gear have they done, besides ethernet controllers?
I think the point stands - aside from some not very significant cases, Intel has been a one trick pony for ages. They haven't even been doing their one trick very well - both AMD and Apple have handed Intel their ass in the last several years.
Think of how many times Intel caught themselves out - they've taken too many shortcuts to try to one up and we've suffered as a result. Skylake bugs? All the variants of Spectre and Meltdown? 14 nm for countless years? Netburst? Atom CPUs that brick themselves after a while and require literal, physical replacement?
Intel's current products focus on benchmarks and marketing more than on actual performance - they throw hundreds of watts at a CPU to get faster immediate performance, but their CPUs can't maintain that for long. Sure, it might win a bit at games, but I wouldn't want an Intel for compiling.
I'm not sure what you expect here: for Intel to dominate a bunch of very different silicon-based product lines? They already dominate(d) CPUs and chipsets and WiFi chips, what more do you want?
Let's compare to Facebook: what do they dominate? The Facebook social network service, and I suppose Instagram, plus some other "support" stuff like Messenger. How about Ebay? Are they some kind of failure because they're a "one trick pony" with their auction site? Is Comcast a failure because all they have is cable TV and cable internet? I guess Toyota is a failure too because all they make is motor vehicles. I find your criticism frankly bizarre.
1) I wouldn't say they dominate the wifi chip market. They're not particularly power efficient, but they're often part of the package that one gets when one gets Intel chipsets.
2) "Dominating" in CPU chipsets is... Well, it's a silly metric, because it's included in their CPU business. It's not like they're providing CPU chipsets for competing CPUs.
So yes, I'd expect one of the largest chipmakers on the planet to have SOME aptitude making products other than CPUs and their chipsets, wifi chips and ethernet chips.
How about storage controllers? They had Xscale until they sold it. How about flash? They've made some good SSDs, but never differentiated themselves in any of speed, quality or performance. GPUs? We know how that has gone - even though they have years of experience with integrated GPUs, they're shipping drivers that are embarrassingly bad. Low power, portable SOCs? The Atom has horrible performance/watt, so much so that MIPS and PowerPC are still used significantly more often than x86 in set top boxes, NAT routers, and so on. Their attempts to make a chipset for cable modems gave us the infamous Intel Puma chipset that has been plagued with problems for years and that Intel still hasn't fixed, after knowing about those problems and releasing a whole new generation.
I still stand by the one trick pony comparison, unless you can think of some business where Intel stands out.
I'd have to see a reference for that. Digital was still an independent company for several years after what would become IA-64 was publicly unveiled and HP didn't end up acquiring Digital by way of Compaq for a few years after that.
"As part of the roadmap to phase out Alpha-, MIPS- and PA-RISC-based systems in favor of Itanium-based systems at HP, the most recent AlphaServer systems reached their end of general availability on 27 April 2007."
"Seen by both executives at HP and Compaq as a redundant overlapping product under the new merged company and with Intel's IA-64 efforts underway, the Alpha -- arguably a much more mature, better supported and more desirable platform was phased out."
From Wikipedia:
"On June 25, 2001, Compaq announced that Alpha would be phased out by 2004 in favor of Intel's Itanium, canceled the planned EV8 chip, and sold all Alpha intellectual property to Intel.[6] Hewlett-Packard merged with Compaq in 2002; HP announced that development of the Alpha series would continue for a few more years, including the release of a 1.3 GHz EV7 variant named the EV7z. This would be the final iteration of Alpha, the 0.13 µm EV79 also being canceled."
All of this in spite of having a large number of supercomputers in the Top500 list, lots of actively developed scientific computing software optimized for Alpha, and features that other CPUs wouldn't have for years.
What that quote is about is that a then HP competitor (and a big Intel partner), Compaq decided that Itanium was the 64-bit future; a lot of companies were making at least contingency plans to support Itanium over in-house designs. But Intel didn't do Itanium with HP to specifically have an impact on Alpha.
> Intel spent billions of dollars trying to make Itanic a thing.
You're looking at that wrong.
Intel spent a gigabuck and scared everybody else out of the space. That's a brilliant business manuever even if the tech was a failure.
The only company left in the space afterward was IBM with POWER. Intel basically wiped out DEC(Alpha), SGI, MIPS, HP (PA-RISC), and Sun (Sparc) for a gigabuck.
The only part of Itanium that annoys me is that it's squatting on the IA-64 abbreviation.
IA-16 is 16-bit x86, retroactively. IA-32 is 32-bit x86. Easy-peasy. But IA-64 is this oddball architecture that has no relevance to anyone's life anymore and it breaks the pattern. It wasn't even Intel's design to begin with, it was HP's. Bah.
...but also says "including results for @jhamby ritanium" and has a link "search instead for @jhamby itanium". If you click that, then Top works. (Note my iOS Twitter app version is somewhat old, so I guess I can't guarantee that this specific sequence doesn't work for you.)
The timing is a bit unexpected, given that there was a similar discussion not too long ago, and I think someone stepped up as a quasi-maintainer (maybe even Adrian, who now acked the removal patch).
Itanium will be remember for quite a while because it gave us the Itanium C++ ABI: https://itanium-cxx-abi.github.io/cxx-abi/ It's actively maintained and continuously adjusted to new implementation requirements for newer C++ standards versions.
Despite the name, it's the C++ ABI that GNU/Linux (and most non-Windows targets) uses for other CPUs as well. I know that people don't like this kind of ABI stability (or C++), but it's what enables widespread C++ usage in distributions, without the need for flag days/mass rebuilds or tons of manually created compat packages. We might not have Qt or KDE without the Itanium C++ ABI.
> Itanium will be remember for quite a while because it gave us the Itanium C++ ABI
There are two other things Itanium gave us, which will also be remembered for a long time: EFI (rebranded as UEFI for its portable non-Itanium implementation), and GPT (the partition table format for disks bigger than 2TB).
Yeah, IA64 was really exciting, until the hardware came out... Even the 'workstation' class machines were ridiculously loud and took a dedicated circuit to power them. And the boot times, oh, the boot times.
Then, the instruction set turned out to be all kinds of meh, and the optimizing compilers supposed to compensate for that never turned up.
So, yeah, this was pretty much unavoidable. Even hardcore VAX holdouts (which HP eventually tried to capture, unsuccessfully) are on x64 by now...
I've never been able to figure out if IA64 was poorly designed, or if the migration path was just to hard. The AMD64 seemed like a bit of a hack when it came out, but at the same time it was just a better solution for most.
We had two Itanium servers for a project I worked on, both donated by HP. They weren't anything special, certainly didn't feel like an upgrade over our Sun machines.
IA64 is effectively a VLIW architecture, and... VLIW architectures just keep ending up not working out. There's a few things that make VLIW architectures hard to do well:
* You're basically encoding microarchitectural details (which operations each execution port can run, how many execution ports, etc.) into the ISA, which makes changing that microachitecture difficult. (See also branch delay slots, which have a similar issue).
* Several instructions have data-dependent execution time, and are very difficult to statically schedule. Dynamic scheduling can handle it much better. The common instruction classes are division, branches, and memory accesses, the latter two of which are among the most common instructions.
* Static scheduling is limited by the inability to schedule around barriers, such as function calls. Dynamic scheduling can overlap in these scenarios.
At the end of the day, the idea that you can rip out all of this fancy OoO-execution hardware and make it the compiler's problem just turns out worse than having the OoO hardware, with the smarter compiler having to manage the instruction stream to maximize the ability of the OoO hardware to get good performance.
> At the end of the day, the idea that you can rip out all of this fancy OoO-execution hardware and make it the compiler's problem just turns out worse than having the OoO hardware
With Itanium and then NetBurst, it seemed to me that Intel had really bad tunnel vision with the overall designs. It's like they got over focused one a couple use cases and then designed towards those architecturally.
As an example I remember the marketing for Itanium and then NetBurst really hammered on tasks like media encoding. The chips could tear through MPEG macroblocks! Wow! Of all workloads what percent are tearing through MPEG encoding or other highly ordered cache-friendly things? Most real world code is cache-hostile super branchy pointer chasing.
The philosophy of making the compiler do all the instruction scheduling serves the cache-friendly predictable data stream model. The only way it can serve the real world model of code is to explode memory requirements by having the compiler emit hundreds of variants of routines and use some sort of function multi-versioning to select one appropriate for the current data shape.
This is an unscientific observation on my part but it's how the situation seemed to me two decades ago. When Intel didn't have marketeers demanding "moar media encoding" they ended up with genuinely good chips like the Tualatin (which became the Core line).
I'm finishing up writing a (very short) book on lessons from Itanium and I don't think I really appreciated all the VLIW backstory at the time. While I sort of understand why HP got excited about EPIC, I don't really understand how they got Intel to go along ESPECIALLY given that Intel had its i860 experience and could have presumably just maintained their market position with 64-bit x86 easy peasy.
> You're basically encoding microarchitectural details (which operations each execution port can run, how many execution ports, etc.) into the ISA, which makes changing that microachitecture difficult. (See also branch delay slots, which have a similar issue).
The HP/Intel people who designed the Itanium did have an answer for this one: Stop bits, which allow the software to indicate which opcodes can run in parallel even across words such that processors with more parallelism could run instructions from multiple words in parallel. Itanium was designed around EPIC, or Explicitly Parallel Instruction Computing, which was designed as a next-generation VLIW that took into account lessons learned from previous VLIW designs:
> Each group of multiple software instructions is called a bundle. Each of the bundles has a stop bit indicating if this set of operations is depended upon by the subsequent bundle. With this capability, future implementations can be built to issue multiple bundles in parallel.
Also:
> Several instructions have data-dependent execution time, and are very difficult to statically schedule. Dynamic scheduling can handle it much better.
They tried to handle this with prefetching and speculative loads, but, you're right, they didn't handle it well enough.
> Static scheduling is limited by the inability to schedule around barriers, such as function calls. Dynamic scheduling can overlap in these scenarios.
Itanium had speculative execution and delayed exceptions to try to get around this. Again, though, not good enough.
Itanium was an interesting design, but it seems that VLIW plus modern superscalar techniques isn't as good as superscalar techniques alone.
Both. It lived off an assumption that the magic compiler generating perfect assembly ideally fitting architecture will come out, and so CPU can skip the whole "crap" related to assigning incoming instruction stream to CPU's execution units. Which just didn't worked in practice.
Current approach of CPU being basically an optimizing compiler that takes assembly in and generates uops to drive whatever execution units the CPU has might be wasteful silicon wise but... caches are much more transistors than this anyway and it allows CPU design to be separated from incoming assembly and so any improvements there are instantly visible to most existing code.
It failed for the price/performance comparison to x64. Even if it performed 2x what it did, that still wouldn't have overcome the low commodity pricing for x64.
Intel figured they had control over that by not releasing a 64-bit x86. AMD ruined that for Intel.
Even without AMD intel would’ve needed to release cheap server, desktop and mobile 64 bit CPUs at some point, with reasonable compatibility to x86 code. It may have happened only around 2010 without AMDs pressure. Itanium could’ve never done the job for consumer grade or smaller servers. Too expensive, too exotic, and no possibility to run x86 code fast.
>Even without AMD intel would’ve needed to release cheap server, desktop and mobile 64 bit CPUs at some point, with reasonable compatibility to x86 code.
I worked there at the time, and this was not the thinking in the company at all. The thinking was that if you needed 64-bit computing, you needed to buy an Itanium, full stop. Otherwise, 32 bits (with PAE) was all you needed. This is what Intel told all its customers. They really thought that IA64 was going to eventually replace x86 altogether.
Yes, at that time Intel had the belief IA64 could be the new architecture. But do you think that plan had a chance to work out? I think it would've become clear after a few years, that IA64 was not a suitable platform to replace the complete CPU lineup. For example to replace the mobile Centrino CPUs with IA64. I think it would've failed in a similar way like Apple failed to put their G5 PPC into a laptop (and switched to Intel then).
Or some pressure, because there is a strong business need to run new 64-bit code side-by-side with old x86 code (which is very slow on Itanium).
And 32 bit + PAE might have been fine in 2000, but by 2010 the de-facto limit for 4GB memory space per process would've become a huge issue.
I'm not addressing whether things would have worked in reality, I'm telling you what the corporate leadership was telling us at the time. You can claim all you want that it wasn't realistic or whatever, but this is the same corporate leadership that thought everyone would be perfectly happy to spend $$$$ on patented RAMBUS memory. Yes, they really did seem to think that IA64 was going to be everywhere eventually.
x86 code was slow on Itanic because it was just a bolt-on PentiumPro IIRC. It was only there for compatibility mode, and was never meant to be high performance. Code needing performance was going to be compiled for IA64 using the magic compiler that didn't exist yet.
When Intel announced that Itanium was going to be VLIW, the computer architects at DEC cheered. They knew full well from painful experience that VLIW was an absolute dead end.
Of course, that was before the DEC Hostile Giveaway.
Nah, it was just poorly designed. Intel promised two things for IA64: more instructions per clock and much higher clock rates. The first promise failed to materialize due to suitable compilers being much too difficult to implement, which in turn stopped investments in silicon improvements (which, in hindsight, would have been extremely challenging as well).
- the promised compilers are _impossible_ as we can't predict all branches and all cache misses in _general_ (works better for floating point heavy code),
- the failure to clock higher was IMO largely due to a ridiculously bloated and over-complicated ISA. In other words, EPIC was doomed from birth.
I've written about IA-64 many times; it actually had many neat ideas, but in the end Intel yet again failed spectacularly in moving away from their archaic legacy.
> the failure to clock higher was IMO largely due to a ridiculously bloated and over-complicated ISA.
Perhaps mostly due to having too many architected registers AND making most of them rotating/part of register windows... that means more work to do per instruction. Wide superscalar => you need lots and lots of forwarding paths between the ALUs. Combined with no out of order execution to allow for spreading that work out a bit (longer latencies per instruction but largely hidden by other work) and you get hard limits on the clock speed.
Part of the problem with the whole Itanic ecosystem is that Intel never spend much energy trying to improve gcc, instead improving and pushing their own compilers.
I guess the thinking when they got started was that this FOSS stuff was for smelly hippies and not serious use.
And once the world had converted to Itanium, having to buy Intel compilers to wring decent performance out of it, would have given Intel another big revenue stream.
In other news, the Intel compiler suite has been recently refactored on top of clang&llvm. How the world turns..
Those who want "excitement" in instruction sets should study GPUs, POWER10, ARMv8, AVX512, and ARM's SVE these days.
GPU instructions, such as bpermute, permute, warp-vote, and other such concepts are the biggest "conceptual" changes to compute I've ever seen. DirectX12, Vulkan, CUDA, HIP, it doesn't really matter what you study per se, the GPU community knows brute force performance and is advancing it.
From this perspective, your study guides are the NVidia PTX guide (CUDA's assembly language), and AMD's RDNA2 ISA. Also keep in mind the NVidia PTX wgmma instruction, which is key to 16-bit 4x4 matrix multiplications (aka: Deep Learning / Tensors).
NVidia's underlying assembly is undocumented (instead, hidden away by the PTX layer / compiler). But people have been figuring out how it works under the hood. I don't think NVidia is trying to keep it a secret, as much as they just prefer users to work at the PTX layer, which would be more portable in the long term. Studying this SASS assembly is harder but still possible: https://arxiv.org/abs/2208.11174
---------
x86-wise, the pext and pdep instructions are single-cycle gather/scatter bitwise operations over 64-bits. I consider these to be the greatest advancements to compute theory on the x86 side and highly suggest people to play with these instructions. They're incredible.
POWER and ARMv8 have extremely clean implementations of load-acquire / store-release, and I expect this to be fundamental to large-scale scaling of CPUs, cache-coherence, and even I/O in the long run.
-------
AVX512 and SVE are other ideas into SIMD compute. AVX512 has compress instructions that I think work extremely well for common SIMD code (ex: the stream compression problem).
SVE tries to be agnostic with SIMD-width. A noble effort, but its the odd one out (AVX512, NVidia CUDA, and AMD HIP all rely upon static SIMD-widths). I'm still interested in what it can do with its "SIMD-width agnostic" framework, but I also recognize that it stands alone in today's ISAs.
--------
The closest thing to Intel Itanium is probably Xilinx FPGAs, which I'm told are VLIW-based instructions still. The old Itanium went all in on VLIW, but its just not a popular ISA-style today, and is largely considered "defeated".
But VLIW apparently lives on in DSPs and Xilinx FPGAs. While no one seems to be investing in this concept, its still being studied (by at least DSP programmers) and could be a darkhorse comeback in 10 years or so.
Once something makes it to Linux, it's very hard to root out. As long as there's even just ONE dedicated developer keeping it alive, it'll remain there.
> The Trillian Project was an effort by an industry consortium to port the Linux kernel to the Itanium processor. The project started in May 1999 with the goal of releasing the distribution in time for the initial release of Itanium, then scheduled for early 2000.[183] By the end of 1999, the project included Caldera Systems, CERN, Cygnus Solutions, Hewlett-Packard, IBM, Intel, Red Hat, SGI, SuSE, TurboLinux and VA Linux Systems.[184] The project released the resulting code in February 2000.[183] The code then became part of the mainline Linux kernel more than a year before the release of the first Itanium processor.
... for values of "day one" which are prior to the release of the actual hardware.
> The Trillian project was able to do this for two reasons:
> the free and open source GCC compiler had already been enhanced to support the Itanium architecture.
> a free and open source simulator had been developed to simulate an Itanium processor on an existing computer.[185]
Itanium was The Future for a good while. It got plenty of resources, hardware, software, and marketing. By the late 1990s, people knew that full support in FOSS was required, so they made it happen. Itanium died because it was founded on a fundamental idea (making parallelism explicit and relying on software to extract it using static analysis) that simply didn't pan out, and when AMD brought the x86 ISA into the 64-bit world it was done.
I would argue that the shame isn't what Itanium might-have-been, but the architectural roads-not-taken because Itanium absorbed all the resources and mindshare. Would have been interesting to see where Alpha, HPPA...even MIPS R10K family...would be today had the investment thrown away on Itanium been spent more wisely elsewhere.
They'd have been at the same place we are today. CPU architecture is a mature technology and other than horizontal integration and super-wide parallelism, all the basic ideas were already fixed by the early 90's. Those architectures were all just regurgitating each others ideas anyway, there was very little genuine innovation in late RISC.
Well, with the arguable exception of Alpha. The 21264 presaged the modern core most closely, even if it was too big and expensive to be very competitive on desktops. The, er, "21364" reached market a few years later and took over the world as the Pentium Pro.
I generally agree although I do think there's too much mythology around Alpha.
What if Intel had said to HP "That's a really dumb plan" when it brought up the idea of EPIC? I agree probably not much. Intel would presumably have accelerated what Gelsinger called a 64-bit RAS Xeon in a magazine article. Probably good for Intel and not clearly negative for HP. (Both companies went that route in the end anyway.)
Less money would have been wasted in general but it's not like a company spending $100s of millions on Itanium would have told its engineers and other employees to go fiddle with some other exotic architecture. It probably just wouldn't have hired them in the first place.
Seems almost certain that we would have ended up with something that looks exactly like x86_64 a few years earlier in that case, no? I mean, it's not like AMD invented fundamentally new concepts or anything. The doubled GPR set was likely to happen regardless. The REX mechanism might work differently (like moving to a 3-address encoding). Maybe Intel wouldn't have dropped segmentation and we had a new selector record in long mode to worry about. Maybe we wouldn't have the sign bit rule in addresses. None of those are design-breakers.
Again, if no one (including giants like Apple and NVIDIA) has invented new ways to run code in the last 30 years either, it seems like wishful thinking to argue that Intel would have somehow done it had they been less wrong about VLIW.
>Seems almost certain that we would have ended up with something that looks exactly like x86_64 a few years earlier in that case, no?
You're probably right. If Intel had said (internally): "Screw it. Let's just extend x86. It's not like we have anything to fear from AMD." You'd probably have had it a bit earlier. (Though it's not like most buyers of x86-based systems were screaming for 64-bit until into the 2000s anyway so it's not clear that there would have been a big push to pull the timeframes in by much.)
And Intel would probably have still pushed too hard on frequency and ILP--because Microsoft if a senior Intel I exec I knew who isn't prone to lying is to be believed.
Also, yeah. Apple Silicon is great but it's not new paradigm great. If anything, the revolution has been in heterogeneous computing (esp. GPUs to date). And a lot of that has been partly enabled by open source.
That's kind of my point. We didn't need some new, speculative, architectural innovation. We would have been better served investing those Itanium dollars in pushing the mature technology which ran the software we wanted to run better. "Genuine innovation" is often an academic exercise, rather than market changing, though we often don't figure that out until later.
Not sure I'd say the 21364 was PPro since as pointed out it came before 21264. There's clearly some crossbreeding tho. The Alpha bus interface did live on in Athlon, tho.
Itanic is just the latest in a long line of architectures that include the caveat "well, yeah, that's a problem but the compiler will make up for that". While compilers have measurably improved over the last 30+ years, the magic compiler tech that makes things like Multiflow Trace, Cydrome or Itanium performant enough to make a difference in the market hasn't materialized. It isn't that the compiler didn't 'happen in time', it still hasn't happened.
What really happened was that cache misses kept increasing in latency (CPUs getting faster, memory isn't) and static scheduling simply cannot scale that far. Multiflow and friends would have exactly the same problem in a modern implementation - static scheduling is fundamentally hopeless.
Transmeta did slightly better as CMS (the "JIT") could take advantage of biases discovered at runtime, but still couldn't do as well as a fully dynamic scheduler.
The shift to Linux happened around the same time, and few people would bother with anything else but GCC. It might have might made a difference if the Gelato Federation had arrived earlier, with more funding, and a mandate to conduct generic toolchain maintenance, in addition to Itanium-specific work. Kind of what Linaro does today. I think Gelato was way too late, and I don't recall it being particularly impactful (but it's been a long time ago, sorry).
The shift to Linux was a bit too late. By the time it happened, Itanium was lagging behind, with Intel resources relocated to match AMD’s 64-but x86 offensive. Maybe, with enough resources Intel and the FOSS community would be able to get the smart compilers an JIT optimisations that could have made EPIC a competitive architecture.
The tech was solid but the implementation left a lot to be desired. I still shudder when I think about the RHEL 6 Itanium DB cluster I "inherited" and had to maintain. A very temperamental serial console that would constantly freeze up. No local storage so we were forced to boot from SAN. I prayed every time we rebooted that it would actually come back up. Plenty of times it didn't.
But that’s all on the tooling side. It’s not really Itanic’s fault. Had it run a decently reliable OS, it’d be fine. It never lived up to the hype, but caches were humongous for the time and more than once they were able to hold most of my working dataset.
I can't see how. It was priced too high to be attractive to the people running Linux at that time, while not being any faster. It was aimed at people running large-scale enterprise DBs, which was not a good use case for linux at the time.
What was missing? HP donated some 2U itaniums to my university, I installed Redhat, downloaded from Redhat. All the expected packages where there, and it just worked.
They made deals all across the industry to get people to sign up to support Itanic, and in the end people got a very mediocre CPU that always promised more than it delivered and always cost significantly more for the same amount of performance elsewhere.
In the meanwhile, Alpha is still supported by gcc, has repositories of tens of thousands of current binary packages, and still has options for modern open source OSes. m68k has gcc and clang support. Heck - even VAX has ongoing gcc support.
You can barely give away an Itanic system these days. It truly is a very sad architecture.
OTOH, some people are still having fun with Itanic systems:
https://twitter.com/search?q=%40jhamby%20itanium