The Itanic Has Sunk
honeypot.net
honeypot.net
Interesting technical tidbit - I remember an Intel engineer giving a talk at Stanford about the architecture and Hennessy came to listen. At the end of the talk he asked why they thought moving so much complexity to the compiler would work when other (including John) found it to be problematic? They didn't have an answer and I could see the look on John's face and at that point realized they might not understand what they are getting into.
Had Intel not embarked on the Itanium project, we might still have ended up with something close to the world we have now, with x86-64 and ARM being the top dogs, and some "traditional RISC workstation" architecture surviving in a small high-end niche (POWER).
HP replaced Alpha with Itanium but that was a costly mistake.
HP bought Compaq 2001, Compaq had bought DEC earlier.
It was weird, I worked on those superdome machines for years without seeing them. and only got to see them when they had to debug some of my serial port code (it turned out the cable was wired wrong...)
HPUX had some really interesting Real Time Extensions. I was on a exploratory group for switching to Linux and scheduling control was going to be a problem (15 years ago...)
But those were in a class of their own... :) If you scale things up that big they're going to belch heat no matter the architecture.
I don't think PA-RISC was inherently worse at performance to Watt than other competing processors at the time.
https://bytecellar.com/2016/03/02/a-quick-tour-of-the-hp-900...
This doesn't signal that the segment is economically unviable, and if you're an existing player with an existing strong design, it signals an opportunity to invest in your own next generation and meet Intel/HP head-on with a superior brand (for this segment) and a more plausible next-gen design.
Intel and HP show up promising a clean sheet design in a decade doesn't seem like a time to roll up your market leading offering and go home.
Here is an article from 1999 on Sun booting SunOS on Itanium:
https://www.zdnet.com/article/sun-boots-solaris-on-itanium-h...
Compaq stopped making Alpha servers and switched to Itanium:
https://en.wikipedia.org/wiki/DEC_Alpha
Itanium was a huge misdirection and distraction for everyone in the workstation business and basically put them in such a bad spot they failed to even compete with Intel x86 past 2000 or so in any real way.
>>Intel and HP show up promising a clean sheet design in a decade doesn't seem like a time to roll up your market leading offering and go home.
They didn't roll up so much as have their existing market disappear. SGI, DEC and Compaq were dead. Sparc and Power gradually transitioned away from any workstation offering to servers.
--
For anyone who wasn't there: In the 80s, Coca-Cola had lost its crown. Pepsi was the most popular soft drink, at least in the USA. Coca-Cola responded by changing their recipe, to great fanfare.
It's often held up as one of American business's greatest failures. People hated New Coke, and later that year they brought back the old formula, under the name Coca-Cola Classic.
I think that that summary of the story misses an important point, though. After the dust had settled. Coke had regained its crown, and has held it ever since. So, while New Coke itself failed on the market, the event's long-term influence on the company's financial outcomes was overwhelmingly positive. To the extent that some people have claimed that the whole thing was just an exceptionally clever PR stunt.
"Old coke", as well as what is now known as "mexican coke" in the USA, used/use sugar.
New coke was the flag day for switching to a cheaper sweetener in the US market. When they switched "back" to coke "classic", they kept the new sweetener.
https://www.motherjones.com/food/2019/07/the-secret-history-...
First, people have done triangle tests on sugar- vs. HFCS- formulations of Coke (Serious Eats has a good one) and, while there is definitely a perceptible difference, the preferences aren't what you'd expect. People who go into these tests saying they prefer cane sugar Coke tend actually to reveal an HFCS preference in the test.
Second, formulations in different parts of the world vary in ways other than which sweetener they use. It's possible that regardless of the sugar involved, there might just be more of it in the formulation (or in the way it's delivered, since concentration systems also vary) in your least-preferred Coke instances.
Non-lite/diet/zero coke is always sickly syrupy oversweet regardless of whether it's sugar or corn syrup. It's sort of what people are going for. I can't believe I used to drink liters of it a day growing up; I limit myself to a dozen servings a year or so (of the full sweet stuff) these days.
Coke wanted to beat those tests, so they designed a soda that people loved much more than Pepsi under those same double blind studies. In an 2oz or so sample people adored New Coke over Pepsi.
In a 2oz pour (shot) the sweetness is a big differentiator, the one that stands out is pretty much always going to be the sweetest. (Like the Loudness Wars in music, there's a dumb human psychological bias in small samples for sweeter in taste or louder in volume as "better", despite both being awful for your health in quantity.) What Pepsi and Coke both seemed to forget in the 80s that focusing on these 2oz "micro-benchmark" test studies was that most people don't drink just 2oz at a time, the unit is generally closer to the 12oz can or more. When drinking more than say 2oz overly-sweet becomes a problem in how it lingers and you want a more balanced palette, which Coke Classic always delivered better than Pepsi.
The failure of New Coke will always be a great illustrated story of make sure you are designing for the right benchmarks (and sometimes micro-benchmarks especially are a trap).
I believe that deeper extension of this metaphor likely also applies to Itanium, they designed it for 2oz pour benchmarks where it sometimes got fantastic numbers, but most compilers got awful numbers in realistic real world workflows.
We certainly had an Itanium build as well, although it doesn't appear on that list, which suggests that it never sold. But it's notable how many of those platforms are effectively dead and only the open source ones on x86 are left standing - and OSX, which deliberately has no server platform.
That era was when people were just starting to realise how much more cost-effective OSS+X86 was. That is what ate the server and workstation markets, especially once people started to horizontally scale and "the cloud" appeared.
The only orgs left with the capacity to choose a new platform and make it cost-effective for the world are basically FAANG+M. And which one of them bought a fabless semi company full of RISC designers from all those dead instruction sets? Apple.
Sure those workstations were powerful and had impeccable engineering, but they also cost at least 5 times as much as a similarly powerful PC. Sometimes more a full order of magnitude more. Plus they were full of obnoxious licensing requirements, like making you purchase a compiler for thousands of dollars per year or requiring you to buy an obscenely overpriced support contract to get OS updates. They just couldn't complete with some cheap clone running Linux, especially as Intel poured way more money into R&D each year and overtook the workstation chips. By the time the Core architecture, and especially Conroe, were released those old workstations had nothing going for them but inertia.
Itanium felt much more like a sideline activity for those that didn't believe x86_64/Linux was going to be as big as it was. They viewed it as a sort of "toy infrastructure" until it was too late.
In fact, allow me to tell a story: as a young engineer, I attended a talk at Stanford, by John Crawford, architect of the Itanium (then known as Merced). He was presenting a bunch of benchmarks that seemed... dubious. And while Merced kicked butt on Eight Queens, it was terrible on gcc (and everything else that looked vaguely real-world). Even as brash as I might have been (ahem), I wasn't about to say anything, but then some guy in the back of the room just got on Crawford on this. Crawford tried to shake him off, but the guy was just a badger, at one point saying "Doesn't this just willfully ignore everything we've learned about commercial workloads over the last decade?" At this point, I turned around -- who the hell was this guy?! -- and saw that it was none other than John Hennessy himself. A Silicon Valley gangland slaying if ever there was one -- and told me everything I (or anyone) needed to know about Itanium's fate.
The room was packed (and open to non-Stanford students, which is how I got there); glad to know I wasn't the only one on whom this made an impact!
[0] https://i.reddit.com/r/IAmA/comments/31ny87/i_am_the_cto_of_...
(I hope the podcast comes back, by the way!)
The manufacturers that intended to switch to Itanium were either part of HP (compaq & dec) and would have thrown in the towel otherwise or were desperate to remain relevant (SGI). They could never had tried to compete itanium or no itanium. Itanium actually made no impact on the strongest competitors, SPARC and POWER.
Not only did Intel lose billions on Itanium but it tied up development resources that couldn't be used against AMD and influenced the decision not to compete in the mobile space.
Ayup. The DEC guys cheered when Intel announced that Itanium would be VLIW. They knew that Intel was about to sink a huge amount of engineering effort into a dead end that would never work.
Of course, nobody realized that all the business management chains were complete cowardly dipshits and that Intel spending a Gigabuck was sufficient to terrify them into completely abandoning the high-end market to Intel who milked it for years.
So ... Itanic was a horrible engineering failure but a great business success.
The Itanium led to one of a more remarkable episodes in my career. Around 2007 we were running a heavy workload on MS SQL Server in a fast growing business.
We faced a lot of outages due to DB overload. Instead of trying to investigate and understand the issue better and optimize the software, some external consultants were brought in and recommended to upgrade the hardware to an Itanium based monster. It was a massive piece of hardware with a price tag close to 7 figures.
The thing went live and performance decreased and issues increased. After a couple of weeks of trying to run on the Itanium we switched back to the old setup and then focused on software improvements.
Long story short - after about 8 weeks of dedicated troubleshooting and improvements the whole app became stable, was capable to double workload on the same hardware without outages for the next 12 months.
The Itanium took up a lot of space in the server room before it was dismantled and used as a paperweight. A lawsuit involving multiple parties (supplier,consultant,business) eventually got settled out of court in 2015 (?) long after I left there.
Farewell Itanium :)
Is there a single example of that working anywhere ever?
I have never seen one.
[1] https://web.archive.org/web/20210705021438if_/https://www.th...
I have recommended buying a huge piece of tin to run SQL Server on as a valid, cost-effective solution to a performance problem. Currently, EPYC CPUs are great value for money, programmers are expensive, and some workloads are too time-consuming to tune.
The customer implemented the change, and it worked.
I have also recommend a reduction in size of a too big SQL Server coupled with some judicious optimisation to reduce the load dramatically. Even expensive programmers can spend a few days of their precious time fixing glaring query issues.
The customer implemented this change also, and it also delivered the promised benefits.
I have the before-and-after metrics to prove that there was a huge benefit in both cases.
In both cases the issues were ongoing, had caused drastic outages, and the internal staff were not capable of resolving the issues on their own.
To be honest, 99% of my job is just to be the outsider that's not playing politics and not stuck in a narrow job description. I'm told to "fix it", so that's what I do. The internal staff have "roles and responsibilities", and they fight with other teams more than they cooperate. Some people actively hate each other. I come in as the neutral party and for a brief shining moment I can get everybody to row in the same direction.
That is the single reason driving external consultant hire in many enterprises.
Always thought that was funny, and probably pretty accurate.
I swear the big benefit of cloud deployments is the teams ability to say “we tried throwing $$ at the problem, if we don’t want to spend $$$ we’ll need to do some work”. And have this convo play out over a day rather than months.
My current job is on the tail end of hypergrowth and we are just starting to get our arms around the years of hacks and inefficiencies that made it possible to succeed. We've had a dozen conversations where we've decided
* to throw $10^2/day at a problem for two weeks so the engineers are free to deliver the features required to land $10^5/year in ARR, then work on perf
* to analyze the system, identify the one or two features that cost the most, and tackle those while leaving the rest alone
* and yes, to translate inefficiencies to real dollars and use that to force prioritization (we do that a lot ;-))
A team that understands cloud computing and can do some cost forecasting makes some amazing things possible.
They had made the 8008 and 8080, but those were awkward and ungainly chips meant to power calculators, of all things. iAPX 432 was a clean sheet 32 bit design designed for high level languages and real computers, kind of like mini Lisp machines, complete with native machine support for garbage collection. But it was taking a while to get out the door, and performance wasn't so great, so they hacked together a quick upgrade to the 8080... the 8088, which was used in the original IBM PC.
History takes over from there.
The reason it never went mainstream is easy enough to explain: expensive chips and (for the hypercube) a very different programming model.
I managed to miss the magic that is the 88k thankfully. Who actually used it? Linotype? Tek workstations maybe?
Applied made high-end in-circuit emulators. My team worked on software for execution trace disassemblers. We had wide and deep memories and could record something like 16,384 bus cycles in emulator (trace) memory.
Once we had some bus cycles to analyze, we’d sort out what the processor had done when it ran (an execution trace) and show it. It was a great tool for answering questions like “How did I get here?” when your embedded code jumped off into the weeds.
The i960CA was relatively simple to work with. The i960MX was a lot more complicated, as I recall.
IHVs had little interest in I2O as it would reduce Intel's costs for swapping out vendors and there was no demonstrable performance improvement. The latter was at least in part because the I2O infrastructure was immature in comparison to the IHV drivers. It eventually formed the model for I/O over Infiniband (where it did make sense).
[0] It's not clear if I2O was the original application for the 960 or it was a pivot for an otherwise homeless processor.
I developed an i960RP design back in the late '90s for an MPEG-2 encoder PCI card. The encoder chips were also PCI, so the PCI bridge on the i960RP made for a nice design where all the PCI stuff was handled in one fell swoop.
For some reason, the BiiN project was terminated in 1988 and Siemens was not interested any more in it.
On the other hand Intel decided to not scrap the results of that project and they introduced the 80960 series based on the architecture formerly known as BiiN.
The commercial name 80960 was derived from their previous 8096 series of 16-bit microcontrollers, so 80960 was initially presented as higher-performance 32-bit replacement for the 8096 series, which was used in various embedded computers.
One interesting feature of BiiN was that it was the first monolithic CPU with an atomic fetch-and-add instruction (first used in 1981 in the NYU Ultracomputer project).
The 80960 inherited the atomic fetch-and-add from BiiN and then Intel added it to 80486, under the XADD mnemonic, together with the atomic compare-and-swap taken from IBM 370 and Motorola 68020 (CMPXCHG).
The applications for which 80960 was best known, like I2O and laser printers, happened significantly later than its initial introduction.
You mean it was biinned.
https://en.wikipedia.org/wiki/Intel_i960
The I2O project wasn't until the mid 1990's
In 1984 it was just the start of a research project named BiiN, of Intel and Siemens, which lasted 4 years, until 1988, when Siemens dropped out.
The series name, 80960, did not appear before the launch from 1988.
I also believe that MMX was basically lifted from the i860, although again, i'm not sure.
It's funny, I tend to think of Intel as the boring chip company, due to the success and legacy that we like to moan about from ia-32, but they have actually made a fair few plays to try and move things on from there, fighting against the market which just wanted ia-32 compatible but faster processors.
Intel, for better or worse, are a victim of their own success. On the plus side, their success gave them lots of money to throw at the problem of making faster x86 CPUs. It seems, though, that Intel is gradually running out of luck, with AMD and now Apple introducing strong competitors, and Intel's advantage in fabrication eroding. So CPU-/ISA-wise, things could get very interesting in the foreseeable future.
One said that computer hardware should have hardware support for high level languages. That school led to the VAX, iAPX432, and 80X86. The other school said that computer hardware should be simple so that it could go faster, and that the compiler should be smart enough to map high level languages to simple hardware.
Intel was firmly in the first camp. It flirted with the second repeatedly: see the late '80s i860/i960. Itanium was the biggest bet placed: it was a RISC-like architecture with the added complexity of multiple dispatch encoded in it's Very Long Instruction Word architecture. The compiler could rearrange instruction order to keep hardware busy, AND (to some extent) instruction contents.
Itanium seemed like a reasonable bet, and Intel (and HP) had the clout to convince others. It was a factor in the decline of the Alpha and MIPS server market, and even Sun hedged its bets by porting Solaris.
The MC68000 ISA was meant to run C code.
I remember talking to Vic Poor when I used to work with him and calculators didn't seem to figure into the whole deal. It's probably worth a quick read through Datapoint history.
The 8008 was the (slower) single-chip implementation of the Datapoint 2200 terminal's processor. The DP 2200 was a serial terminal capable of running code on its own as a standalone machine, conceived in 1969 (originally as a drop-in replacement for the IBM 129 key punch), announced in 1970, and eventually introduced in 1971. Datapoint had commissioned the chip, but rejected the result, as it was slower than the discrete logic design, with rights for the chip-implementation remaining at Intel. This remarkable terminal has been with us ever since.
> The iAPX 432 failure could best be summed up by a meeting of Intel marketroids and Tandem engineers who wanted to use the chip in their next generation machine, after the slides, the senior engineer asked: “How long does it take to execute a procedure call?”
> The presenter looked it up. “Two hundred and fifty microseconds.”
> Tom immediately walked out, followed by the majority of the Tandem software department. The presenter was poleaxed. “What did I say?”
Found in comments to https://www.youtube.com/watch?v=FvmTSpJU-Xc , but I saw it somewhere else, too, I just don't recall where. Doesn't anyone know?
(Netburst is also unfairly maligned if you ask me; contrary to the article, enthusiasts have clocked those P4s up to 12GHz. As far as I know they're still, over a decade later, the fastest CPU for single-threaded sequential integer workloads that has ever been made; certainly the fastest x86-compatible processor for such. They're kind of the equal and opposite failure to the Itanium, ironically enough)
From my limited perspective, I find C one of the easier languages to write optimizing compilers for, and would therefore expect optimizing compilers to be the most efficient there. 40 years of collective experience of optimizing for C-like languages also helps of course.
Or is it the lack of explicit parallelism in the language that is limiting? Somehow I suspect the limited uptake of better suited languages to be a sign that they aren't very helpful most of the time, and most of the parallel operations people do is more like serving a lot of individually sequential transactions per second, which is something C and unix is pretty good at.
I checked on grep.app, there are 10k results for `restrict` for C code, compared to 700k for `struct` (I know they're not directly comparable but that gives an idea.
I've been working with C since the early 90's. I've never seen any code use restrict.
[0] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94....
The Rust compiler has repeatedly found critical bugs in LLVM's restrict / noalias support, bugs that would impact C / C++ as well if any real-world C / C++ programs actually used it.
If compilers produce straight-up broken code in these situations, I can only imagine they're not putting a lot of effort into these optimization strategies.
restrict is rare in C and C++ but common in Fortran; array parameters in Fortran aren't allowed to alias. Intel and IBM both have great Fortran compilers so I would expect their C and C++ compilers to have good support for restrict.
Modern languages like Rust tend to produce more instructions for the same high-level logic, but those instructions are easier to schedule for superscalar CPUs. It typically ends up as a bit of a wash on CISC processors, but could be better than C/C++ on VLIW.
I guess we'll never know now...
I was thinking of languages where dependencies are more explicit and the idea of a global evaluation order isn't there in the first place. I'd be very interested to see a reduceron-style effort that implemented graph-reduction evaluation on a VLIW processor.
> Somehow I suspect the limited uptake of better suited languages to be a sign that they aren't very helpful most of the time, and most of the parallel operations people do is more like serving a lot of individually sequential transactions per second, which is something C and unix is pretty good at.
Heh, that was the idea that those barrel-processor SPARCs were designed around. But they weren't so successful in the market either in the end.
I doubt that even a 8GHz P4 would be able to beat a lower clocked more modern design even on single threaded integer workloads. The P4 had a lot of glass jaws (the non-constant shifter, load replays on misses, very narrow decoder when running out of trace cache).
I think that's still pretty much the bible for frequency records.
The computing world has moved on from C, mostly. To Javascript. The main impact of that seems to be a couple of numeric conversion instructions on ARM?
(OK, not entirely fair: the computationally heavy stuff has moved away to GPUs. But if you ask the question for every button press a human makes on a computer where the dominant execution time is you might have some interesting answers, and for a lot of them it is going to be JITted Javascript)
I think it's fairly clear that for general purposes VLIW is not what either the programmer or the compiler writer wants to deal with. In-order execution is such a convenient mental model that people are willing to accept any tricks that keep it working.
The C world isn't moving to Javascript, it's moving to Rust, Zig and Go.
MATLAB simulations were comically faster on my lower clocked Pentium M laptop.
There's your problem.
Given the bajillion programs out there already, how many companies wanted to dig into assembly instead of just waiting 18-24 months for Moore's Law to speed up their software?
It's all very well and nice to have nice hardware in theory, but if you can't compile existing code to be fairly fast, then in practice you just have some expensive sand (silicon) in the shape of a square.
> People let their (understandable) hatred of Intel-the-company colour their technical judgement.
So getting back to your first statement: no they didn't. Everyone was basically all-in on Itanium. All the Unix vendors (except Sun) dropped their own architectures and steered their customers toward Intel. Microsoft released software for it.
But it seems the market didn't like what they saw, and just kept on with x86—and then amd64 came out and gave 64-bits to everyone in a mostly compatible way.
cough IBM cough
They were never going to ditch power... Did they ever even have an Itanium product? I know they've had x86/x86_64, all sorts of power variants like Cell and god knows what.
I did briefly work on an Itanium system at IBM, but it was an HP box.
The people that bought Itanium-powered servers certainly weren't replacing them every 18-24 months. At the price they paid, you were looking at 5-8 years of computing before replacement. Or more.
My employer bought a pair of the final batch of Itanium servers. To replace 10-year old ones. This was an insurance purchase. The original plan was to shift all of that workload into the cloud, but that's neither going quickly enough nor is it saving any money. If you have a workload for which Itanium does well, it does it really well.
I was referring to the software vendors: why would they go through the effort of optimizing their code for this new architecture when they could simply wait a little while for the "old" one to get faster via Moore's Law?
If only for the reason that Itanium was one of the few architectures not affected by Spectre-family attacks.
I know only few people who maintained software for Itanium, but from their reports it was a nightmare to debug code on. To have a chance to see what was going on, you would have to use special debug builds that disabled all explicit parallelism. Debugging optimized code was almost impossible, and user-provided crash dumps were similarly useless. Your only hope would be that the issue was reproducible in debug builds or on other architectures.
Needless to say, they hated it and were happy when ia64 was finally phased out.
> once the computing world finally moves on from C.
Yeah, it moves on from C... to JavaScript. Making compilers slow and complex doesn't mix well with JIT compilation.
One thing I have to give Itanium credit for is that due to EPIC it was totally safe from the speculative execution vulnerabilities like Spectre/Meltdown/etc. That was certainly a forward-looking aspect of it.
Oh god. Let me guess, when it crashes, you get a pointer to the word with the failed instruction in ... but no elaboration on which of the 3 instructions it was? Or is it worse than that and it fails to maintain the in-order illusion?
Funny, I was just thinking the opposite: Compiler-driven parallelism loses against CPU-driven parallelism because the CPU has live profiling. With a JIT the compiler can have it too.
The debugging problem on the machine-code level becomes less of an issue when most people write higher-level code too.
Instruction level parallelism achieved by decoding a single stream and then sorting and scheduling requires more silicon and a bit more power, but low power high performance superscalar chips like modern ARM64 CPUs have shown that the cost is not that high and that you can go very wide. The M1's Firestorm cores are 8X wide from what I read, which is better than Itanium.
Since the whole superscalar architecture is hidden, it can evolve freely.
That being said I don't think VLIW was a horrible idea at the time, and it might still have a chance if it were revived in specialized high performance or ultra-low-power use cases. The mistake was betting the farm on it.
The other big thing we learned since then is that the important part of RISC wasn't reduced instruction set size, but uniform instruction size and encoding. That allows you to decode arbitrarily wide chunks of instructions in parallel without crazy brute force hacks like those required to do parallel decoding of the variable length X86 instruction stream. The problem with CISC isn't how many instructions there are, but the complexity of the encoding and the presence of a lot of confounding requirements that arise from instructions that to very different things at once (e.g. complex math with memory operands). You want the instruction stream to be trivial to decode and easy to schedule.
In the end the best approach seems to be a simple general purpose instruction set augmented with special instructions for common special cases that can be greatly accelerated this way (e.g. vector operations, floating point, cryptography, etc.), and all with a logical fixed length encoding that is easy to decode in parallel. Load-store architecture and a relaxed memory ordering model seem to also be performance wins since separation of concerns simplifies the scheduler. The future (for conventional CPUs) looks a lot like ARM64 and RISC-V.
Vaguely related ideas from the distant past are ANDF:
https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...
And TaOS's VP Code:
https://sites.google.com/site/dicknewsite/home/computing/byt...
IBM i is on a POWER CPU today, but can still run System/38 binaries from the 70s, thanks to install-time compilation to whatever CPU the system is running this decade.
I admit that I’m glad Itanium finally died. It killed a lot of other interesting architectures and gave nothing in return.
unwarranted optimism. I recall HP Pentium Pro servers with loads of "built in" stuff and dual PCI buses: all the builtins were hung off the 2nd, chained bus; on one IRQ. The memory was severely limited, too, iirc; NUMA'd through one of 4 CPUs.
HP design seems to be all about locking performance away; it might be in that box in theory, but all their ingenuity was spent ensuring it stayed there.
What sort of architectures (if any) got killed as a direct result of developing IA-64?
That aside, though odd and impractical, I found Itanium to be at least a technically interesting perspective (both in terms of architecture, ie VLIW, and in terms of the amount of technical work it inspired at HP and Intel, such as the Itanium C++ abi [1])
Alpha?
To be fair though, I think its death is more attributable to ARM than Itanium. And RISC-V is killing off anything that remained.
https://www.realworldtech.com/forum/?threadid=27345&curposti...
It had very strong floating point performance and on spec int it was holding pace with Opterons, Athlons and P4s clocked a lot higher. Apparently a lot of the int performance was due to large fast caches (I think it had a bigger die size compared with the others) -- have a look at the 1.5MB version vs the 3MB version. But even there it wasn't doing so bad against the Sun and IBM processors which were out of order I think. So yes you're right some things did run pretty fast.
Unfortunately for Itanium, compiler techniques to make up for in-order execution had just about run out of steam at that point, while OOOE continued to scale up and improve steadily. Which is pretty much the opposite of what HP and Intel had predicted in the 90s, which is why they justified Itanium's approach.
Huh, I never really connected the dots before, but TIL that this is why 64-bit images and package repositories of various Linux distributions were referred to as `amd64`...
And IIRC, AMD's x86 license evaporates automatically, if the company is acquired by someone else, which means the only company that could buy it without disastrous consequences is Intel, who probably would run into some anti-trust issues if they did.
Tl;dr: many new patents have been created over the years, for instance SSE extensions, and those haven't expired.
Meanwhile AMD offered "x86, but faster and wider", which (once you booted a 64-bit operating system) could run either type of binary at native speed. Sometimes people really do just want a faster horse.
I thought this was sarcasm, but the tone continues throughout the article. Are people this really painfully misinformed? The ISA was brilliant. The execution, not so much. It was a far more scalable architecture, completely "clean" from x86 baggage (I'm talking about the ISA, not the thermal issues Madison and McKinley had with the floating point units). It even ran Windows and had two compilers (one from HP and one from Intel), and it decoded x86!
Then again, people were also hot on Transmeta at the time, so perhaps the author is confusing things.
> better known for the good designs you killed
Like?
Intel sat on Yamhill (64b "star-T" for x86) for a year, and when I was brought on, the project had issues in both instruction fetch and execution-unit area. It was not a good design, and was not ready because it was cobbled together at the last minute. Quite literally. AMD beat Intel to both 64-bit and 1 GHz, and we all (architects) knew it.
Looking at it one way, Itanium was a product that was ahead of its time. In 1995~97 Google didn't even exist yet, Amazon was just getting started. Server farms with their own power plants were something reserved for investment banks as redundant backup, US eCommerce was well under $1Billion/yr . I'm 100% certain that if Intel had brought the yields up on Itanium and taken an early loss to build market share, it would have been the dominant architecture in integer cloud today.
But in reality they had to beat AMD, because AMD was going after their cash cow (commodity x86) with a vengeance, and winning. Couldn't fight two wars at once, and thus, Itanium withered.
So looking at it another way, one could argue Itanium was too late because the internet scaled out fast in late 1990, and Itanium was caught with its pants down, so x86 filled in the gap.
Either way, Arm is more likely to take away server market from x86 than IA64, going forward, but that's a not a sure thing.
I could (30% chance) see VLIW making a comeback if capacity weren't such a problem, it is far more suited to e-commerce cloud instruction mixes, and with hypervisors and docker-like virtualization so much faster than VM, it could happen.
So I am drawn to Linus Torvald's commentary on IA64:
"IA64 made all the mistakes anybody else did, and threw out all the good parts of the x86 because people thought those parts were ugly. They aren't ugly, they're the "charming oddity" that makes it do well. Look at them the right way and you realize that a lot of the grottyness is exactly _why_ the x86 works so well (yeah, and the fact that they are everywhere ;)."
I think this is the most astute statement he makes: "yeah, and the fact that they are everywhere."
> ARM's Johnny-come-lately 64-bit implementation that has gone farther up and down
What do you mean? Arm is primarily embedded IP, where 64b only recently has come en vogue (unless you mean A5/A7?, I'm talking Cortex-M). Arm competitors are really Renesas, Synopsys, TI, and a number of Chinese chips, and 64b isn't a prioirity in most of that space. Not defending anyone, just not sure what you mean.
The P4 was built with an enormous pipeline (~20 stage?) in the hopes of reaching a 10ghz goal that was never going to happen.
The Itanium was designed a decade before, programmed for parallelism that was also never going to happen.
The M1 is not an esoteric machine, and if Apple had bundled an Itanium of equal computational ability, all of those NOPs would burn a hole through the casing.
ARM's 64-bit implementation is obviously something special, esoteric or not it is more powerful than anything produced by Intel in several measures.
> The M1 is not an esoteric machine, and if Apple had bundled an Itanium of equal computational ability, all of those NOPs would burn a hole through the casing.
You're right, its not. And I never said it was. But a 6D mesh torus sure is.
Linus says to ignore the design mistakes like segmentation.
Then he says:
"the baroque instruction encoding on the x86 is actually a _good_ thing: it's a rather dense encoding, which means that you win on icache."
How wide is the widest Intel CPU? How wide is M1? Case closed.
It was sarcasm, but the tone continued because I think Itanium was an enormous waste of time and other resources.
> The ISA was brilliant.
I completely disagree. The ISA depended on enormous leaps in compiler technology in order to make it useful. However pretty it may have been, it couldn't be implemented in a performant way. It'd take ugly-but-practical over pretty-but-impossible any day of the week, especially when I get to use languages that abstract the ugliness away from me.
Put another way: given a choice between stuffing an electric engine in a Ford Fiesta, and a Tesla, Itanium could have been the Tesla in the hands of another company, but the market went after the Fiesta retrofit because it was here-and-now, not coming-soon.
EDIT: changed from "you" to "that statement"; added analogy.
IA-64 required a complete rethinking of compiler design to solve NP-hard problems on a large scale just to get passable performance. Translating C to ASM that keeps execution units busy is radically different on IA-64 than pretty much anything else.
> NP-hard problems on a large scale just to get passable performance.
First, it is hard to refute a claim, or find meaning in it, when you start using terms like "passable" and "good enough".
Second, I think this overstates the need for optimal scheduling because Itanium SPEC performance was "passable" out of the gate.
But all of the details had gross amounts of complexity. More modern VLIW architectures are more obvious about their parallelism... Without any of the weird 'bundles' that made the Itanium terribly complex.
I still think that 'simple decoder' has hope, and I point to NVidia Volta and Turing as my case in point. At the assembly level, the NVidia SASS compilers generate the read write dependencies. NVidia has proven that the compiler can indeed specify the dependencies at compile time, though they require a huge amount of software bulk to be able to do so (PTX pseudo assembly that compiles into SASS later)
The issue is that the Itanium was poorly designed and impractical. But the overall concepts seem to still be possible (indeed, more possible given today's technology). I'd be interested in a modern Itanium, but instead split as follows: where the compiler determines the dependencies but the core figures out the precise scheduling.
This is the only reason why Itanium failed.
Had AMD not been allowed to produce Intel-compatible CPUs, everyone would eventually be forced to eat Itanium regardless how they tasted.
One doesn't get to be picky when food supply dries out.
But in the server space the story might have been different.
I take it intel were planning "Mobile Itanium" at some point?
Yes, on the server it would have been differently, however Linux distributions might have still killed the other UNIX vendors with their CPUs alongside, as it happened.
I spent some time "optimizing" code to run on Itanium for "MegaBank". Who then dumped it. Then we swapped to AMD Opteron for while before Intel caught back up.
I suppose it was successful in that it created work.
Unless you worked in their HFT group, that is.
[1] high frequency, not necessarily low latency, for some defintion of the word 'high'.
"This annoyed them and they decided to make a new CPU that no one would want to use."
Facts: 1. Itanium grew out of internal HP efforts to define their next generation architecture, presumably in response to their difficulty scaling the Precision Architecture.
2. Intel only got involved part way through.
3. Nobody ever "decides to make a CPU that no one will use".
Itanium for all its issues, was used in great number, but nowhere near what it was supposed to. The failure of Itanium was a bet of handling cache misses with the compiler (like Transmeta, my alma mater) and having a design by committee (lots of nice ideas in isolation, a disaster in aggregate).
There are so many technical problems with the ISA, too many features, too much performance draining complexity. Something as critical as registers is burried behind (IIRC) three levels of indirection (rotating windows, modulo scheduled registers, etc). The big bet on predication didn't help code density nor cycle time.
It's really a shame that Intel throughout history has botched ISA design after ISA design. That it can be done right is exemplified by Alpha, RISC-V, and ARM64. If the rumored acquisition of SiFive happens, then maybe they can finally get it.
EDIT: Typos
Also, on the time of its peak, the Itanium did perform quite well, I wonder what it could deliver, if it would be grown to use all of modern production processes.
Maybe VLIW cannot be made to work, but I do think that Intel missed the boat by not providing cheap development systems to enthusiasts. Like a PC-compatible motherboard with an Itanium for like 500$. The Linux crowd would have picked it up gladly. Instead, it was only available as espensive hardware, which reduced the potential developer audience (both from the availability of the development resource itself as in the target market).
The post mentions, that everyone picks up the new Apple Silicon processors, because they are nice. They certainly are, but the big point is, that a compatible ARM system can be picked up for as little as $35, the Raspberry Pi and its friends. And while Apple hardware isn't low-cost, it is increadibly cheap in comparison to the Itanium systems of that time.
Now they cry help to the same engineers they have turned away from in the past.
Which is strange since IIRC Intel engineers designed the PCI bus to replace ISA in spite of management saying that's for the PC makes to do. I would have thought they'd learn from that success, but apparently not.
https://www.reuters.com/legal/transactional/oracle-loses-bid...
https://www.debian.org/ports/ia64/ https://wiki.debian.org/Ports/ia64
Servers are cheap on ebay and the older Intel boards (also sold by Dell, Fujitsu,..) can be upgraded to newer CPUs that are either less power hungry or faster with more cores and sort-of HT. HP are generally not upgrade-able and SGI/ia64 is a special case with lots of other custom hardware as usual.
Annoyingly many Linux / gcc developers want to remove ia64 support from their source trees because the architecture is no longer commercially relevant.
As a necrocomputing enthusiast it's quite sad, but not much one can do about.
If only this old junk was as popular as the various homecomputers...
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Or...
We have found and fixed multiple regressions in the kernel on ia64. As of Linux 5.12, the kernel runs fine on most ia64, there is still one known regression that affects some machines.
Disclaimer: I'm Debian's maintainer for ia64 (and most other older architectures such as m68k).
That contract helped keep Progeny alive after the venture capital funding dried up; the company's original plan was to allow customers to reboot their Windows desktop computers overnight to run as a distributed Linux supercomputer.
It does, albeit indirectly, and not by name. Poor Alpha and PA-RISC...
In 1989, HP determined that the Reduced Instruction Set Computing (RISC) architectures were approaching the processing limit at one instruction per cycle. HP researchers investigated a new architecture, later named Explicitly Parallel Instruction Computing (EPIC), that allows the processor to execute multiple instructions in each clock cycle. EPIC implements a form of very long instruction word (VLIW) architecture, in which a single instruction word contains multiple instructions. With EPIC, the compiler determines in advance which instructions can be executed at the same time, so the microprocessor simply executes the instructions and does not need elaborate mechanisms to determine which instructions to execute in parallel.[5] The goal of this approach is twofold: to enable deeper inspection of the code at compile time to identify additional opportunities for parallel execution, and to simplify the processor design and reduce energy consumption by eliminating the need for runtime scheduling circuitry.
HP believed that it was no longer cost-effective for individual enterprise systems companies such as itself to develop proprietary microprocessors, so it partnered with Intel in 1994 to develop the IA-64 architecture, derived from EPIC. Intel was willing to undertake the very large development effort on IA-64 in the expectation that the resulting microprocessor would be used by the majority of enterprise systems manufacturers. HP and Intel initiated a large joint development effort with a goal of delivering the first product, Merced, in 1998.[5]
It was fun to play around with, but coming from Linux, HP/UX left a lot to be desired. I'm not sure if there is a way to run Pick/BASIC on Linux but it would have made sense for them. Costs would have went way down being able to use Intel machines instead of paying a premium for Itanium parts.
(Setting aside the question if good compiler support would have been possible with Itanium's architecture, or if the optimizations they thought of could not be implemented in principle. I don't know enough about it to tell for sure.)
The people prophesying the second coming of VLIW (for general purpose code) seriously need to explain the compiler breakthroughs that have been done to make the whole affair worthwhile.
I used a PA-RIRC/Alpha and Power machines in various work roles. All those architectures/OS fell to X86 speed improvements/low prices. All those other architectures couldn't compete as intel X86 got faster and faster and caught up with exotic silicon.
When MS released windows NT for x86 it was over. My Mom's former employer (PTC) released for windows NT a little late and lost ground to SolidWorks. Even Apple gave up using power an switched to x86.
# uname -a
HP-UX antique B.10.20 A 9000/800 862741461 two-user license
# model
9000/800/K380> https://lists.debian.org/debian-hppa/
It might be worth to be hosted at the Open-Source Lab at Oregon State University where we just lost one Debian machine IIRC.
I have several of them, bit they run on 220v power and are the size of a small refrigerator.
The CPUs range up to 220MHz.
Bitsavers has a series of memos showing how the Alpha predecessor Prism went down in flames when DEC decided to quick-fix its technology hole with MIPS.
Alpha was a kind of illicit skunk works leftover from that failed project. If DEC had pushed it out the door a couple of years earlier - not likely, but possible with a push - it might have eaten the rest of the industry.
[1] And it's not like Alpha was some shining beauty of ISA design either. Early versions lacking sub-word load/store, the absolutely crazy memory consistency model, ...
A year ago, Derbauer did a teardown and got some sweet die shots of one: https://www.youtube.com/watch?v=Lqz5ZtiCmYk
Nit: this blog's text is a bit small and thin.
Ooh! The pretty pictures start around 11:03.
(Blog is mine; I'll see about tweaking the text.)
And as with Intel, it just wasn't enough.
If I didn't know better I'd have accused myself of ghostwriting that post. That's amusing and horrifying.. but it's all accurate to what I think!
It didn't sell well, though. At all.
> and how many supercomputers chose to use it?
Here's a chart of supercomputer architecture by year: https://commons.wikimedia.org/wiki/File:Processor_families_i...
Itanium showed up around 2001, peaked in 2003 at about 100 systems, and was nearly gone by 2007.
However good it might have been hypothetically -- and I contend that it wasn't -- it was a market disaster.
The last 10 years or so HP actually paid intel a lot to keep making and developing itanium because they're so dependent on it for hpux and their long term support contracts. If a port was realistic they would have done it