77 pointsby jandeboevrie7 hours ago6 comments
  • sedatk5 hours ago
    A historical note: Windows XP 64-bit Edition that was mentioned in the article, was Itanium-specific. It was based on XP kernel while Windows XP x64 Edition (for AMD64 architecture) was based on Windows Server 2003 kernel. Because of that, Windows XP x64 Edition had some significantly different performance characteristics compared to other Windows XP editions. If anything, it was closer to Vista than XP in some aspects.
    • twoodfin5 hours ago
      I would love to read the Microsoft PM spec for this product. Who in the world were they making it for?

      Itanium never made it into the consumer-class hardware that was XP’s audience. AFAIK, Intel never even published a roadmap for that to happen!

      Maybe a proof of concept they shipped as a demonstration of loyalty to Intel?!

      • walrus014 hours ago
        In approx. 2000 to 2002, 2003 or around then, there was a theoretical dream that Itanium based workstations would become a real mass market thing, but it obviously never caught on.

        Intel never made Itanium CPUs cheap enough to realistically purchase and Itanium motherboards never became a thing from the top-10 sized Taiwanese motherboard makers (the same companies that were making really nice boards for the 1 GHz to 1.2 GHz socketed Pentium 3 with 512KB cache and the first generations of Pentium 4).

        Also the performance sucked. This was before AMD64 existed on the corporate desktop or home desktop.

        • MisterTea3 hours ago
          > Itanium motherboards never became a thing from the top-10 sized Taiwanese motherboard makers

          Supermicro and pretty sure Tyan offered Itanium motherboards.

          From what I remember the Itanium was always harped on as too complex and too power hungry for mainstream while offering abysmal x86 emulation which soured its adoption. It had a niche in certain industries like HPC and high reliability. AMD's x64 architecture launched only 2 years after Itanium launched and pretty much destroyed any future for Itanium.

        • bobmcnamara3 hours ago
          It totally worked! Took out like four decent risc competitors with just a little FOMO
          • stinkbeetle41 minutes ago
            Paper-Itanium is unfairly blamed / credited with that, but it's not exactly true. The vertically integrated RISC/UNIX minicomputer companies were not on economically viable trajectories. x86 systems were undercutting their high margin workstation and server business, subsidized by enormous volumes in PC market needed to sustain increasing silicon manufacturing and design costs of new generations. The RISCs were forced to keep retreating to higher margin, lower volume, more specialized, higher performance markets which was really their only option by that point but it was also exactly the wrong direction to go in for long-term viability in the face of these prevailing trends.

            Intel had their foundries and CPU cores paid for by video gamers and receptionists and students typing up their assignments and people looking at porn at 14.4kbps. Servers and workstations were pretty much gravy and every year there was less their systems couldn't do compared to the big iron.

            Those computers pretty much sold themselves, contrast with every $20k workstation or $100k server that the unix guys had to explain why they were worth 5x the grey box on the desk.

            SGI was struggling to make their MIPS chips and were pretty quickly finished off when nvidia started making GPUs. Itanium originated at HP as a PA-RISC replacement. They owned DEC Alpha when they killed it but arguably DEC didn't have a big base of legacy software at that point. IBM and Sun stood for a lot longer, mainly I would say largely due to locked in customers/data on Oracle and DB2 databases and proprietary software, rather than the merits of their hardware.

            If Itanium never happened, 64-bit x86 server chips would have done the same thing to MIPS, Alpha, PA-RISC, SPARC, PowerPC. Might have happened even sooner from Intel since they allegedly sandbagged efforts in that direction to protect Itanium.

        • acdha4 hours ago
          Yeah, that was real soon now in the mid-90s – I remember reading Byte in high school and they’d be talking about how Alpha, MIPS, etc. workstations were doomed and then it kept getting pushed back – maybe 98/99, early in the next century, … and then AMD launched x86-64 and everyone just stopped pretending Itanium was ever going to happen.
      • mrpippy5 hours ago
        There were Itanium workstations (https://www.openpa.net/systems/hp_i2000.html, https://www.openpa.net/systems/hp_zx2000.html), but of course these quickly crashed and burned with the rest of Itanium
        • twoodfin4 hours ago
          Yeah, I had forgotten that by the Windows XP/Server 2003 era, the latter was definitely a server product, with XP targeting the workstation world.

          That still seems weird to me. If I had to rely on a PC for high-end work in that period, I wanted the server SKU.

      • ghaff4 hours ago
        It's pretty simple. There was a point in the early 2000s (especially pre-AMD x64) when it was pretty broadly assumed that Itanium from Intel was going to inevitably win given that a 64-bit transition was inevitable (correct) and that it would happen on Intel's terms (incorrect).
  • tech234a4 hours ago
    I wonder if people are able to get Windows Server 2008 R2 to run on this yet as well. That was the last Windows OS to support Itanium, and it received updates until January 14, 2020.

    EDIT: there was also an additional patch released in May 2020 according to https://en.wikipedia.org/wiki/Windows_Server_2008_R2#Itanium

    • qingcharles4 hours ago
      Wild that shipments of Itaniums didn't end until 2021.
      • taspeotis3 hours ago
        I think HP had a big investment in Itanium and even sued Oracle to get them to keep supporting Itanium (they had contractually agreed to it, but Itanium was such a dead end...)
        • Nursiean hour ago
          They did, IIRC back in the late 00s they were also paying IBM to port software to HP-UX on Itanium, because I remember I was given a machine to play with and was asked to produce builds of some components.

          From what I remember the only drama was that there was a missing pthread_ API implementation on the platform, might have been pthread_gettime or something.

          Compared to the HP-UX on PA-RISC box I had access to at the time, the performance was amazing!

  • mghackerlady6 hours ago
    I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore

    Ironically, it died around the time LLMs/AI started becoming good. I feel like the compiler problems with vliw could be solved to a degree with a purpose built ai

    • monocasa5 hours ago
      So I feel like I need to write a blog post about this, but succinctly I think there's a good argument to be made that the issue wasn't the compiler despite popular wisdom. I don't even think it was the nature of unpredictable memory access times either as the itanium has a ton of special architectural hardware to handle unpredictable memory accesses (a lot of which are essentially some of the primitives that an OoO core uses for internal bookkeeping, just exposed architecturally).

      I just think the arch has a similarity to archs like cell where it was planned for a world without the end of dennard scaling and just stopped making sense when we weren't targeting scaling to 10Ghz consumer CPUs and beyond.

      The relatively fixed clock period that makes sense post ~2006 also means that the CPU architecture of that made the most sense ~2006 (Tomasulo OoO cores) continues to make sense, with most of the process gains going to just making bigger, wider cores.

      • jcranmer27 minutes ago
        I recall opening up the Itanium manual, and by the end of the architecture description, just despairing of the thought of trying to write a compiler for it. Itanium, I think, was ultimately a victim of its weirdness: it's too weird to really comfortably write assembly by hand; the compilers weren't really capable with its weirdness, so "regular" code was worse off than you'd normally expect. Raymond Chen has pointed out in several articles how the hardware took advantage of C's UB to do some really weird things--and this is an era where most developers expected UB to really be just implementation-defined behavior.

        Combine that with the fact that the hardware development process seems to have been compromised from the start (if you told me the hardware architects never looked at anything other than 30-instruction traces of BLAS kernels, I'd believe you), and the insane hype that was built up for it... it's not surprising that it had an extremely underwhelming launch.

      • twoodfin5 hours ago
        It was also planned for a world where high-end CPUs were differentiated by their ability to run floating-point-heavy workloads with relatively predictable memory access patterns.

        The rise of the web—and databases behind it—as the dominant high-end, high-margin workload obsoleted that assumption.

        There’s a great presentation floating around where a Compaq-acquired-DEC engineer is trying to justify how great the OpenVMS port from Alpha to Itanium is going, despite benchmarks showing Alpha smoking Itanium running Apache.

        • wbl4 hours ago
          If only the Alpha had hung on.
          • icedchai3 hours ago
            I have an AlphaServer in my collection (DS10.) For a 25+ year old system, it still feels pretty snappy!
        • eej715 hours ago
          I worked for a company that had a fairly large OpenVMS installation and had to make the transition from Alpha to Itanium. It required a considerable amount of work and the early iterations of Itanium did not provide a clear performance improvement over the final Alpha EV7z that we had been using in some GS1280s.

          Going by my faulty memory, I'd say it wasn't until Tukwila that it was a clear win over Alpha EV7z. By the time Tukwila arrived, it was pretty clear that Itanium's goose was already cooked.

      • bluedino3 hours ago
        I wonder if most people kept them around just so they don't have to port their apps or migrate to something new.

        I worked at an HP shop, and Itanium ran HP/UX so they kept running their business on their PickBASIC (and whatever database that I've forgotten the name of) system

      • acdha4 hours ago
        There was also a long piece by a former Intel chip designer who was incredulous about how much the Itanium team was promising numbers based on a very few hand-scheduled routines for FPU-limited code. I think there’s a solid argument that the design just wasn’t based on a correct understanding of what most CPUs did and over-indexed on the most performance-sensitive HPC code. I once helped run some HPC code on a test Itanium system and even there it was just so easy to fall out of the only patterns which performed well and end up slower than older Pentiums even before factoring price into the evaluation.

        > I said, wait I am sorry to derail this meeting. But how would you use a simulator if you don't have a compiler? He said, well that's true we don't have a compiler yet, so I hand assembled my simulations. I asked "How did you do thousands of line of code that way?" He said “No, I did 30 lines of code”. Flabbergasted, I said, "You're predicting the entire future of this architecture on 30 lines of hand generated code?" [chuckle], I said it just like that, I did not mean to be insulting but I was just thunderstruck. Andy Grove piped up and said "we are not here right now to reconsider the future of this effort, so let’s move on".

        https://www.sigmicro.org/media/oralhistories/colwell.pdf

        > Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average system-wide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis.

        http://courses.cs.washington.edu/courses/csep590/06au/projec...

        • aleph_minus_one3 hours ago
        • kmeisthax3 hours ago
          It's doubly funny knowing that basically nobody bothers doing these kinds of workloads on CPU if they can help it. And everything you have to do to get GPU floating point performance also makes GPUs really, really bad for normal CPU code. Hell, at one point AMD actually was shipping VLIW for shader code...
          • aleph_minus_one3 hours ago
            > It's doubly funny knowing that basically nobody bothers doing these kinds of workloads on CPU if they can help it.

            When the Itanium was developed and introduced (2001), nobody was thinking about general-purpose computations. DirectX 8.0, which introduced Shader Model 1.1 (which was far away from being suitable for GPGPU; Shader Model 1.1 was rather about strongly (also size-)limited programs for the vertex and pixel processing stage), was only introduced in 2000, the first release of CUDA was in 2007, and the first release of OpenCL was in 2009.

      • 5 hours ago
        undefined
    • 20k5 hours ago
      People have tried all kinds of techniques for VLIW, including techniques that are much better than a purpose built AI, AI isn't a magic silver bullet. Fundamentally there's no reason you can't analyse a piece of code to death, and maximally extract parallelism out of it

      The fundamental issue is that there simply doesn't exist enough information to be able to extract the necessary parallelism without a rewrite, its the same issue as trying to autovectorise. You can do it to some degree, but it doesn't work in practice to be able to fill out a very wide architecture with reasonable efficacy

      The SIMT programming model has proven to be much more successful vs trying to autovectorise or mash things into a VLIW architecture

      • ggm3 hours ago
        From memory, Glasgow University CS had serious buy in to VLIW models of computation for a while, predating Itanium. There was good reason for believing it might have some interesting behaviours. I think they worked on languages targetting it, data models, things like reversible computation, long lived processes.
    • MBCookan hour ago
      It was neat to live through the era where CPUs constantly got faster and they were willing to try such oddball stuff.

      For such a long time it became “faster and more cores, don’t be different” and just didn’t seem as interesting.

      Apple Silicon had been very interesting to me. I’m really hoping to see a stronger ARM push on Windows, both because I know it can be great and because it’s just interesting. Windows has never had to switch architectures (for consumers) or support two at once for any reasonable population.

      Also, whatever happened to mill? We used to get posts about them all the time.

      And I wonder what would have happened to Power if they had the 3rd party fabs that exist today instead of being stuck with what IBM could make in-house.

    • spott5 hours ago
      I think it died before that, it was just that buried it then.
    • ndiddy4 hours ago
      Even if the magical Itanium compiler did exist, Itanium would have still lost to AMD64. As soon as you introduce anything that doesn't behave in a statically predictable manner (multitasking, or virtualization, or even an application that processes unpredictable input like a web backend or database), your performance drops down to a fraction of what a similarly priced AMD64 chip could do. VLIW is great for some very specific workloads like HPC, but Intel should have never tried to replace x86 with it.
      • MBCookan hour ago
        The lack of licensing to other companies was clearly a POWERFUL incentive.

        Imagine how much money they could make if that pesky AMD went away.

    • nl4 hours ago
      > Ironically, it died around the time LLMs/AI started becoming good.

      What?

      I think maybe you are confusing Itanium with something else?

      Development on itanium stopped in 2013:

      > On 31 January 2013 Intel issued an update to their plans for Kittson: it would have the same LGA1248 socket and 32 nm process as Poulson, thus effectively halting any further development of Itanium processors.[1]

      It's true that it shipped until 2021, but I think you had to already have previous orders to get that.

      [1]https://en.wikipedia.org/wiki/Itanium

    • icedchai3 hours ago
      Itanium was effectively dead once Intel adopted AMD's x86-64. It just remained a zombie for another 15+ years.
    • 486sx335 hours ago
      [dead]
  • WarOnPrivacyan hour ago

        XGCJ6-Q6XGJ-BQ2QQ-BRWJ7-67X7W
    
    I used to have this key memorized.
  • t1234s3 hours ago
    was there any advantage or special use case for running an itanium windows workstation instead of x86 back then?
    • twoodfin3 hours ago
      More than 3GB of application memory space and more than 4GB overall (including the NT kernel).

      At that time, this was starting to become a major issue at the high end of servers and workstations.

      • kstrauseran hour ago
        And then AMD64 came along and we immediately moved to 8GB servers, taking away the only real Itanium advantage.
  • an hour ago
    undefined