I mean if you're talking about ISAs, at the lowend something other than x86 (with x86 compatibility driven by WoA style hybrid emulation) would be possible. But for performance sensitive applications, I doubt Intel will sell anything new without an x86 frontend any time soon.
Well, you mean truly general-purpose. Because, their Xe GPU will certainly *not* use x86, nor do the chips they acquired from MobileEye, Nervana, or Movidius. Those are all performance-sensitive, but more specialized.
I still think we *could* still see Intel step past x86. What'll need to happen, first, is for ARM or RISC V to displace a significant amount of their cloud/datacenter marketshare. Perhaps ARM eating their laptop market would also spur them to react.
Itanium wasn't VLIW. It was superscalar with dependencies explicitly specified at the ISA level. In a VLIW, a bundle is an ISA atom; in Itanium, bundles were primarily a frontend distinction (you could have dependencies within a bundle) and a separate concept called "groups" existed for parallel groupings (which could span multiple bundles.)
It was more recently used GPUs and DSPs. AMD dropped it from their GPUs in 2011, with the introduction of GCN. I don't know if any mobile GPUs (still) use it, but you do still find it in DSP cores.
It took so long to sink because HP had no choice but continue bribing Intel to keep the IA64 processors produced. Without HP, it would have sunk a decade ago. And strangely, HP has no real strategy past 2021. They haven't ported HPUX to x86-64. Their roadmap involves "run HPUX in a virtual machine on x86-64"
No, there are others, like AMD's architectures. But Itanium *is* one of the few Spectre-immune chips, as long as the software doesn't itself use speculative loads, or else does so in a secure way. This is because it simply doesn't try to predict in hardware - which is one reason it's slower than x86.
I suspect if Itanium had been more of a success, a lot of that success would still have been built on speculative loads. Of course it might've been easier to fix that way - you could recompile the software, rather than add a firmware hack and software workarounds or buy a new CPU.
Itanium was only 2-way multithreaded, not 4-way, and there's little enough resource sharing that I doubt it is vulnerable to those issues. It's basically just fast context switches (Switch-on-Event Multithreading, Intel calls it), not the aggressively shared core that Intel ships for x86 where you can have multiple threads issuing in the same cycle.
There are a few ARM chips out there that are invulnerable to both Spectre and Meltdown; the Broadcom series used by the Raspberry Pi Foundation for their boards is one:
Anton besides HP-UX, you can also run OpenVMS on many of the a Kittson based Integrity system, although the port to x86_64 is now available to early adopters.
Not only that - these don't just go into Superdomes like the article says. Superdome2's are big many-socket scalable systems with the sx3000 chipset; there are also a number of smaller HPE systems with the Boxboro-MC chipset (rx2800 i6, bl8x0c i6.)
Intel is being efficient and dropping technologies which did not make even though it was ahead of its time. Quark cpu is also one that Intel drop but that is like market is not a fit for Intel CPU's
Look, it's the Intel shill again, spinning whatever Intel does as the best idea since the wheel was invented. Hope you got your shill cheque this week; you're certainly earning it.
Remember how much Intel talked about how great the IPF roadmap was? "Sustainable roadmap for the long-term future"? How do you think those customers feel about Intel "being efficient" at this point?
That's sure Orwellian - dropping a product > 20 years after its introduction being considered "efficient". Don't you ever feel embarrassed for saying such things?
What I would call "efficient" is how quickly they dropped the i860 line (and its unreleased successor). Rumor has it, the successor was quite promising.
So, they'll start selling it again when the time is ready for Itanium? In the year 2050 maybe? No one supports it, no one wants it, that's why they're not selling it. Unbelievable reasoning though lol.
EPIC/Itanium were never ahead of any time. It is a very simple micro-architecture. Hugely parallel but no intelligence like out-of-order. The REAL reason Intel was developing EPIC (and it was mostly HP to be fair) was they needed an architecture that was not licensed to AMD. The AMD cross-license deal, still to this day, is what bothers Intel most.
No out-of-order execution was one of its selling points. The idea being that you could spend your transistor budget on execution units that do actual work, instead of scheduling logic (which, to a large extent, can be done by compilers).
Unlike true VLIW, EPIC requires some scheduling. But true VLIW code needs to be recompiled for each new generation, whereas EPIC does not.
The real credit for killing Itanium is AMD when they brought 64 Bit to X86 the IA64 architecture was dead. Intel planned to bring the IA64 to the desktop market but with x64 there was no way people would give up the backward compatibility.
I'm not sure there was a single cause for IA64's failure. My favorite scapegoat was Intel's IP lawyers. They patented every aspect of that ISA, to the point that no potential exists for there ever to be a clone. This made too many potential adopters wary of locking them into a single CPU supplier.
But I agree with your point - Intel originally tried to hold back 64-bit from x86, using it as a lever to force broader adoption of IA64. The combination of IA64's high prices, low (x86) performance, and the availability fast AMD chips with 64-bit addressing was a headwind IA64 couldn't hope to counter.
Agreed with the above. Intel boxed themselves in right from the start, arguably sacrificing the potential of the product to their own profit margins and market segmentation requirements.
All due credit to AMD for exploiting those weaknesses when they were able, but Intel really did leave that opportunity on the table for them.
What I heard is IA64 was extremely advance - it supposedly had reloadable microcode which Intel got from Dec Alpha. It is possible this technology was migrated into x86 processors.
I remember the early days 64 bit x86 and supposedly Intel had a 64 bit version before AMD. But they probably did want 64 bit to be adapter to IA64 and the primary issue in my IA64 is not adapted because there is too much software on x86 platforms and even a decade later this problem can be still observed. This can be seen with the failure of Windows for ARM (Qualcomm). Things are different now than a decade ago (a little more) because during the 32bit days 4G of memory was a huge amount of memory and even today there are some systems with only 4G or less memory. For example BestBuy has 243 laptops with 4G and 13 with 2G
I don't believe AMD had credit for down fall of IA64. Yes a decade later 64 bit is important in x86 market but what really killed IA64 was the fact no one was willing to switch software to platform from Xeon processor line which over the decade as improved both in memory and performance make IA64
Keep in mind, I not saying that 64 bit on x86 did not contributive to IA64 downfall - in ways it did but Intel Xeon is primary reason. I would expect in last decade or so, Intel Xeon line would have gone 64 bit anyway. AMD just speeded it up.
I go back and forth about this. On one hand, Itanium was developed using assumptions about the future of computing that turned out not to be true, and so it might have died off, since I don't think Intel's plan from the late 90s (that eventually, 64-bit Itanium would move downmarket and kill off x86) would have really happened. So without AMD under that version of history, Itanium never makes it below expensive workstations, and eventually, Intel has to relent and come up with a way of addressing more than 4GB of memory on x86, but it might happen some time later.
On the other hand, corporate mergers had killed off most of Intel's competition from other architectures: HP and Intel jointly developed Itanium, so HP made sure PA-RISC wasn't going to be a direct competitor, and, by luck, HP also found itself in charge of Alpha (through their purchase of Compaq who'd purchased DEC), and killed it off in favor of Itanium. PowerPC might have been an option, but I'm not sure what the terms were of IBM and Apple's agreement, particularly with the PowerPC 970 (G5) series.
So in that version of non-AMD history, Intel (actually, HP) effectively controlled the market, and Intel could have pushed Itanium exclusively, killing Xeon off and eventually forcing Itanium on prosumers then consumers (and giving Microsoft and others time to figure out how to handle the x86-Itanium transition - possibly by forcing x86 to 'legacy' status and waiting until Itanium was fast enough to emulate x86-32 in software at a reasonable speed). I guess it's possible customers, particularly those who were using UNIX anyways, COULD have migrated en masse to PowerPC on Apple's OS X server, which would have radically changed the course of Apple's history, but I doubt it.
I don't believe even without AMD picture Itanium would kill off x86 could even if 64 bit was in the picture. The problem is convincing customers or more precisely convert software to IA64. I been at my job for 9 years and previous job was related for 14 and it is still 32bit x86 ( MFC and now with .net integrated ) Server environments would be different.
Just for information, this announcement does not mean Itanium is dead - just Itanium 9300 - not the 9700 and not sure about 9500?
Uh, yeah, it does. They have a picture of the 9300 on there (probably because that's what they have as a sample - successors only really mattered to those who had them already), but the news is about the 9700. Intel said the 9700 would be the last Intel Itanium processor back in May 2017: https://itpeernetwork.intel.com/evolution-mission-... "Although the 9700 series will be the last Intel Itanium processor, our OEM partners will continue to deliver system- and software-level innovation and support for Intel Itanium processor family users, as they weigh the benefits of business continuity with their longer term mission critical strategy."
Basically they're getting out, if HP wants to continue making servers with it that's their business but they'd better snap them up quick because the bell has tolled for last orders from Intel.
One thing this does not mean Itanium is gone, Intel still has 9700 series but with Microsoft dropping support in Windows it is pretty much end of life. I don't see why someone needs one when they can get Xeons.
It does mean Itanium is gone. That's what this article is about. In a year, no more 9700 orders.
And until Xeon can run the full set of Itanium operating systems, this affects customers. NSK has been ported; VMS and GCOS 8 have announced ports, but neither are shipping on Xeon today AFAICT; HP-UX, likely the largest installed base of all of them, has no announced port, just a vague "we'll provide some kind of migration path to Linux."
It has been a very long time since I heard anything about the IA64 platform. Like other have said Intel probably hoped that at some point IA64 would be adopted into the desktop platform in some shape or form so they could become the main supplier of CPU's down the road. AMD released x64 before Intel was able to switch in some sort of IA64 onto the desktop market.
My theory is if AMD was not able to get x64 out first and because Intel had locked down the IA64 to the point nobody could clone it like x86 that right now AMD would not be making CPU's or at least would be a much smaller player in the market. Just just look at what Intel did to Nvidia back in the day when they pulled Nvidia's chipset license which disallowed Nvidia from making any Intel based chipset and that was just from Nvidia's license running out and they could not get it renewed by Intel.
No intel did not pull nvidia's license, they changed their chipset interface, from the Front Side Bus (FSB), which had been licensed to many companies (SIS, VIA, ATI, Nvidia...) to QPI in the Core iX processors. Intel has not licensed QPI to anybody, which explains why there is no 3rd party chipset anymore.
It was not AMD that did - more likely advancements in Xeon's I am sure Intel is using some of advancements in Itanium to advance x86 processors especially Xeons. By way only 9300 is discontinued.
Nope. It was AMD that killed this by producing a 64-bit extension to x86 architecture. Originally, Intel had no intention for making Xeon or other x86 processor 64-bit. They were forced to do it only to respond to AMD. And at that point IA64 became a toast. Not only with pretty much ordinary performance, but also not binary compatible with x86.
Eh, not really. I spent a lot of years working at a very intimate level with IPF, and while there were a lot of things I liked, they were almost all uarch, not ISA.
The good: +Ridiculously fast caches. Single-cycle L1, large and fast L2 and L3. +Four load-store units. Meant that you could keep a LOT of memory throughput going. Doesn't apply to Poulson or Merced though. +Two large, fast FMA units. Paired with the above, meant some linear algebra code performed very well. +Speculative loads - software-controlled speculation that didn't entirely suck.
The bad: -Code density was absolutely atrocious. Best case, assuming no NOP padding (ie, favorable templates for your code stream) was 128 bits for three ops. That's also assuming you don't use the extended form (82 bits IIRC) that took up two slots in your instruction word. -Advanced loads never worked well and had strange side effects. This is *not* software speculation done right. -L1 miss rate was always high IME, both on I and D side. I've assumed there was a trade-off made here that resulted in the undersized 2-way L1 that was accessible in one cycle. -Intel never seems to have felt SIMD beyond MMX equivalence was necessary. There were technical-compute apps that would have benefited from it. -Intel never seems to have taken multithreading seriously. The switch-on-event multithreading in Montecito and up offered tiny gains IME, and at least one OEM (SGI) didn't bother supporting it at all. Even FGMT would have been a welcome improvement. -I feel like there was a tendency in the IPF design to jump to whizz-bang features that didn't offer much in real code - RSE comes to mind.
In summary, I had a lot of fun working with Itanium. It had a million dials and switches that appealed to me as a programmer. But in-order cores have progressively looked more and more like the way forward, and IPF was never consistently good enough to disprove that.
I meant out-of-order was the future. Embarrassing typo. I held onto the "maybe this EPIC thing can work out!" gospel up until Power7 came out, but after that, it was pretty clear where the future was going.
There was very basic FP SIMD, but IIRC only paired single-precision ops on existing registers. I suspect that 128b SIMD would have been seen as heretical by the original IPF design group - remember that Multiflow had NO VECTORS coffee mugs! That being said, it wasn't really an outlier - the other RISC/UNIX players were all pretty late to the SIMD party. SPARC never got a world-class vector extension until Fujitsu's HPC-ACE, and while IBM had VMX in its pocket for years, Power6 was the first mainline Power core to ship it (and VMX performance was decidedly underwhelming on P6; P7 improved it greatly.)
RSE was the Register Stack Engine. The idea was that registers would automatically fill/spill to backing store across function calls in a way that was mostly transparent to the application.
Switch-on-event was indeed long-running events. IIRC the main things were either a software-invoked switch hint or an L3 miss. It took something like 15 cycles to do a complete thread switch (pipeline flush of thread 1 + time for ops from thread 2 to fill the pipeline) on Montecito/Tukwila. Per my recollection, Poulson knocked a couple cycles off SoEMT thread switch times (as well as doing some funky stuff with how it was implemented internally), but it was still several.
Yeah, 2-way L1 was pretty painful. It was offset a little bit by the fact that - especially after Montecito shipped - the L2 was fast (7 cyc L2I, 5-6 cyc L2D IIRC) and *very* large, but the hit rate for L1I and L1D was fairly embarrassing, especially on code with less-than-perfectly-regular memory access patterns.
A quick look at the reference manual indicates I misremembered and the L1 was actually 4-way. Still 16+16, though, and my point about hit rates being decidedly mediocre stands.
How do you get a bad hit rate? Did it have a poor eviction policy? Or maybe it tried to do some fancy prefetching that burned through cache too quickly?
How big were the cachelines? Perhaps too small + no hardware prefetching could've caused a lot of misses.
L1I miss rate was bad due to a combination of being only 16KB and Itanium ops being enormous (as mentioned above, best-case 3 ops in 128 bits; frequently worse in real code.)
Fancy prefetching is almost entirely absent on Itanium, but there are several software-controlled solutions (cache-control ops, speculative loads [which load a NaT value instead of generating exception if they fail], and advanced loads [loads into a buffer called the ALAT, which then gets checked at load time, resulting in either picking up the value or failing to and initiating a new non-advanced load.])
So, did RSE keep a dirty bit for each register? I thought a cool way to solve the caller-save vs. callee-save debate would be to save the intersection (logical AND) of the registers modified by the caller vs. the registers the callee would modify. The dirty mask could then be updated by zeroing those registers that had been saved, for the sake of functions called by the callee.
Nopes. Itanium was bought pretty much only by HP, who ported its enterprise HPUX OS to IA64 and discontinued the PA-RISC architecture. Intel would have discontinued IA64 a decade ago if it wasn't bribed by HP.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
63 Comments
Back to Article
SarahKerrigan - Thursday, January 31, 2019 - link
I had front row seats for much of this long, strange saga. I miss IPF, despite its flaws - and it had many of them.mlkj - Thursday, January 31, 2019 - link
That boat sure took a long time to sink. I wonder if we'll see another big VLIW attempt in the future?boozed - Thursday, January 31, 2019 - link
The good ship Itanic finally slips below the waves.And after this boondoggle of an experiment, I doubt it!
Alexvrb - Thursday, January 31, 2019 - link
I mean if you're talking about ISAs, at the lowend something other than x86 (with x86 compatibility driven by WoA style hybrid emulation) would be possible. But for performance sensitive applications, I doubt Intel will sell anything new without an x86 frontend any time soon.mode_13h - Friday, February 1, 2019 - link
Well, you mean truly general-purpose. Because, their Xe GPU will certainly *not* use x86, nor do the chips they acquired from MobileEye, Nervana, or Movidius. Those are all performance-sensitive, but more specialized.I still think we *could* still see Intel step past x86. What'll need to happen, first, is for ARM or RISC V to displace a significant amount of their cloud/datacenter marketshare. Perhaps ARM eating their laptop market would also spur them to react.
SarahKerrigan - Thursday, January 31, 2019 - link
Itanium wasn't VLIW. It was superscalar with dependencies explicitly specified at the ISA level. In a VLIW, a bundle is an ISA atom; in Itanium, bundles were primarily a frontend distinction (you could have dependencies within a bundle) and a separate concept called "groups" existed for parallel groupings (which could span multiple bundles.)mode_13h - Friday, February 1, 2019 - link
Yeah, I think "EPIC" was specifically coined to distinguish it from VLIW. But the similarities are definitely there.Both do data dependency analysis only at compile-time. The difference is that EPIC still has runtime scheduling, while VLIW does not.
mode_13h - Friday, February 1, 2019 - link
It was more recently used GPUs and DSPs. AMD dropped it from their GPUs in 2011, with the introduction of GCN. I don't know if any mobile GPUs (still) use it, but you do still find it in DSP cores.Manch - Friday, February 1, 2019 - link
Imagination GPU's use it I think. At least they did.UtilityMax - Friday, May 24, 2019 - link
It took so long to sink because HP had no choice but continue bribing Intel to keep the IA64 processors produced. Without HP, it would have sunk a decade ago. And strangely, HP has no real strategy past 2021. They haven't ported HPUX to x86-64. Their roadmap involves "run HPUX in a virtual machine on x86-64"SH3200 - Thursday, January 31, 2019 - link
isnt itanium the only meltdown immune chip in existence ?GreenReaper - Thursday, January 31, 2019 - link
No, there are others, like AMD's architectures. But Itanium *is* one of the few Spectre-immune chips, as long as the software doesn't itself use speculative loads, or else does so in a secure way. This is because it simply doesn't try to predict in hardware - which is one reason it's slower than x86.I suspect if Itanium had been more of a success, a lot of that success would still have been built on speculative loads. Of course it might've been easier to fix that way - you could recompile the software, rather than add a firmware hack and software workarounds or buy a new CPU.
Krysto - Friday, February 1, 2019 - link
Likely not immune to the two HT bugs found last year, though. Considering Itanium was 4-way HT, that one was probably a big issue, too.Oxford Guy - Saturday, February 2, 2019 - link
"Likely not immune to the two HT bugs made public last year, though."SarahKerrigan - Saturday, February 2, 2019 - link
Itanium was only 2-way multithreaded, not 4-way, and there's little enough resource sharing that I doubt it is vulnerable to those issues. It's basically just fast context switches (Switch-on-Event Multithreading, Intel calls it), not the aggressively shared core that Intel ships for x86 where you can have multiple threads issuing in the same cycle.kaidenshi - Friday, February 1, 2019 - link
There are a few ARM chips out there that are invulnerable to both Spectre and Meltdown; the Broadcom series used by the Raspberry Pi Foundation for their boards is one:https://www.raspberrypi.org/blog/why-raspberry-pi-...
RU482 - Monday, February 4, 2019 - link
security through obscurity?ilt24 - Thursday, January 31, 2019 - link
Anton besides HP-UX, you can also run OpenVMS on many of the a Kittson based Integrity system, although the port to x86_64 is now available to early adopters.see: http://www.openvms.org/node/116e
SarahKerrigan - Thursday, January 31, 2019 - link
Not only that - these don't just go into Superdomes like the article says. Superdome2's are big many-socket scalable systems with the sx3000 chipset; there are also a number of smaller HPE systems with the Boxboro-MC chipset (rx2800 i6, bl8x0c i6.)HStewart - Thursday, January 31, 2019 - link
Intel is being efficient and dropping technologies which did not make even though it was ahead of its time. Quark cpu is also one that Intel drop but that is like market is not a fit for Intel CPU'sLord of the Bored - Thursday, January 31, 2019 - link
Intel discontinues products that hey can't sell, just like everyone else. Also products they don't WANT to sell.sa666666 - Thursday, January 31, 2019 - link
Look, it's the Intel shill again, spinning whatever Intel does as the best idea since the wheel was invented. Hope you got your shill cheque this week; you're certainly earning it.WasHopingForAnHonestReview - Saturday, February 2, 2019 - link
Its like reading reddit comments. Everyone is shilling something.SarahKerrigan - Thursday, January 31, 2019 - link
Remember how much Intel talked about how great the IPF roadmap was? "Sustainable roadmap for the long-term future"? How do you think those customers feel about Intel "being efficient" at this point?mode_13h - Friday, February 1, 2019 - link
That's sure Orwellian - dropping a product > 20 years after its introduction being considered "efficient". Don't you ever feel embarrassed for saying such things?What I would call "efficient" is how quickly they dropped the i860 line (and its unreleased successor). Rumor has it, the successor was quite promising.
Teckk - Friday, February 1, 2019 - link
So, they'll start selling it again when the time is ready for Itanium? In the year 2050 maybe? No one supports it, no one wants it, that's why they're not selling it. Unbelievable reasoning though lol.Manch - Friday, February 1, 2019 - link
LOL, good lord...jjjag - Friday, February 1, 2019 - link
EPIC/Itanium were never ahead of any time. It is a very simple micro-architecture. Hugely parallel but no intelligence like out-of-order. The REAL reason Intel was developing EPIC (and it was mostly HP to be fair) was they needed an architecture that was not licensed to AMD. The AMD cross-license deal, still to this day, is what bothers Intel most.mode_13h - Sunday, February 3, 2019 - link
No out-of-order execution was one of its selling points. The idea being that you could spend your transistor budget on execution units that do actual work, instead of scheduling logic (which, to a large extent, can be done by compilers).Unlike true VLIW, EPIC requires some scheduling. But true VLIW code needs to be recompiled for each new generation, whereas EPIC does not.
AlyxSharkBite - Friday, February 1, 2019 - link
The real credit for killing Itanium is AMD when they brought 64 Bit to X86 the IA64 architecture was dead. Intel planned to bring the IA64 to the desktop market but with x64 there was no way people would give up the backward compatibility.mode_13h - Friday, February 1, 2019 - link
I'm not sure there was a single cause for IA64's failure. My favorite scapegoat was Intel's IP lawyers. They patented every aspect of that ISA, to the point that no potential exists for there ever to be a clone. This made too many potential adopters wary of locking them into a single CPU supplier.But I agree with your point - Intel originally tried to hold back 64-bit from x86, using it as a lever to force broader adoption of IA64. The combination of IA64's high prices, low (x86) performance, and the availability fast AMD chips with 64-bit addressing was a headwind IA64 couldn't hope to counter.
Spunjji - Friday, February 1, 2019 - link
Agreed with the above. Intel boxed themselves in right from the start, arguably sacrificing the potential of the product to their own profit margins and market segmentation requirements.All due credit to AMD for exploiting those weaknesses when they were able, but Intel really did leave that opportunity on the table for them.
HStewart - Friday, February 1, 2019 - link
What I heard is IA64 was extremely advance - it supposedly had reloadable microcode which Intel got from Dec Alpha. It is possible this technology was migrated into x86 processors.I remember the early days 64 bit x86 and supposedly Intel had a 64 bit version before AMD. But they probably did want 64 bit to be adapter to IA64 and the primary issue in my IA64 is not adapted because there is too much software on x86 platforms and even a decade later this problem can be still observed. This can be seen with the failure of Windows for ARM (Qualcomm). Things are different now than a decade ago (a little more) because during the 32bit days 4G of memory was a huge amount of memory and even today there are some systems with only 4G or less memory. For example BestBuy has 243 laptops with 4G and 13 with 2G
mode_13h - Sunday, February 3, 2019 - link
Didn't Itanium have a hardware x86 translater? Even so, recall it being quite slow.SarahKerrigan - Sunday, February 3, 2019 - link
Only pre-Montecito. The software emulators later were much improved (1.6GHz I2 being able to more or less match 1.6GHz Pentium4 on SPEC-type code.)HStewart - Friday, February 1, 2019 - link
I don't believe AMD had credit for down fall of IA64. Yes a decade later 64 bit is important in x86 market but what really killed IA64 was the fact no one was willing to switch software to platform from Xeon processor line which over the decade as improved both in memory and performance make IA64HStewart - Friday, February 1, 2019 - link
Keep in mind, I not saying that 64 bit on x86 did not contributive to IA64 downfall - in ways it did but Intel Xeon is primary reason. I would expect in last decade or so, Intel Xeon line would have gone 64 bit anyway. AMD just speeded it up.sing_electric - Friday, February 1, 2019 - link
I go back and forth about this. On one hand, Itanium was developed using assumptions about the future of computing that turned out not to be true, and so it might have died off, since I don't think Intel's plan from the late 90s (that eventually, 64-bit Itanium would move downmarket and kill off x86) would have really happened. So without AMD under that version of history, Itanium never makes it below expensive workstations, and eventually, Intel has to relent and come up with a way of addressing more than 4GB of memory on x86, but it might happen some time later.On the other hand, corporate mergers had killed off most of Intel's competition from other architectures: HP and Intel jointly developed Itanium, so HP made sure PA-RISC wasn't going to be a direct competitor, and, by luck, HP also found itself in charge of Alpha (through their purchase of Compaq who'd purchased DEC), and killed it off in favor of Itanium. PowerPC might have been an option, but I'm not sure what the terms were of IBM and Apple's agreement, particularly with the PowerPC 970 (G5) series.
So in that version of non-AMD history, Intel (actually, HP) effectively controlled the market, and Intel could have pushed Itanium exclusively, killing Xeon off and eventually forcing Itanium on prosumers then consumers (and giving Microsoft and others time to figure out how to handle the x86-Itanium transition - possibly by forcing x86 to 'legacy' status and waiting until Itanium was fast enough to emulate x86-32 in software at a reasonable speed). I guess it's possible customers, particularly those who were using UNIX anyways, COULD have migrated en masse to PowerPC on Apple's OS X server, which would have radically changed the course of Apple's history, but I doubt it.
HStewart - Friday, February 1, 2019 - link
I don't believe even without AMD picture Itanium would kill off x86 could even if 64 bit was in the picture. The problem is convincing customers or more precisely convert software to IA64. I been at my job for 9 years and previous job was related for 14 and it is still 32bit x86 ( MFC and now with .net integrated ) Server environments would be different.Just for information, this announcement does not mean Itanium is dead - just Itanium 9300 - not the 9700 and not sure about 9500?
GreenReaper - Friday, February 1, 2019 - link
Uh, yeah, it does. They have a picture of the 9300 on there (probably because that's what they have as a sample - successors only really mattered to those who had them already), but the news is about the 9700. Intel said the 9700 would be the last Intel Itanium processor back in May 2017:https://itpeernetwork.intel.com/evolution-mission-...
"Although the 9700 series will be the last Intel Itanium processor, our OEM partners will continue to deliver system- and software-level innovation and support for Intel Itanium processor family users, as they weigh the benefits of business continuity with their longer term mission critical strategy."
Basically they're getting out, if HP wants to continue making servers with it that's their business but they'd better snap them up quick because the bell has tolled for last orders from Intel.
mode_13h - Sunday, February 3, 2019 - link
PowerPC ran Linux for a long time - odd that you'd assume UNIX people would all go to Apple. Also, you forgot about SPARC and MIPS.HStewart - Friday, February 1, 2019 - link
One thing this does not mean Itanium is gone, Intel still has 9700 series but with Microsoft dropping support in Windows it is pretty much end of life. I don't see why someone needs one when they can get Xeons.SarahKerrigan - Friday, February 1, 2019 - link
It does mean Itanium is gone. That's what this article is about. In a year, no more 9700 orders.And until Xeon can run the full set of Itanium operating systems, this affects customers. NSK has been ported; VMS and GCOS 8 have announced ports, but neither are shipping on Xeon today AFAICT; HP-UX, likely the largest installed base of all of them, has no announced port, just a vague "we'll provide some kind of migration path to Linux."
UtilityMax - Friday, May 24, 2019 - link
Microsoft support is irrelevant. The main customers for HP IA64 hardware are HPUX users. HP has no plan to port HPUX to x86-64 btw.rocky12345 - Friday, February 1, 2019 - link
It has been a very long time since I heard anything about the IA64 platform. Like other have said Intel probably hoped that at some point IA64 would be adopted into the desktop platform in some shape or form so they could become the main supplier of CPU's down the road. AMD released x64 before Intel was able to switch in some sort of IA64 onto the desktop market.My theory is if AMD was not able to get x64 out first and because Intel had locked down the IA64 to the point nobody could clone it like x86 that right now AMD would not be making CPU's or at least would be a much smaller player in the market. Just just look at what Intel did to Nvidia back in the day when they pulled Nvidia's chipset license which disallowed Nvidia from making any Intel based chipset and that was just from Nvidia's license running out and they could not get it renewed by Intel.
frenchy_2001 - Friday, February 1, 2019 - link
No intel did not pull nvidia's license, they changed their chipset interface, from the Front Side Bus (FSB), which had been licensed to many companies (SIS, VIA, ATI, Nvidia...) to QPI in the Core iX processors.Intel has not licensed QPI to anybody, which explains why there is no 3rd party chipset anymore.
NuclearArmament - Friday, February 1, 2019 - link
I hate AMD for killing this processor. It truly was the future of computing.HStewart - Friday, February 1, 2019 - link
It was not AMD that did - more likely advancements in Xeon's I am sure Intel is using some of advancements in Itanium to advance x86 processors especially Xeons. By way only 9300 is discontinued.SarahKerrigan - Friday, February 1, 2019 - link
Typical HStewart lies. The PCN Anandtech links to specifically lists the 9700 series as being discontinued.UtilityMax - Friday, May 24, 2019 - link
Nope. It was AMD that killed this by producing a 64-bit extension to x86 architecture. Originally, Intel had no intention for making Xeon or other x86 processor 64-bit. They were forced to do it only to respond to AMD. And at that point IA64 became a toast. Not only with pretty much ordinary performance, but also not binary compatible with x86.SarahKerrigan - Friday, February 1, 2019 - link
Eh, not really. I spent a lot of years working at a very intimate level with IPF, and while there were a lot of things I liked, they were almost all uarch, not ISA.The good:
+Ridiculously fast caches. Single-cycle L1, large and fast L2 and L3.
+Four load-store units. Meant that you could keep a LOT of memory throughput going. Doesn't apply to Poulson or Merced though.
+Two large, fast FMA units. Paired with the above, meant some linear algebra code performed very well.
+Speculative loads - software-controlled speculation that didn't entirely suck.
The bad:
-Code density was absolutely atrocious. Best case, assuming no NOP padding (ie, favorable templates for your code stream) was 128 bits for three ops. That's also assuming you don't use the extended form (82 bits IIRC) that took up two slots in your instruction word.
-Advanced loads never worked well and had strange side effects. This is *not* software speculation done right.
-L1 miss rate was always high IME, both on I and D side. I've assumed there was a trade-off made here that resulted in the undersized 2-way L1 that was accessible in one cycle.
-Intel never seems to have felt SIMD beyond MMX equivalence was necessary. There were technical-compute apps that would have benefited from it.
-Intel never seems to have taken multithreading seriously. The switch-on-event multithreading in Montecito and up offered tiny gains IME, and at least one OEM (SGI) didn't bother supporting it at all. Even FGMT would have been a welcome improvement.
-I feel like there was a tendency in the IPF design to jump to whizz-bang features that didn't offer much in real code - RSE comes to mind.
In summary, I had a lot of fun working with Itanium. It had a million dials and switches that appealed to me as a programmer. But in-order cores have progressively looked more and more like the way forward, and IPF was never consistently good enough to disprove that.
mode_13h - Sunday, February 3, 2019 - link
Only 2-way? Ouch!Lack of FP SIMD sounds like a really bad decision. Perhaps, by the time it became feasible, the writing was already on the wall.
I assume switch-on-event is referring to events like cache-miss?
What's RSE?
Why do you say in-order cores looked like the way forward? Only in GPUs and ultra-low power.
SarahKerrigan - Sunday, February 3, 2019 - link
I meant out-of-order was the future. Embarrassing typo. I held onto the "maybe this EPIC thing can work out!" gospel up until Power7 came out, but after that, it was pretty clear where the future was going.There was very basic FP SIMD, but IIRC only paired single-precision ops on existing registers. I suspect that 128b SIMD would have been seen as heretical by the original IPF design group - remember that Multiflow had NO VECTORS coffee mugs! That being said, it wasn't really an outlier - the other RISC/UNIX players were all pretty late to the SIMD party. SPARC never got a world-class vector extension until Fujitsu's HPC-ACE, and while IBM had VMX in its pocket for years, Power6 was the first mainline Power core to ship it (and VMX performance was decidedly underwhelming on P6; P7 improved it greatly.)
RSE was the Register Stack Engine. The idea was that registers would automatically fill/spill to backing store across function calls in a way that was mostly transparent to the application.
Switch-on-event was indeed long-running events. IIRC the main things were either a software-invoked switch hint or an L3 miss. It took something like 15 cycles to do a complete thread switch (pipeline flush of thread 1 + time for ops from thread 2 to fill the pipeline) on Montecito/Tukwila. Per my recollection, Poulson knocked a couple cycles off SoEMT thread switch times (as well as doing some funky stuff with how it was implemented internally), but it was still several.
Yeah, 2-way L1 was pretty painful. It was offset a little bit by the fact that - especially after Montecito shipped - the L2 was fast (7 cyc L2I, 5-6 cyc L2D IIRC) and *very* large, but the hit rate for L1I and L1D was fairly embarrassing, especially on code with less-than-perfectly-regular memory access patterns.
SarahKerrigan - Sunday, February 3, 2019 - link
A quick look at the reference manual indicates I misremembered and the L1 was actually 4-way. Still 16+16, though, and my point about hit rates being decidedly mediocre stands.mode_13h - Sunday, February 3, 2019 - link
How do you get a bad hit rate? Did it have a poor eviction policy? Or maybe it tried to do some fancy prefetching that burned through cache too quickly?How big were the cachelines? Perhaps too small + no hardware prefetching could've caused a lot of misses.
SarahKerrigan - Sunday, February 3, 2019 - link
L1I miss rate was bad due to a combination of being only 16KB and Itanium ops being enormous (as mentioned above, best-case 3 ops in 128 bits; frequently worse in real code.)Fancy prefetching is almost entirely absent on Itanium, but there are several software-controlled solutions (cache-control ops, speculative loads [which load a NaT value instead of generating exception if they fail], and advanced loads [loads into a buffer called the ALAT, which then gets checked at load time, resulting in either picking up the value or failing to and initiating a new non-advanced load.])
mode_13h - Sunday, February 3, 2019 - link
So, did RSE keep a dirty bit for each register? I thought a cool way to solve the caller-save vs. callee-save debate would be to save the intersection (logical AND) of the registers modified by the caller vs. the registers the callee would modify. The dirty mask could then be updated by zeroing those registers that had been saved, for the sake of functions called by the callee.mode_13h - Sunday, February 3, 2019 - link
It was the future of computing, until the future passed it by. Now, it is the past.The kinds of things it was really good at are easily ported to GPUs. Those are already much faster than any EPIC CPU that could've existed.
WasHopingForAnHonestReview - Saturday, February 2, 2019 - link
But can it run crysis at 60fps 4k?mode_13h - Sunday, February 3, 2019 - link
No.StrangerGuy - Sunday, February 3, 2019 - link
AFAIK, Itanium was mainly bought for their RAS features and performance which ironically had completely nothing to do with the IA-64 ISA.mode_13h - Sunday, February 3, 2019 - link
I thought I recall reading that it was mainly used for running server-side Java apps that needed lots of RAM (hence, 64-bit addressing).UtilityMax - Friday, May 24, 2019 - link
Nopes. Itanium was bought pretty much only by HP, who ported its enterprise HPUX OS to IA64 and discontinued the PA-RISC architecture. Intel would have discontinued IA64 a decade ago if it wasn't bribed by HP.