Announcement

Collapse
No announcement yet.

Linux 6.7 Set To Drop Support For Itanium IA-64

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

  • stormcrow
    replied
    Originally posted by Dawn View Post

    OpenVMS only made up ~5% of Integrity systems sales (HP-UX accounted for over 80%, and absolutely dominated big-system sales, with Nonstop and - prior to 2010 - Windows Server making up the majority of the remainder.)
    Windows Server wasn't an impediment to migration. Technically, neither was HP-UX as it's a Unix-like with much more in common with Unices at the time than the wholly proprietary OpenVMS. There were migration paths available to IBM AIX, SPARC/Solaris (Sun/Fujitsu and later Oracle's greed-driven mismanagement). Still, I grant the argument that people tend to stick where they are regardless until they have no choices but to move. For the low-mid tier x86-64 was "good enough", while the high end stuck with the devils they knew already. The HPC crowd would go with whoever topped the performance charts and won the contracts. The support libraries for science HPC work just expanded to accommodate which ever platforms won the lab contracts.

    Leave a comment:


  • Dawn
    replied
    Originally posted by stormcrow View Post

    Opteron didn't kill Itanium. x86 in general (added: and x86_64 specifically but no individual product as such) did on the low end along with the people Intel wanted to attract stuck with IBM/Sun for those that were in the market for expensive high-availability hardware on the high end. The reason HP was able to push Itanium for as long as they did was because the people stuck with DEC's entirely proprietary OpenVMS didn't have any other migration path. Between HP and Intel they killed Alpha architecture, DEC's intended path forward. Those who could stuck with Alpha based systems as long as they could find the parts for them. Few if any of those are going to be running Linux, anyway.
    OpenVMS only made up ~5% of Integrity systems sales (HP-UX accounted for over 80%, and absolutely dominated big-system sales, with Nonstop and - prior to 2010 - Windows Server making up the majority of the remainder.)

    Leave a comment:


  • stormcrow
    replied
    Originally posted by Dawn View Post

    Itanium systems outsold Opteron systems for many years. I don't get this "Opteron killed Itanium" narrative and never have.

    https://images.anandtech.com/doci/4285/Risc_loss.png for instance.
    Opteron didn't kill Itanium. x86 in general (added: and x86_64 specifically but no individual product as such) did on the low end along with the people Intel wanted to attract stuck with IBM/Sun for those that were in the market for expensive high-availability hardware on the high end. The reason HP was able to push Itanium for as long as they did was because the people stuck with DEC's entirely proprietary OpenVMS didn't have any other migration path. Between HP and Intel they killed Alpha architecture, DEC's intended path forward. Those who could stuck with Alpha based systems as long as they could find the parts for them. Few if any of those are going to be running Linux, anyway.
    Last edited by stormcrow; 18 September 2023, 12:30 PM.

    Leave a comment:


  • jabl
    replied
    Originally posted by oiaohm View Post
    I could say some of the last Itanium buyers might be having a very bad case of buyers remorse.
    Au contraire, I believe most of them were happy they got their final order in, allowing them to kick the inevitably upcoming migration project down the road a few more years.

    Leave a comment:


  • Dawn
    replied
    Originally posted by zexelon View Post

    100% true... but the entire market cared... very deeply. Itanium was the first major 64bit ISA from Intel and was billed as the "transition from 32bit to 64bit". Unlike your other examples Itanium does include x86 hardware instructions in it, and in all its incarnations clamed full x86 compatibility. Literally NONE of your other examples do that. Its just that in Itanium the completely butchered the x86 implementation in some half baked (probably marketing driven, but thats pure hearsay) attempt to drive people to the IA64 implementation.

    Also Opteron completely crushed Itanium. Itanium was first to market, that was its only win in the sales side. It was then promptly relegated to niche markets like the HP nonstop servers.

    Aggressiveness is a poor substitute for reason.
    HP designed Itanium as a long-term evolution of PA. For its userbase, x86 compatibility was largely irrelevant, because HP-UX never ran on x86 to begin with. The only use of x86 compatibility I ever saw was running x86 utility software on large Windows Server systems, and for that, the fact it had a 50%+ penalty didn't matter at all because those were not CPU-bound applications (I'm talking about stuff like PuTTY here.)

    Also, "crushed Itanium" at what? Look at sales numbers for 2007-2009, when Itanium and Opteron had both been around for years. It's one-sided, and not in favor of Opteron. If you say "performance", take a look at SPEC and TPC numbers for the same period.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by zexelon View Post

    Yes you are correct, its performance exceeded x86 substantially... in very specific, very parallel use cases and only when fully programmed in its native IA64 instruction set. If you were trying to run in x86 compatibility mode, early editions were utterly abysmal and later editions were merely passable. It was also far more difficult to build optimized compilers for this ISA than originally thought.
    Right but any compatibility mode is going to be substantially lower than using the native instruction set so not sure what point you are making here. Similar to Rosetta for Mac systems, the whole point of these compatibility modes is to provide a bridge for the native instruction set and not something to be used if you want top performance.

    So to me saying that the x86 compatibility mode in IA64 was slower than x86 is kinda like, "well duh".

    Leave a comment:


  • zexelon
    replied
    Originally posted by Dawn View Post

    "Processor running emulator has substantial performance penalty! Film at 11!"

    Who gives a shit? That's relevant to the NT folks and almost nobody else. Shockingly, Itanium's major competitors - Power, SPARC, Z - would also have poor performance emulating x86.
    100% true... but the entire market cared... very deeply. Itanium was the first major 64bit ISA from Intel and was billed as the "transition from 32bit to 64bit". Unlike your other examples Itanium does include x86 hardware instructions in it, and in all its incarnations clamed full x86 compatibility. Literally NONE of your other examples do that. Its just that in Itanium the completely butchered the x86 implementation in some half baked (probably marketing driven, but thats pure hearsay) attempt to drive people to the IA64 implementation.

    Also Opteron completely crushed Itanium. Itanium was first to market, that was its only win in the sales side. It was then promptly relegated to niche markets like the HP nonstop servers.

    Aggressiveness is a poor substitute for reason.

    Leave a comment:


  • Dawn
    replied
    Originally posted by zexelon View Post

    Yes you are correct, its performance exceeded x86 substantially... in very specific, very parallel use cases and only when fully programmed in its native IA64 instruction set. If you were trying to run in x86 compatibility mode, early editions were utterly abysmal and later editions were merely passable. It was also far more difficult to build optimized compilers for this ISA than originally thought.
    "Processor running emulator has substantial performance penalty! Film at 11!"

    Who gives a shit? That's relevant to the NT folks and almost nobody else. Shockingly, Itanium's major competitors - Power, SPARC, Z - would also have poor performance emulating x86.

    Leave a comment:


  • Dawn
    replied
    Originally posted by CommunityMember View Post
    Itanium was too far ahead of its time, in that the compilers, of its day, could not properly schedule the EPIC (a VLIW variant) pipeline, leaving a lot of potential performance on the table. And Intel's choice to not cannibalize its existing cash cow (x86) production by using the more advanced lithography was another factor that contributed to Itanium's minuscule market share. AMD (with its 64-bit extension(s) for x86) put the nail in coffin, although Itanium continued as the living dead for quite some time. Itanium did have a place in certain high performance computing deployments where there was value in throwing programmers at optimizing their code for the architecture.
    Itanium systems outsold Opteron systems for many years. I don't get this "Opteron killed Itanium" narrative and never have.

    https://images.anandtech.com/doci/4285/Risc_loss.png for instance.

    Leave a comment:


  • CommunityMember
    replied
    Itanium was too far ahead of its time, in that the compilers, of its day, could not properly schedule the EPIC (a VLIW variant) pipeline, leaving a lot of potential performance on the table. And Intel's choice to not cannibalize its existing cash cow (x86) production by using the more advanced lithography was another factor that contributed to Itanium's minuscule market share. AMD (with its 64-bit extension(s) for x86) put the nail in coffin, although Itanium continued as the living dead for quite some time. Itanium did have a place in certain high performance computing deployments where there was value in throwing programmers at optimizing their code for the architecture.

    Leave a comment:

Working...
X