Announcement

Collapse
No announcement yet.

Linux Looks To Retire Itanium/IA64 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by jabl View Post
    I guess they have a bunch of captive VMS customers that they are happily milking, with little resources spent on development. Not sure what the plan is for VMS, have they ported it to x86-64 or..
    DEC > Compaq > HP > VMS Software Inc. I have no clue if VMS Software is an independent spin off, wholly owned subsidiary of HP or HPE or what. But right now the company is betting on its x86-64 port moving forward. It has been in the works for years and only just recently became available for those with the cash to spend on it. That's NOT 'happily milking with little spent on development'. Porting to new architectures is expensive and time consuming.

    If it were me and my company hadn't already created a road map to an alternative, I'd be pushing for it vigorously. VMS is a dead end road. Note, not saying VMS is dead. I'm just saying as a business platform it has no future. It took too long to make the port to x86, the numbers of people able and willing to support it are dwindling making them increasingly more expensive to hire. If your system hardware becomes unusable, moving your data off it will be prohibitively expensive (because you also either have to port your software to the new architecture, or do data conversions for new software packages, or hope you can buy a used compatible part), etc. That's a lot easier when you can do all that with a relatively smooth transition functional transition -rather than panic mode because hardware died and can't be replaced or repaired.

    Over the years VMS has run on VAX, Alpha, Itanium, and now x86-64. Last release for Alpha OpenVMS was in 2017 while the final release for Itanium/Integrity was in 2021. They'll be supported for the indefinite future I'm sure. Systems like this rarely completely die out because of the problem in moving their functions to new architectures. This is why there are still a few Apple IIs in some small businesses, some large corporations and governments still have IBM S/360s and even punch card tabulators, and Alpha systems were still maintained by 3rd parties long after the demise of DEC/Compaq and the Alpha architecture (by cannibalizing parts).

    Comment


    • #22
      Originally posted by EphemeralEft View Post
      Damn, 65k lines?! Isn’t it the compiler’s job to port architecture-agnostic code to architecture-specific instructions? Or is all that code just drivers?
      Several kernel components need to know CPU-specific things, especially the scheduler since it needs to swap out registers. OSes also just generally sprinkle assembly language here and there for the odd specific behavior or optimizations. Even Windows has assembly in some usermode code.

      Comment


      • #23
        Originally posted by Ironmask View Post
        My guess is they kept making them under some contractual reasons or partnership deals. In fact, while I don't have any sources, that sounds very familiar to me.
        The TL;DR is that the deal between HP and Intel that birthed Itanium and moved HP-UX off PA-RISC compelled Intel to stick to the agreed-upon roadmap, come hell or high water.

        Comment


        • #24
          Originally posted by EphemeralEft View Post
          Damn, 65k lines?! Isn’t it the compiler’s job to port architecture-agnostic code to architecture-specific instructions? Or is all that code just drivers?
          The kernel runs close enough to the hardware that it needs plenty of ISA specific code. You can see precisely what is being changed in the summary here:



          That said, some things that stand out in the patch are the syscall entry code, EFI support, iommu support, ACPI support, I/O SAPIC support, Machine Check Architecture support, ptrace support and stack unwinding support. Each of those are over a thousand lines with many over 2 thousand lines.

          That said, there are plenty of little things that each ISA is expected to do and those all add up.

          Comment


          • #25
            Originally posted by schmidtbag View Post
            At first I found this confusing - if Itanium was made as recently as 2021, that implies there must have been customers to justify its production in 2020, yet the article suggest there haven't been any. I know there's no modern Windows OS to support it. The BSDs have IA64 support but they seem to struggle just to be fully caught up with x86-64, so I don't see why anyone would run their enterprise on IA64 with BSD. So, I looked it up - apparently the OS is HP-UX, which is some other Unix derivative. I knew HP was really the only reason Itanium was still alive but I didn't think they made their own OS for it. I can't say I'm surprised though - I'm sure Intel didn't want anything to do with it and clearly, nobody from any other market cares, so it was really up to HP to do all the work.


            It would also explain why Intel thought they could compete against ARM in the mobile market using x86. So the funny thing is, I'd say Intel has had more reasons not to put all their eggs in the x86 basket than to do so.
            The main OS on Itanium boxes these days is OpenVMS. Unfortunately, we still have 2 servers at work using OpenVMS on Itanium (a library reservation server, and our ERP/payroll/dispatch system). It's getting harder and harder to support the hardware (UltraSCSI drives, whee!) yet neither company really has a migration path to get off OpenVMS. The ERP system has a "nice" web frontend now ... which is just a GUI wrapper around telnet connections to the OpenVMS system. They also added a "nice" MSSQL reports database ... that still pulls data from the OpenVMS flatfile databases.

            It's going to be an interesting year, as contracts come up for renewal. Without some solid plans for migrating off OpenVMS on Itanium, we're going to start looking for alternatives.

            Comment


            • #26
              Originally posted by jabl View Post

              AFAIU there was no big user of Linux on Itanium, except for SGI, but they switched over their Altix line to x86-64 before going economically in the drain and eventually ended being gobbled up by HPE.

              HP-UX is an old-school unix. I think originally it ran on M68k(?) before switching over to HP's own RISC architecture, PA-RISC. The Itanium project originally started of as a HP research project to design a "PA-RISC 2.0", and then Intel got on board and eventually more or less took it over. That being said, I'm not sure there's any actual HP-UX development going on, or are they content on milking their existing customers as hard as possible before they jump ship to Linux for as long as it lasts.

              Via the DEC (via Compaq, no?) acquisition HP also got hold of VAX/VMS, and they ported VMS over to Itanium as well. Similar to HP-UX, I guess they have a bunch of captive VMS customers that they are happily milking, with little resources spent on development. Not sure what the plan is for VMS, have they ported it to x86-64 or..
              There is an OpenVMS port to amd64 in progress. I believe they just released a beta or public preview or something like that. No idea when it will be "production ready", though, as it's been "just around the corner" for 5-odd years now.

              Comment


              • #27
                Originally posted by kurkosdr View Post
                Nah, Itanium kind of sucked because the compilers it required to perform proved impossible to write.
                I would go one step further (not disagreeing with you, just adding...). Itanium and other VLIW processors addressed one problem - making optimal use of available hardware assuming consistently fast memory - quite successfully, and AFAICS the compilers generally were up to the task.

                What the combination of VLIW hardware plus smart compiler could *not* address is the runtime impact of cache hits and misses on memory accesses. Rather than memory having fairly consistent behaviour (the difference between a DRAM page hit and page miss was only ~2:1) the processor now had to deal with 1000:1 differences in memory latency that could not be predicted at compile time without explicit management of cache contents.

                It's not clear to me why the combination of compile-managed VLIW and hardware-managed caches was pursued (by others as well as Intel) but I imagine the argument was that a HW-managed cache shared across all threads could outperform a compiler-managed cache (like LDS/GDS on a modern GPU) that had to be partitioned into smaller per-thread blocks so that the compiler could own the thread's cache. Given the "diminishing returns" relationship between cache size and hit rate I don't buy that argument, but caches were much smaller back then so it may have carried more weight.

                VLIW + smart compiler handled one problem but not the other, while out-of-order and speculative execution handled both.
                Last edited by bridgman; 15 February 2023, 01:07 PM.
                Test signature

                Comment


                • #28
                  Originally posted by phoenix_rizzen View Post

                  The main OS on Itanium boxes these days is OpenVMS. Unfortunately, we still have 2 servers at work using OpenVMS on Itanium (a library reservation server, and our ERP/payroll/dispatch system). It's getting harder and harder to support the hardware (UltraSCSI drives, whee!) yet neither company really has a migration path to get off OpenVMS. The ERP system has a "nice" web frontend now ... which is just a GUI wrapper around telnet connections to the OpenVMS system. They also added a "nice" MSSQL reports database ... that still pulls data from the OpenVMS flatfile databases.

                  It's going to be an interesting year, as contracts come up for renewal. Without some solid plans for migrating off OpenVMS on Itanium, we're going to start looking for alternatives.
                  This is not even close to true.

                  VMS never accounted for more than a few percent of IPF revenue. HP-UX was always the overwhelming majority, with Nonstop, Windows, VMS, and Linux making up the smaller parts. HP noted in internal emails that VMS was actually a smaller business unit for them than Windows/IPF was. HP didn't even bother supporting VMS on much of their later hardware (any Poulson machine, larger Tukwila machines.)

                  Comment


                  • #29
                    Originally posted by stormcrow View Post
                    DEC > Compaq > HP > VMS Software Inc. I have no clue if VMS Software is an independent spin off, wholly owned subsidiary of HP or HPE or what. But right now the company is betting on its x86-64 port moving forward. It has been in the works for years and only just recently became available for those with the cash to spend on it. That's NOT 'happily milking with little spent on development'. Porting to new architectures is expensive and time consuming.
                    I meant 'development' as in adding new features, making the code faster and more scalable etc. Sure, porting to a new platform is expensive and time consuming, but that's kinda them being being between a rock and a hard place, needing to do it if they want to keep selling VMS at all after Itanium hardware disappears.

                    If it were me and my company hadn't already created a road map to an alternative, I'd be pushing for it vigorously. VMS is a dead end road. Note, not saying VMS is dead. I'm just saying as a business platform it has no future. It took too long to make the port to x86, the numbers of people able and willing to support it are dwindling making them increasingly more expensive to hire. If your system hardware becomes unusable, moving your data off it will be prohibitively expensive (because you also either have to port your software to the new architecture, or do data conversions for new software packages, or hope you can buy a used compatible part), etc. That's a lot easier when you can do all that with a relatively smooth transition functional transition -rather than panic mode because hardware died and can't be replaced or repaired.
                    Yes, absolutely.

                    Over the years VMS has run on VAX, Alpha, Itanium, and now x86-64. Last release for Alpha OpenVMS was in 2017 while the final release for Itanium/Integrity was in 2021. They'll be supported for the indefinite future I'm sure. Systems like this rarely completely die out because of the problem in moving their functions to new architectures. This is why there are still a few Apple IIs in some small businesses, some large corporations and governments still have IBM S/360s and even punch card tabulators, and Alpha systems were still maintained by 3rd parties long after the demise of DEC/Compaq and the Alpha architecture (by cannibalizing parts).
                    A former employer of mine had an Alpha-based HPC cluster back in the day. When it reached EOL it didn't go on the scrap heap, instead a nuclear power plant bought it for spare parts.

                    Comment


                    • #30
                      Originally posted by edxposed View Post
                      IA32 support should also be removed, this obsolete garbage should go into a museum
                      You mean legacy 32-bit x86? There are still some currently-manufactured microcontrollers that run it.

                      Given that probably millions of time as many 32-bit x86 CPUs shipped as IA64, I'd say 32-bit x86 support should probably hang on a little bit longer.

                      Comment

                      Working...
                      X