I had to maintain an IA-64 Linux system at a previous job, and it was such an odd duck. The OS did a decent job of abstracting away most of the weirdness, but at the end of the day it was just a very slow server. The compiler breakthroughs that Intel was counting on to make it competitive never happened, and since its unusual architecture made it bad at running code not specifically tuned to it, the end result was that nothing ran great on it. I’m sure that HP had some highly optimized code that ran like greased lightning, but that never worked its way out to the general public.
I admit that I’m glad Itanium finally died. It killed a lot of other interesting architectures and gave nothing in return.
> I’m sure that HP had some highly optimized code that ran like greased lightning,
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.
> It killed a lot of other interesting architectures and gave nothing in return.
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])
Itanium may have been the nail in the coffin, but by the time the hammer fell on that nail, Alpha was already basically dead due to bad business structure and incentives that were inherited from DEC. They had many of the same problems that Intel has been having recently (low yields, failure to keep up with performance increases) without Intel's long-standing business agreements or inertia to hold up the product line through a difficult period.
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.
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.
And they did it again with the i960 and i860. I'm told they were quite nice processors in their day (never having been close to one myself, that was before my time), but for whatever reasons, they did not go mainstream.
I've programmed both, though only shipped products that used the i960 (CA and KB). I believe the i960 tended to be used in things like printers but there weren't many design wins for the i860.
I managed to miss the magic that is the 88k thankfully. Who actually used it? Linotype? Tek workstations maybe?
I worked with the Intel i960CA parts and the i960MX parts, while working for Applied Microsystems Corporation (now defunct.)
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.
The i960 flopped in part because it was tied [0] to the I2O ('Intelligent I/O') project. (The 2 was always rendered as a subscript). I2O pushed a split-driver model in which the OS driver ('top half') did not talk directly to its hardware ('bottom half'), but queued I2O messages to the bottom half, which sat behind the i960 which did the proxy work.
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.
I2O was definitely a pivot. The original i960Kx, i960Cx and i960Jx had nothing to do with I2O. I2O was introduced later with the i960Rx series.
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.
During the eighties there was a joint research project of Intel with Siemens, for a new processor architecture named BiiN.
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.
The i960 was the main CPU in the Sega Model 2 arcade board, used in games like Daytona USA and Virtua Cop. At the time (early 1990s) the texture mapped 3D graphics in those games were pretty impressive.
I remember i860 accelerator cards being used with Fortran compilers, not really sure if this went anywhere, it's all a bit hazy exactly what happened, but the i860 was VLIW, so the compiler tech required for Itanium was already being explored for the i860.
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.
I don't know about the i860, but accelerator cards for math-heavy workloads are still a thing, of course. I remember seeing a brochure for an add-on card with one or two Cell CPUs, Intel has (had?) their Xeon Phi, and of course GPUs are very popular for things other than graphics.
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.
There were two competing schools of thought in the late '70s and early '80s.
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.
>They had made the 8008 and 8080, but those were awkward and ungainly chips meant to power calculators,
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.
I think the poster is thinking of the 4004, which was originaly designed for a calculator. But that isn't really related to the 8008 onwards, which are based on a Datapoint computer terminal as you say.
> They had made the 8008 and 8080, but those were awkward and ungainly chips meant to power calculators, of all things.
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?”
Interestingly, it appears based on https://en.wikipedia.org/wiki/Intel_iAPX_432#The_project's_f... the procedure call instruction was a heavyweight thing designed to maximise features and it could branch much more quickly - but their compilers didn't handle that out of the box.
People let their (understandable) hatred of Intel-the-company colour their technical judgement. Itanium was one of the more interesting architectures of its time, it fairly flew on expert-tuned assembly; I still believe we'll see a return to its ideas once the computing world finally moves on from C.
(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)
What types of languages do you see would enable more efficient VLIW compilers?
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.
One well known obstacle to optimizing C is the difficulty of alias analysis. It's easier to do that for languages that don't have C's unrestricted pointers.
I suspect if you want a HW architecture for running array operations you'll end up with something like a vector machine (e.g. ARM SVE(2) ) or a GPU rather than a VLIW CPU?
And a traditional scalar architecture is more flexible still. The trick is to pick the correct set of tradeoffs for the targeted applications. I claim that for most array style workloads vector/GPU architectures are flexible enough, and offer better perf/watt and perf/chip area.
What? I use it whenever I have a function that takes two or more pointers if I know they can't refer to overlapping memory. And it's part of the signature for memcpy since C99
When he said "anyone" he meant "almost anyone". You're an outlier if you use `restrict` regularly.
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.
That seems like about the right proportion to me - struct solves a much more common problem than restrict does. And to be fair, it is a lesser known feature. But user-the-name is implying that restrict is somehow difficult to use or understand, which I don't agree with at all.
The paper Why Programmer-specified Aliasing is a Bad Idea[0] evaluated the effectiveness of restrict in 2004. They found that adding optimal restrict annotations provided only a minor performance improvement, on average less than 1% across the SPEC2000 benchmarks.
How much of this is because nobody puts effort into these optimizations?
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.
> How much of this is because nobody puts effort into these optimizations?
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.
C is very "pointer heavy", and much code involves chasing linked lists and the like. This tends not to suit VLIW well.
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.
The TMS320C6678 (C66x architecture) DSPs still use VLIW and work pretty well.
Like most DSPs, they're typically programmed using C, for which TI supplies optimised libraries for processor-intensive operations.
IIRC, the compiler itself was fairly standard.
> What types of languages do you see would enable more efficient VLIW compilers?
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 Can't find any hit for 12ghz P4. I thought the record is around ~8GHz (And you can push modern processors in that ballpark).
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've heard about 8+ GHZ Celerons (Netburst-based ones) and they were definitely on top a few years ago. I haven't kept track lately, though, and those records may have been beaten by now.
I malign Netburst because I owned one (actually still own it) and it was slower than the previous generation of processors (under certain loads) despite costing more.
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.
Kinda veering a bit off topic, but I’ve always seen go marketed as a systems languages alongside C, Rust, etc., but in practice I’ve only really ever seen it used to developer high level web applications.
Docker and k8s, flannel, etc are all written in go and something I'd consider "systems programming" - I mean they have to do some pretty complex coordination w/ the kernel to do thier work.
The numeric conversion instructions you're thinking of are branded "JavaScript", but actually exist to emulate Intel x86 floating-point behavior. It just so happens that the ECMA specs call for said behavior because existing code relied upon it.
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.
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.
> how many companies wanted to dig into assembly instead of just waiting 18-24 months for Moore's Law to speed up their software?
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.
> The people that bought Itanium-powered servers certainly weren't replacing them every 18-24 months.
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?
> People let their (understandable) hatred of Intel-the-company colour their technical judgement. Itanium was one of the more interesting architectures of its time, it fairly flew on expert-tuned assembly;
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.
> you would have to use special debug builds that disabled all explicit parallelism
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?
> Making compilers slow and complex doesn't mix well with JIT compilation.
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.
My understanding is that the problem with VLIW is that it exposes too much. Anything you expose via the instruction set becomes fixed permanently, so if you have say 4X wide VLIW there is no way to ever make it wider or change how things like dispatching work. The only way to do that would be to start pipelining and scheduling VLIW chunks, in which case you are back where you started.
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.
My professor in college back in 1997 was doing research on maintaining binary compatibility between different generations of the same VLIW architecture. If you had a different number of execution units and stuff like that. He had a few ideas and one of them was preprocessing the compiled binaries and rewriting them. Some of them were having flags in the architecture for what generation of chip they were to have the OS do on the fly changes
In a world where all software is JITted (Java gang rise up), the fixedness of a VLIW ISA doesn't matter, because you always compile specifically for the target machine anyway. What you describe sounds like applying that strength of JITting to AOT-compiled code.
Vaguely related ideas from the distant past are ANDF:
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.
Alpha was the reason DEC was for sale. It was a very cool speedy architecture, but it took too long to emerge from the DEC management swamp.
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.
I suspect that whatever the virtues of the Alpha architecture [1], DEC simply didn't have the muscle to stay in the game with exponentially increasing R&D costs.
[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, ...
and MIPS, as a server architecture. In 1998, MIPS Technologies left SGI. Without a major systems house using it, MIPS was left to chase embedded markets. The R10000 had been used by SGI, Tandem, Pyramid, and NEC for high-end servers.
> In 2003, AMD launched their 64-bit, but Pentium-compatible, Opteron CPU. Everyone stopped buying Intel CPUs for a while. [...] almost everyone immediately embraced AMD's instruction set and no one but HP wanted anything to do with Itanium.
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`...
This leads to an interesting situation, where Intel owns x86 and licenses it to AMD, while AMD owns the amd64 extension and licenses it to Intel. Should one company revoke their license, so would the other (I assume, naively), and boom - no more amd64/x86_64 CPUs for you and me. Intel could probably create a new extension to x86, but that would take some time.
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.
What is it that ensures licensing is required? Patents? Because patents on x86 technology predating amd64 should be expired by now... and without patent protection, another company would be allowed to reverse-engineer it, no?
Yup. It was a classic mishandled transition; they messed up the emulation https://www.zdnet.com/article/intel-scraps-once-crucial-itan... , and getting the benefits of the transition required a big ecosystem shift. You more-or-less had to use Intel's compilers.
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.
It also didn't help that the Itanium project was delayed many years. Actually the first one "Merced", was supposed to come out 95 or 96. Had it been on time, things might have looked quite differently. And indeed, I think it was the AMD64 which breathed new life into x86, killing both the Itanium as well as most classical RISC architectures, because it was a nice upgrade path from existing PCs.
it was a great time. I remember buying a rackfull of AMDs at 1Ghz when the opteron first came out. They flew. They also consumed a ton of power and generated a ton of heat (I blew the circuit breaker for the whole floor of Evans Hall, in Berkeley, just turning them on).
It's a bit ironic that one of the reasons for Itanium's failure was that the compilers were not ready. I have no doubt that nowadays GCC and clang would immediately have good support for any new processor (especially from a big player like Intel). In any case the processor vendor would make sure themselves that there would be good compiler support (see Apple).
(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.)
gcc had already existed for 14 years by the time Itanium came out, and it had been widely ported to many different systems... that was kind of the whole point of the project. The real issue I feel is locked up in your parenthetical: it is difficult to put aside the question of whether good compilers for Itanium were even possible, as part of the entire problem was that the VLIW architecture concept was so incredibly different than CISC/RISC that it made porting the compiler very difficult (and while you could, can, and did somewhat easily do naive compilation that simply ignored the potential benefits, the resulting performance sucked). I was in college at the time and I remember VLIW being cited as a reason why compilers had a lot of hot research that needed to be done ASAP.
AFAIK Intel and HP spent well north of $1B on VLIW compiler research, with crickets to show for it all.
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.
Yes -- and explain how code statically scheduled for the worst-case dependences at compile time can ever beat out-of-order and speculative execution that can see the actual dependences at runtime. For anything other than extremely regular codes, there's an information gap that can't be overcome.
They definitely "can" port it, but would they? I believe HP is internally using Linux for more and more things -- the question is if there are enough customers paying for HP-UX to make porting worth it, or if they are legally able to sell the rights to it as they did OpenVMS. Only HP knows the full answer.
There's still a lot of legacy HPUX servers out there, mostly running SAP+Oracle combo, but they all slowly get phased out in favour of Linux or Windows boxes. Still, some of them will likely remain chugging along for years to come, because their performance will simply be sufficient for the task at hand.
I can well imagining HP milking existing HP-UX customers for all they're worth, but I'm finding it hard to justify spending much $$$ to develop it. So I would expect HPE to provide security patches and nothing more.
Yeah but those versions have long been unmaintained. All modern HPUX code and third party apps are itanium only.
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
> In 2003, AMD launched their 64-bit, but Pentium-compatible, Opteron CPU. Everyone stopped buying Intel CPUs for a while. Within a few years Intel made their own 64-bit, but AMD-compatible, CPUs to avoid entirely losing the desktop and small server market. They were right earlier: almost everyone immediately embraced AMD's instruction set and no one but HP wanted anything to do with Itanium.
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.
History may have unrolled quite differently at that point, if the only choice was to shift architecture, then we may have seen a more diverse server CPU estate being maintained. At that point Sun were still relevant, POWER systems were still being bought and deployed in larger proportions etc.
True, but Apple were running Macbooks on power back then I think. I know windows was even more dominant then than it is now so perhaps large numbers of powerbooks was never on the cards.
But in the server space the story might have been different.
I take it intel were planning "Mobile Itanium" at some point?
On those days Apple market share was still of a company struggling to get out of insolvency, and they never had any significant market share outside North America during the last century.
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.
Not to mention AMD was in the business when IBM mandated second/backup supply source to Intel, and that's how AMD began producing x86 chips like Intel.
Gentoo also has instructions. Linux/ia64 works fine for the most part, it's not an architecture that causes much drama for userspace applications.
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...
That's because not everyone is always running bleeding-edge kernels.
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).
Minor historical footnote: HP paid Progeny (Ian Murdock's company he founded years after creating Debian) to help port Debian packages to Itanium. They gave us a first-generation computer, which was epically slow of course.
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.
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.
There was that time a bunch of Silicon Valley engineers went and fixed the healthcare.gov (Obamacare) site for the US govt after the original contractors did a terrible job. But then the first team were already contractors, so maybe the lesson there is, if your first external consultants don't work, just keep bringing in more?
Yes, it works when your best people get tired of middle management interference and quit to form a consultancy that upper management eventually hire in desperation.
Some of the best anecdotes on HN are of the genre "company brought me back as a consultant for a multiple of what I made as an employee when they realized their mistake."
Loads, but successful consulting engagements don't lead to headlines. Source: 25 years as a consultant with many successful customer projects under my belt and zero that landed my name in the press.
Totally agree with this. External consultants are easily blamed. But the problem usually lies elsewhere - someone makes a decision without understanding the full scope of the challenge.
Selection bias. The bad cases are the ones you hear about --- lawsuits and politicking (office or government) resulting in airing grievances to the press.
Yes, this. I've never seen a "crisis averted by timely application of consultants!" post on Medium, but I'm sure many such tales exist, as I'm one of those consultants.
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.
This: 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.
It’s funny, I remember many such projects back when my title was “systems engineer”. I swear the appeal was always that company could spend $$ and get a working solution. It after all makes sense that a growing business would need more hardware. But the problem usually was a few terrible queries.
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.
> 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.
Kind of curious why the article didn't mention HPs PARISC architecture. IIRC, HP switched away from PARISC to Itanium at the time. I guess because they saw that managing your own architecture comes at a huge cost? I very well remember how Itanium was heavily promoted by HP to existing PARISC customers as the natural upgrade path and how they played down x86 as unreliable PC derived stuff that no-one should put in a datacenter ;)
> Goodbye, Itanic. You were a strange, unloved little detour, better known for the good designs you killed than for any successes of your own. Few will miss you.
It does, albeit indirectly, and not by name. Poor Alpha and PA-RISC...
HP concluded PA-RISC (and all RISC, really) had reached a plateau. Wikipedia explains it well:
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]
The only place I ever worked with Itanium was an HP shop. They wrote their custom accounting/booking program in the 90's using Pick/BASIC.
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.
> In 1994, Intel and HP looked around and saw a wide variety of successful server CPU architectures like Alpha, MIPS, SPARC, and POWER. This annoyed them and they decided to make a new CPU that no one would want to use.
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.
I'm pretty surprised to hear "MegaBank" ran AMD. Not that Opteron wasn't awesome and better than what Intel had at most things, at least until Woodcrest if not Nehalem. But because MegaBanks are usually pretty conservative. More than a few still run mainframes and proprietary unixes.
We wrote quant code that had to run on all architectures... for the HFT team [1], unfortunately, including a long drawn out debacle supporting Solaris 5.7 for an absurdly long time. Other members of my team were looking at IBM architectures as well, mostly because IBM were throwing money at us to use their kit.
[1] high frequency, not necessarily low latency, for some defintion of the word 'high'.
>> Intel lost a lot by playing games rather than letting engineers build the best stuff they could and cash out checks on it.
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.
I have worked for Intel sometime later, when they stopped being so elitist and actually started overdoing it in the other direction -- building everything else and the kitchen sink rather than focusing on their core competency.
I would like the suggest the Itanium was a huge business success. At the start of the 90s, there were many decent workstation CPUs: SPARC, MIPS, PowerPC, Alpha, and PA-RISC. Intel CPUs were not considered in the same class. Big engineering work was done on workstations powered by these chips. But as the decade went on, the chips became vastly more complex and expensive to design. Near the middle of the decade, it was becoming clear what the trajectory was and companies started looking around trying to figure out how to navigate this. On top of this problem, Intel/HP teamed up to design a processor that was quite beyond (in terms of complexity) anything being designed at the time and it became clear competing was just not economically feasible. So basically the industry folded. In one move, Intel took out entire industry of companies that could compete. PowerPC is still there, but is marginal. SPARC, PA-RISC, MIPS, and Alpha design teams are gone.
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.
True, but the other side of the coin is that the massive economics of scale in chip manufacturing as well as around ISA ecosystems (software) meant that some massive consolidation of the industry was all but inevitable.
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).
No question there are a lot of ways to win, probably many better than what transpired. But in the end, Itanium played a big role in Intel consolidating the CPU market and taking complete control for a significant period of time.
Alpha was DEC, HP had PA-RISC. I had a PA-RISC in my office and had to have facilities come and adjust air conditioning airflow because the computer put off so much heat.
Not all of them did. I have a 712 PA-RISC workstation and its CPU is passively cooled with a spring loaded tiny cooling block. They didn't even bother to use paste.
I had a PA-RISC workstation too. No heat problems, but it wasn't particularly fast. But the "superdomes" (Refigerator sized computer in the very cold and loud server room....).
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...)
Your causality doesn't seem to line up. As you tell it, the workstation CPUs were already peaking in terms of complexity and cost, when Intel and HP announce a huge investment in the next generation of this class of CPU.
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.
Nothing about this history lines up with facts. Intel killed the RISC workstation CPUs with the Pentium Pro, not with the Itanium. PRO/Engineer and SolidWorks had been ported to Windows NT at the very beginning of that operating system's availability, and the performance on x86 was already better than RISC workstations, at a tiny fraction of the cost, by late 1995.
The Pentium Pro and eventually the AMD64 chips equalled or bested the workstations on many tasks by the end of the 90's and early 2000s. But the Itanium processor distracted them from even competing. SGI for example had at least one high-end MIPS processor under development (iirc "the beast") and they stopped the project and later were trying to ship Itanium servers. HP threw the towel in and joined forces with Intel.
Here is an article from 1999 on Sun booting SunOS on Itanium:
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.
The Itanium wasn't just designed as a workstation CPU it was designed to be superior to existing high-end systems and then over time with volume be the eventual x86 replacement. The business case for itanium didn't work as a workstation cpu.
>>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.
FWIW, both New Coke and Coke "Classic" (aka new coke 1.1) both use high fructose corn syrup, which is substantially cheaper in the USA in industrial quantities due to huge tax-funded agricultural subsidies for corn (maize) farmers. These remain in place today (which is why everything in the US is sweetened with corn syrup instead of sugar).
"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.
When I first moved to USA from Denmark, back in the late 90s, the chemical, sickly syrupy taste of Coca Cola made me gag and I was very surprised in terms of how different it was from the European version. Then I found out that in Europe, they use sugar rather than corn syrup. It's amazing what the Americans will put up with.
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.
Thomas' knowledge-dropping in a sibling comment is more in depth, but anecdotally: I prefer sugar coke after drinking HFCS coke in the USA for a few months, then prefer HFCS coke after drinking sugar coke in europe for a few months.
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.
New Coke is a great example of design biases. Pepsi in the 80s was beating Coke year after year in 80s double blind taste tests of 2oz or so sample pours. Pepsi was hugely proud of this and it was a big part of their advertising.
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.
The article makes it sound like Itanium was some genius move on Intel's part to kill off the old workstation market, but IMHO that's exactly the opposite. This was Intel spending god knows how much money to jump into the workstation market right as it was suffering its final death throes from fatal wounding it took from the PC clone market.
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.
I follow your line of reasoning, but I think AMD had a much bigger role in killing off the various RISC architectures.
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.
Itanium was a huge business success for anything AMD64. I think IA64 was too early and targeted the wrong market too be a success of its own. Also being a single source ISA is very unattractive. If the ISA had been open like RISC-V, and the target market was scale out servers and small computers rather than the nonexistent scale up HPC market and almost nonexistent scale up database market, things could have been very different. On the positive side maybe some open source ISA can emerge using EPIC type architecture now that the proprietary version is dead.
I was at that Stanford lecture! Assuming it was the one that I attended, the Intel engineer was John Crawford, the lead architect of Merced -- and John Hennessy was absolutely annihilating him. I described attending that lecture in a Reddit AMA years ago [0]:
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!
Surely -- I have retold it many times over the years. And we're working on On the Metal! A combination of pandemic/resurgence + us being (very) heads down has delayed us, but stay tuned!
That sounds like the lecture I was at. Thanks for sharing that, fun times. There were some really great lectures back then. I remember when Exponential gave their talk right after Apple moved away from the PowerPC architecture. Everyone knew their processor was a dud in every commercial way (super high-power BiCMOS PowerPC chip), but almost felt sorry for the guy and were amazingly polite.
Might be a case of sunk cost fallacy. The article mentions that while vendors were asking for 64 bit, they didn't want to cannibalize Itanium, but were forced to anyway when AMD came out with their 64 bit pentium compatible CPU.
The competing unix manufacturers didn't need Itanium as an excuse to fold; they were completely non-competitive by the time the itanium came around. Customers didn't purchase a unix system because of the performance of the proprietary architecture but the entire ecosystem provided by manufacturers. DEC and its Alpha was on life support even though it was marginally more competitive against x86 precisely for this reason.
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.
> 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.
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.
I don’t know if it’s true, but a story I was told by an HP engineer claims that Itanium was more or less designed by HP. Which would mean that HP wanted to kill off the PA-RISC platform.
The grand plan of VLIW might not have worked out anyway, but I always wondered what would have happened, if Intel had moved the Itanic to current process nodes, even without huge modifications. By the transistor count, it could probably be power-efficient enough to drive mobile phones.
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.
Everybody here seems to be focusing on the negatives, but there's also a few positive legacies from the Itanium architecture, all of them on the software side: EFI which became UEFI (like it or not, it's still better than the legacy BIOS), the GPT partition table format, and the C++ ABI now used for all architectures on Linux.
I’ve seen it mentioned over the years that writing the necessary compilers was more than merely difficult. As I understood it, the dynamic nature of load latencies (hit L1 cache? L2? L3? Slow trip to DRAM?) means that some workloads just can’t be statically scheduled in an effective manner. Anything to that?
Essentially yes. In cases where memory latency is predictable like DSP workloads then VLIW processors actually tend to work really well. Itanium had some facilities to allow speculative loads but they had a lot of overhead in practice.
Given that we have magic compilers that convert mostly sequential CUDA into highly parallel SIMD assembly code, I don't think that the Itanium concept was too far off.
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.
247 comments
[ 7.8 ms ] story [ 409 ms ] threadI 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])
[1] https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html
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.
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.)
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
https://en.wikipedia.org/wiki/I2O
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.
https://segaretro.org/Sega_Model_2
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.
[0] https://en.wikipedia.org/wiki/Datapoint_2200
> 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...
http://venge.net/graydon/talks/CompilerTalk-2019.pdf
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.
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, ...
And as with Intel, it just wasn't enough.
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.
(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.
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
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.
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.
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.
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]
(https://en.wikipedia.org/wiki/Itanium)
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.
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'.
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.
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.
https://www.reuters.com/legal/transactional/oracle-loses-bid...
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.
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.