29 ms·
Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel
- 404mm 3y agoEnd of a short lived era. I deployed last Itanium in 2009 as a replacement of old Alphas. OpenVMS was blazing on IA-64 compared to Alphas lol.
- johnklos 3y agoSo Alpha, m68k and even VAX have outlived Itanic. Poetic.
- jamiek88 3y agoIt's funny thinking back to the hype cycle of Itanium back in the heady days where performance was doubling every year, desktop was king and this was the future. Turns out it was more like IBM's MCA / PS2 rather than the future. Compatibility and ubiquity wins. As nearly always.
- chx 3y ago2009 summary https://www.pcmag.com/article2/0,2817,2339629,00.asp https://www.pcmag.com/article2/0,2817,2339629,00.asp > The failure of this chip to do anything more than exist as a niche processor sealed the fate of Intel—and perhaps the entire industry, since from 1997 to 2001 everyone waited for the messiah of chips to take us all to the next level. > It did that all right. It took us to the next level. But we didn't know that the next level was below us, not above. The next level was the basement, in fact. Hopefully Intel won't come up with any more bright ideas like the Itanium. We can't afford to excavate another level down.
- cubefox 3y agoThis piece sounds like a lot of misrepresentation and exaggeration.
- chx 3y agoWhether the DEC Alpha development stopped because of Merced (as it was called then) or because of the 1997 legal mess https://www.wired.com/1997/10/intel-dec-settle-alpha-chip-dispute/ https://www.wired.com/1997/10/intel-dec-settle-alpha-chip-di... is quite hard to say. The DEC Alpha architecture was planned for 25 years and it certainly was not technical barriers that killed the Alpha 21464.
- jabl 3y agoIn the end it was market forces that did it in. Making new chips was (still is!) exponentially more expensive for each generation, and at the same time mass market chips were getting better and better while they could amortize the NRE costs over zillions of chips sold, eating the market from below. And other RISC competitors (and IA-64) were attacking from the sides. DEC just didn't have the customer base or depth of pockets to fund Alpha development. That it was Itanium that ultimately delivered the coup de grace was but the final insult.
- FullyFunctional 3y agoIn my limited understanding two factors contributed significantly to Alpha failing. Business-wise, DEC and Ken Olesen were stuck in an old minicomputer mentality and wasn't sufficiently able or willing to "let it loose" and let it take over the market with DEC as the CPU supplier. Technically, Alpha development was taking longer and longer and the schedule slips got worse and worse.
- kstrauser 3y agoIf the business end had kept the cash rolling in, do you think the technical side could have kept to schedule?
- GrilledChips 3y agoIt wasn't the technical side that caused the schedule slips. It was constant competition with other aspects of the business, especially the VAX lineup. The VAX 9000 in particular was a $3 billion money pit that didn't make back even 25% of it's development costs and was repeatedly chosen over development of prism and later alpha. Even when it came down to the embarrassingly fast NVAX chip vs the even faster Alhpa, DEC still couldn't get the story straight and lost valuable VAX customers when they could have offered a faster VAX and an upgrade path to Alpha.
- vGPU 3y agoThis reads like it was written by a discount version of chatGPT.
- postmodest 3y agoAs someone working in that space at that time, IA64 was still losing to Sparc64 the entire time. We would do big boxes on Solaris and replace older Sun boxes with ia32 Pentium Pros. There wasn't really ever a point at which we thought "hm, RISC isn't working for us, we need VLIW" ...and we were an HP shop!!!
- GrilledChips 3y agoSun was one of the few processor makers who were sceptical and decided to wait and see before cancelling plans for their architecture, and it's nice to hear that worked out for them for a bit before 64-bit x86 ate their lunch. Of course, it's also possible that by that point Sun was already paralysed by infighting between various splinter groups, with no big bad DEC to fight against.
- javitron 3y agoThe irony being that Itanium is basically a SPARC64 on steroids; both wide, both used huge register windows, and both were in order. the only difference being that Itanium exposed a lot of the superscalar bits to the programmer. I still have no clue why an HP shop would be using Solaris boxes, alas...
- brookst 3y agoI still get confused whether the real name is Itanium or Itanic
- Tsiklon 3y agoIt’s a beautiful piece of tabloid journalism - jokingly naming Itanium, Itanic after the Titanic.
- rasz 3y agoIt was only the future until release date forced it to face the reality. Linus Torvalds in 2003: https://yarchive.net/comp/linux/x86.html https://yarchive.net/comp/linux/x86.html >Itanium 2 doesn't hold a candle to a P4 on any real-world benchmarks.
- FullyFunctional 3y agoHilariously, it must be read in the context that Linus actually hated the P4 for it's very imbalanced performance.
- twoodfin 3y agoCompatibility and ubiquity wins. As nearly always. I’m not particularly confused about Intel’s perspective on compatibility: Even at the time, there were several examples of successful platform CPU transitions across architectural “full breaks”. Apple going from 68k to PowerPC is the closest analogy for Intel, and if the Itanium performance and software (compiler) story had played out as Intel envisioned they likely would have been fine. But as for ubiquity, I’m befuddled. As far as I’ve been able to determine—having lived through it and followed many retrospective threads like this looking for new evidence—Intel had no plans on any useful timeline to turn Itanium into a (non-workstation) desktop or laptop chip. Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that.
- flashback2199 3y ago> Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that. Oh but they did :)
- bombcar 3y agoI think it's the case that they wanted to believe that, because the other story, that all the major "big iron" companies would be absolutely and totally forever wrecked by stupid free Linux running on stupid cheap whiteboxes was simply too horrible to envision.
- twoodfin 3y agoData center computing being dominated by commodity Linux running on commodity x86 PC architecture—for which the best CPUs were not commodities, but rather made exclusively by Intel—was likely the best of all possible worlds for them! Going back to at least the i432, Intel seems to have had a deep vein of “mainframe envy” in their culture and strategic thinking. It seems that somehow the market (and a bit of trailblazing into x86-64 by AMD) saved them from themselves.
- 3y ago
- bitwize 3y agoItanic was hype from the word go. Intel tried and failed twice to make "VLIW CPUs that rely on 'sufficiently smart' HLL compilers doing the right instruction packings" a thing before Itanium came along (iAPX 432 and i860). I think someone very high up at Intel was in love with the idea despite its repeated failures. Alpha was clearly the future -- and Itanic ruined Alpha. We didn't even get to see it live on inside some other corporate sarlacc.
- BirAdam 3y agoWell, zero speculation would have saved from all of the exploits over the years… so there’s that.
- fulafel 3y agoI hadn't heard about compiler vs 432 before, any links?
- p_l 3y agoI do recall some discussion about combination of really bad code generation combined with some ridiculously bad design decisions (I think it might have been total lack of cache?)
- tjalfi 3y agoThe blog entry Revisiting the Intel 432[0] and the cited paper Performance Effects of Architectural Complexity in the Intel 432[1] discuss the compiler issues. [0] https://bcantrill.dtrace.org/2008/07/18/revisiting-the-intel-432/ https://bcantrill.dtrace.org/2008/07/18/revisiting-the-intel... [1] https://dl.acm.org/doi/pdf/10.1145/45059.214411 https://dl.acm.org/doi/pdf/10.1145/45059.214411
- bitwize 3y agoAll I know is the Wikipedia article references a crappy Ada compiler whose lack of optimization made it run slower than a 286: https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432
- kstrauser 3y ago> Compatibility and ubiquity wins. As nearly always. In this case, that means AMD showing up with the first x86-compatible 64-bit CPUs killed Itanium dead. For big software projects already running on x86, there were 2 options: - Port everything to a new architecture that only looked good in specific benchmarks, cross your fingers, and hope for the best. - Keep running your code on new 64-bit CPUs that were backward compatible with your existing code, then recompile for 64-bit as you got around to it. As a bonus, amd64/x86-64 CPUs were faster than the P4 chips that practically needed 3 phase power to boot up. It was kind of a no brainer.
- justin66 3y ago> Turns out it was more like IBM's MCA / PS2 rather than the future. It was quite a bit worse than that. If you ignore the horror of IBM vendor lock-in, which in retrospect made the whole thing untenable, and the overpriced nature of the systems, MCA was a fine thing for its time. The PS/2s had some nice features. They were compatible with everyone's DOS and Windows stuff, even if IBM would have preferred you use OS/2, and so on. Itanium was a piece of crap, even if you could somehow ignore the cost and lock-in.
- fulafel 3y ago> Compatibility and ubiquity wins. As nearly always. Counterexample: GPU compute.
- spamizbad 3y ago> Compatibility and ubiquity wins. As nearly always. I'm not sure that was Itanium's only problem. Intel's Itanium launch focused on a market that was not captured by the so-called "Wintel" monopoly: high performance servers. The software support needed in this market was relatively narrow. Nevertheless, it failed there too. The biggest issue with Itanium is that the juice was never worth the squeeze. It was expensive. The cost to migrate your existing 64bit systems never made sense. So, you might ask, what about 32-bit shops that needed to make the leap to 64 bits? Well, by the time intel and its vendors started getting costs under control, the AMD Opteron hit the scene with commodity 64bit hardware that had the added benefit of full backwards compatibility. And that pretty much killed it.
- reidacdc 3y agoOn the one hand, I am not surprised -- at my workplace, we only ever had one Itanium system, an SGI Altix 3000-series computer. It was kind of niche even when we bought it, and core-for-core, the Itanium CPUs were slower than their competitors. What the SGI was really good at was MPI parallelism. I don't know how much of that was the CPU and how much was the overall system design of the Altix, which featured a pretty amazing interconnection fabric (CrayLink, I think?), and cache-coherency and a sophisticated memory model. But not all problems parallelized well, so the system ended up kind of being this weird outlier that was a good answer to some classes of problems, but you had to remember it existed. On the other hand, it's a bit of a shame to formally, officially lose another option out of the computing ecosystem.
- deleted 3y ago[deleted]
- cy384 3y agonumalink, 1.6GB/s in 2003! there's an altix 3000 on ebay that I'm kinda tempted by https://www.ebay.com/itm/174917876903 https://www.ebay.com/itm/174917876903 it only runs like one specific version of suse or red hat
- sillywalk 3y agoI've always wanted an Indy or an O2,but other than running the demos, I don't know what I'd do with them. Also, high-end kit is also interesting, but again, I kind of want an Altix (or Origin 2000/3000), or .AS/400 or a Tandem Cyclone.. just because it's neat. Do you have anything specific you'd do with an Altix 3000? (I don't mean to sound snooty)
- cy384 3y ago>Do you have anything specific you'd do with an Altix 3000? nope, I just like weird computers and distributed systems, itanium is possibly the weirdest CPU architecture that modern linux can run on, and SGI is an interesting part of computer history.
- 3y ago
- pixelesque 3y agoPrevious discussion from a few days ago: https://news.ycombinator.com/item?id=38115989 https://news.ycombinator.com/item?id=38115989
- jl6 3y agoThe latest 9700 models from 2017 are still in support until 2025!
- linsomniac 3y agoI presume you mean "by Intel", because Linux has other ideas. :-)
- 404mm 3y ago6.1 LTS has EOL set for Dec 2026
- mrpippy 3y agoBy HP I assume? Intel doesn’t sell them anymore, and HP was the last one to sell systems and support OSes.
- usr1106 3y agoI am surprised that there was still a new processor in 2017. I would have guessed it died nearly 20 years earlier. (I have used computers since more than 10 years before the Itaniun came out, or if you count the year of their release, 30 years older ones. But I never came even close to any Itanium.)
- pram 3y agoThe Itanium sales forecasts never fail to make me laugh. Aged like the finest wine: https://upload.wikimedia.org/wikipedia/commons/8/88/Itanium_Sales_Forecasts_edit.png https://upload.wikimedia.org/wikipedia/commons/8/88/Itanium_...
- nullc 3y agoEasily one of the best illustrations on Wikipedia.
- tux3 3y agoContrast with the notorious IAE solar forecast: https://zenmo.com/wp-content/uploads/2019/01/iea-vs-reality-photovoltaics-2018.png https://zenmo.com/wp-content/uploads/2019/01/iea-vs-reality-... Statistics and modeling are complicated, granted. But when your model diverges from reality 5 years in a row, perhaps you should just extrapolate the current line next time around. (In the case of the Itanic, that would have been the line at 0. Still a better forecast than what they did!)
- duskwuff 3y ago> Contrast with the notorious IAE solar forecast "There's no way this level of growth can be sustainable." "Surely we've hit a stable level by now." "Maybe that last year was a fluke." Love to see it. :)
- MBCook 3y agoThe motorcar is a fad! Surely after 115 years it will be over!
- deleted 3y ago[deleted]
- jodrellblank 3y ago> ""There's no way this level of growth can be sustainable."" Those are GW of added capacity per year, their prediction flatlining is predicting sustaining the same level of growth.
- karmicthreat 3y agoI had a manager that loved these things. He would shoe horn eBay one’s into any gambling backend he did. It was terrible, impossible to support and made accomplishing anything a chore. Rust in peace.
- bitwize 3y agoI don't think the Rust team is any more interested in supporting these...
- dvaletin 3y agoWhy it took so long?
- deleted 3y ago[deleted]
- yjftsjthsd-h 3y agoWith the possible exception of darwin, all the major operating systems are fairly careful about maintaining backwards compatibility. They've certainly been making noises about cutting support for a long time, but it's not surprising that they were very deliberate about doing it for real.
- dvaletin 3y agoThere is a difference between ongoing support and security fixes support. Oracle database dropped support itanium on Linux since version 11. I suggest others did this as well. Of course companies wanted to extend their HW lifetime as much as possible and switch from everyday production use to some secondary functions. But having this power hungry monsters online is a waste of money on my mind.
- p_l 3y agoIt took extra long because for various reasons it was the officially blessed architecture (specifically, HP-UX on Itanium) for running Oracle databases, leading to HP suing Oracle when the latter bought Sun and essentially declared HP-UX is to soon be EOL'd
- the_panopticon 3y agoAs necessity is the mother of invention, Itanium did lead to UEFI, though The Chicken and the Egg The very first effort that is considered a direct ancestor of UEFI technology had a very specific tactical goal. In the course of 1997 people at Intel were working on how to boot computers based on the prospective Itanium® Processor family...." from https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
- MarkSweep 3y agoAnother thing created for Itanium that outlived it is the Itanium C++ ABI: https://itanium-cxx-abi.github.io/cxx-abi/abi.html https://itanium-cxx-abi.github.io/cxx-abi/abi.html My understanding is this was first created for Itanium but is now used for other architectures.
- jenadine 3y agoIf I remember correctly, intel published a spec for the C++ ABI for uranium and GCC decided to use that on all architectures and OS to simplify the implementation. (This was at a time were GCC was still breaking frequently the ABI from version to version) When llvm came out, it tried to be compatible with GCC. As a result, given the prevalence of GCC, the Itanium ABI is now used almost everywhere. The notable exception is the Microsoft Visual compiler (MSVC) who still has its own API.
- somat 3y agoNo that's a bad thing. we could of had openfirmware. Sort of a half joke, I can see no way OFW could have made the jump to the pc world.
- p_l 3y agoVery early the project incorporated x86, because Intel planned on keeping x86 in the play for quite a long time. For a time, you could easily download a devkit for EFI on x86 which included tools and source code for EFI 1.1.
- failuser 3y agoThe worst thing about Itanium is that it killed DEC Alpha, high-performance MIPS and some other arches I keep forgetting about.
- GrilledChips 3y agoIt's kind of funny. There are lots of architectures it killed (Alpha, PA-RISC, basically everything except SPARC because Sun was sceptical) but basically all of them have outlived it in the linux kernel. It killed their manufacturing based on hype, where as they all established a firm install base before itanium ever got rolling, which has ensured they continue to be (halfheartedly) maintained.
- cbmuser 3y agoItanium was killed because unlike all the other architectures it puts a rather big burden on upstream developers due its complicated design (dual stack with growth into two directions, complicated compiler optimizations etc).
- usrusr 3y agoI keep wondering if it perhaps simply appeared too early. These days it feels as if almost everything is either open source or runs in some form of JIT compile VM, or both. Back then it was a huge problem to require code to be compiled not just to the general architecture but to the specific model to be fast. But today? Moving some of the adaptions from the hardware scheduler to process lifetime persistence (as in JIT VM) or even into the software distribution infrastructure could be delightfully transparent.
- vgatherps 3y agoIt would probably be even worse today. Dynamically discovering ILP “just works” even as memory gets slower and slower and slower. A CPU today can execute hundreds of instructions and many predicted branches ahead of a slow load. It would be impossible to statically schedule this (you don’t know what will/won’t be in cache), and difficult to try and hoist all loads 100 instructions in advance especially when you take branching behavior into account. GPUs have taken over much of the niche where these processors excel, number crunching where you have entirely pre-determined memory / compute access patterns.
- raverbashing 3y agoI wonder how good is LLVM optimized code on it, and if SW could have made a difference, or if it was just too hard/too slow to be competitive
- acdha 3y agoIt would have helped a lot but they just needed to deliver. Back in the 90s I tried a couple of things using Intel’s compilers, and they helped but not enough to catch up even before you factored pricing in. I still am amazed that they were so set on licensing revenue that they let Itanium really suffer in benchmarks but it was always going to be ugly as long as they couldn’t ship hardware on time or with the promised numbers.
- tedunangst 3y agoThis change breaks my IA-64 userland.
- mat_epice 3y agoI think they way they do this is they post a message to lkml with a “speak now or forever hold your peace” message. I think they won’t remove functionality if anyone has a credible use. If you’re ever on funky hardware and want to ensure continuing Linux compatibility, I guess it pays to subscribe.
- spandextwins 3y agoThat thing was such an abomination, good riddance. Not sure what the heck HP and intel were thinking, yeah, have the compiler do the work of ordering instructions particularly crafty so it wouldn't stall. HP had PA-RISC at the time, maybe it was an effort to kill Intel?
- JohnBooty 3y agoyeah, have the compiler do the work of ordering instructions particularly crafty so it wouldn't stall Obviously it was a disaster, but it didn't/doesn't sound like it is necessarily a bad idea. A ridiculous percentage of a modern CPU's transistor count (and design complexity) is devoted to speculative execution and other "smarts" that intel proposed shifting to the compiler. Which theoretically lets you ditch all that speculative execution hardware in the CPU and spend it on more badass cool performance stuff. Theoretically.
- 1letterunixname 3y agoPour one out for blind faith in Transmeta (which Linus also was involved with) Crusoe-like VLIW, complicated compilers, and Rolls-Royce grand designs with almost 500 registers. Enterprise will buy anything if it's expensive enough, right? Perhaps VLIW should've been proven workable and advantageous with realistic modeling first before betting billions in development.
- IAmLiterallyAB 3y agoI really like the idea of VLIW CPUs, it's a shame none of them have worked out. Does anyone know of any other cool more modern CPU designs? Stuff like RISCV is fine but doesn't feel particularly innovative
- quux 3y agoThe mill architecture has interesting ideas but as far as I know it’s never made it past simulation and there hasn’t been much progress lately. https://millcomputing.com/ https://millcomputing.com/
- Symmetry 3y agoThey had a bunch of really interesting ideas but trying to innovate in more ways at once brings exponentially more risk. And there weren't only trying to reconceptialize how computers worked, they also were doing a weird innovative corporate structure too. Once the patents expire I hope someone makes a RISC-V design that just tries to get their, e.g., virtual and backless memory working with Linux. That seems like it would be worthwhile in and of itself.
- fulafel 3y agoThere have been successful VLIWs in eg GPUs and mobile basebands. Ie in apps that don't have the software inertia of needing to run existing CPU code. Parallel unfriendly C/C++ semantics is the killer.
- voxadam 3y agoVLIW architecture is far from uncommon in DSPs (digital signal processors). TI, NXP, Fujitsu, and plenty of other companies with names less likely to be know by most people focused on general purpose computing currently manufacture massive quantities of VLIW based DSPs.
- Symmetry 3y agoThe Hexagon DSPs in Qualcomm's Snapdragon SoC line are VLIWs. Also, NVidia used some cores from the Transmeta lineage in some of its mobile SoCs for application cores. There was a program that ran on them that automatically rewrote ARM instructions to their own ISA that not only was VLIW but was a skewed pipeline VLIW! That's what the Mill guys call phasing, see here: https://millcomputing.com/wiki/Phasing https://millcomputing.com/wiki/Phasing
- rediguanayum 3y agoThe chip designers back then were focussed (micro-)instructions per clock (IPC), and everyone knew that RISC and CISC were going to hit a wall due to the ALU bypass network. A this is pretty true, they did, to this day, with some incremental improvements. Folks hoped that VLIW and advanced compilers would take us to the next level of IPC. What they didn't realize was that Itanium wasn't a true VLIW, and had that same ALU bypass network, hence couldn't scale up width and frequency as promised. But a true VLIW would have been very hard to work with. Perhaps Transmeta's approach could have worked if that technology was pushed by a a larger, more resourced company.
- chasil 3y agoI wonder how ARM, so relatively late with AArch64, was able to compel Fujitsu to take the instruction set to the heights of the top-performing supercomputer. I understand that there are exotic addressing modes involved. I'm not versed enough to understand. https://en.m.wikipedia.org/wiki/Fugaku_(supercomputer) https://en.m.wikipedia.org/wiki/Fugaku_(supercomputer)
- pezezin 3y agoFujitsu was using their own in-house SPARC designs with custom vector instructions, but they could see that SPARC is dead and has no future. In fact, not that long ago they announced that they will stop sales in 2029 and support 5 years later: https://www.fujitsu.com/global/products/computing/servers/unix/sparc/key-reports/roadmap/index.html https://www.fujitsu.com/global/products/computing/servers/un... So if they wanted to keep pushing their own designs they needed a new architecture, and ARM64 was their best option. The modern SVE extensions were co-designed by ARM and Fujitsu based on their HPC experience.
- fulafel 3y agoYep, the conventional (current) wisdom is that they hit compilers. Itanic was predicated (pun intended) on compilers being able to deliver the parallelism from existing C/C++ apps. It's pretty tragic how this has turned out. Still no mainstream CPU languages that are good for parallelism and all the action is happening in the GPU side with the tragic fragmented mutually incompatible buggy properietary dev stacks (and C++ baggage to top it off), going on for 15+ years.
- deleted 3y ago[deleted]
- tgma 3y agoAside the commercial fail, Itanic EPIC design is an interesting architecture especially when revisited from the lens of GPU computing world we live in today. Itanic also contributed EFI and popular 64-bit ABI conventions.
- logbiscuitswave 3y agoIn the mid 2000s I had to test a product I was working on with all architectures supported by Windows, which of course included ia64. We had one engineering sample HP ia64 machine in the test lab (I think it was a zx2000 but I could be mistaken). It was this giant, noisy, hulking boat anchor full tower that weighed some over 50 lbs and had a 650W power supply. I had to find a Server 2003 ia64 CD to install the OS (and work through the awful UEFI CLI incantations required to get the damn thing to boot). Once installed I was always struck by just how incredibly slow the machine was. It was just such a drag to use. Once we no longer needed to support ia64 I was thrilled that I’d never need to use that thing again. Good riddance.
- rubicks 3y agoAs an erstwhile C++ developer of finance monoliths running on OpenVMS Itanium, may I offer this sentiment: Good riddance.