Announcement

Collapse
No announcement yet.

Intel Itanium IA-64 Support To Be Deprecated By GCC 10, Planned Removal In GCC 11

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

  • #41
    Originally posted by torsionbar28 View Post
    Complete nonsense, where do you get this stuff?? Plenty of Itanium hardware was sold with vendor installed and supported Linux distros. I worked for HP during this time, and I can assure you, RHEL was an officially supported OS on Itanium. Same goes for the Itanium servers from Dell, which were sold with your choice of Linux (RHEL or SLES) or Windows.
    Workstations != servers

    Comment


    • #42
      Originally posted by Bsdisbetter View Post
      Workstations != servers
      Who said anything about workstations? I'm talking about rack mount servers. Both HP and Dell supported Windows and Linux on Itanium rack mount servers. Fact.

      Edit: see for yourself here. Dell supported OS's on the Poweredge 7150 Itanium server include Red Hat Linux:
      https://www.dell.com/support/home/us...e-7150/drivers
      The newer Poweredge 3250 and 7250 with Itanium2 processors supported RHEL v2.1 and v3 as well.

      I'm not going to dig up an equivalent HP link because their site is horrible how after the HP/HPE split, but I can assure you it's the same situation with HP.
      Last edited by torsionbar28; 14 June 2019, 10:03 PM.

      Comment


      • #43
        Originally posted by torsionbar28 View Post
        If you recall, Netburst P4's were so terrible, they regularly overheated, couldn't compete with Athlon on performance, and only scaled to 3.8 Ghz max.
        Not exactly. The P4 Northwood core was faster than Athlon XP (T-bred), and it didn't have the overheating problems of its succesor, (Prescott), unless you pumped in too much Voltage when trying to OC.
        Netburst couldn't compete with Athlon64, even when Intel got the TDP under control with the move to 65nm (Cedar Mill/Presler).

        Comment


        • #44
          Originally posted by jacob View Post
          The Itanic will be remembered as one of the worst ideas in CPU design history, with a botched implementation to match.
          Botched implementation? Maybe. But VLIW is definitely not the worst idea in CPU design. The idea is good at the time where superscalar wasn't mature. Have you ever heard of the Transmeta Crusoe? An "x86" CPU that's smaller, cheaper, faster and much less power hungry than Intel CPUs in its era

          Comment


          • #45
            Originally posted by phuclv View Post

            Botched implementation? Maybe. But VLIW is definitely not the worst idea in CPU design. The idea is good at the time where superscalar wasn't mature. Have you ever heard of the Transmeta Crusoe? An "x86" CPU that's smaller, cheaper, faster and much less power hungry than Intel CPUs in its era
            Maybe you mean dynamic OoO execution and register renaming? Superscalar was very mature at the time. Intel had been using it since the first Pentium, several years before the Itanium, and the Pentium itself was already late to the game.

            Of course I've heard of the Crusoe. It has an internal VLIW core, just like most modern CPUs including virtually all current Intels and AMDs. But that's the whole point: it uses VLIW the right way, e.g. dynamically, where the execution slots can be fed from a dispatch queue based on the current context and thus maximise the core utilization. The Itanium idea was to get rid of all the dynamic translation/dispatch "overhead" and expose the naked core, with the assumption that optimisation would instead be done statically ahead of time by the compiler. I don't know if it's just me, but I really don't understand how could someone believe that it was somehow not equivalent to the Turing machine's halting problem? I practice, I've read somewhere that in real world applications (as opposed to benchmarks) the instruction slot utilisation was around 60% at the best of times. So the whole Itanic saga ultimately amounted to offering extremely expensive processors with subpar performance to begin with, and then running them at around 60% of their capabilities. AMD's proposition, on the other hand, was much cheaper processors with excellent performance and backward compatibility on top of it. Put like that it's obvious who won and why.

            Comment


            • #46
              Technically VLIW was interesting when HP proposed the project. It had been preceded by Fisher's "Bulldog" compiler (PhD research), commercialized by Multiflow. It looked performant for scientific applications. The common wisdom is that commercial workloads are too irregular and branchy (at a small scale) for VLIW to get good traction.

              Commercially, it looked to me as if Itanium succeeded in blowing most RISC architectures out of the market. PA gone. Alpha gone a little later. MIPS retreated to embedded space. SPARC and Power lost mindshare. That damage scorched the earth, making room for x86 when it got good enough. So failure of Itanium was almost irrelevant to Intel's success moving up the box hierarchy.

              The Itanium systems seemed to be designed from the start for server systems: no stupid BIOS history, HA features, ECC, not tied to having a keyboard and VGA display. These looked like the style of engineering around boxes from Sun, IBM, HP, and SGI. PC hardware still hasn't gotten there completely. I think EFI came out of Itanium. Surely there was some second system syndrome too.

              It appeared as if Intel x86 was in mortal combat with AMD and Itanium got few engineering cycles. I seem to remember it was always a generation behind in semiconductor process. No wonder it looked bad.

              Today's x86 processors seem really profligate with transistors. But that seems to be OK when there are so many transistors on a chip. In retrospect, transistor budgets really determined optimal architecture style. For a while it was a no-brainer that RISC was best. Now it seems almost irrelevant for desktops and above.

              Comment

              Working...
              X