Linux Looks to Retire Itanium/IA64 Support
phoronix.com
phoronix.com
The United States is like the guy at the party who gives cocaine to
everybody and still nobody likes him.
-- Jim Samuels
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:
Are the tweets private or is this a further example of Twitter's degradation?
...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.)
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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).
What a thing to be remembered for. But fitting for the inelegant, baroque architecture IA64 ended up becoming.
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...
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.
- 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.
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.
The ISA wasn't actually that bloated.
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.
* 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.
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:
https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...
> 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.
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).
Intel figured they had control over that by not releasing a 64-bit x86. AMD ruined that for Intel.
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.
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.
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.
Of course, that was before the DEC Hostile Giveaway.
If Linux support would be important, I guess Intel or one of the mainframe manufacturers would chip in.
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..
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.
When the Pentium 4 adopted AMD's instruction set after Microsoft's refusal to support a new Intel 64-bit ISA, the customer base evaporated.
Back then, having Microsoft’s blessing could make or break an ISA. I can’t shake the feeling Itanium was being sold to the wrong crowd.
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.
Their complaints about that system really focused on the administration and provisioning issues. It ran code fine.
Itanium had Linux support from day one:
> 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.
Perhaps another example of “worse is better”…
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.
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.
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.
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.
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.