Slashdot Mirror


HP's NonStop Servers Go x86, Countdown To Itanium Extinction Begins

An anonymous reader writes "HP has been the sole holdout on the Itanium, mostly because so much of the PA-RISC architecture lives on in that chip. However, the company recently began migration of Integrity Superdome servers from Itanium to Xeon, and now it has announced that the top of its server line, the NonStop series, will migrate to x86 as well, presumably the 15-core E7 V2 Intel will release next year. So while no one has said it, this likely seems the end of the Itanium experiment, one that went on a lot longer than it should have, given its failure out of the gate."

243 comments

  1. EPIC failure by Anonymous Coward · · Score: 0

    Also, Itanic

    1. Re:EPIC failure by Megane · · Score: 1

      I am extremely disappointed that this Register article does not use the word Itanic. Not even the (currently 8) reader comments. I expected higher standards from such an organisation as El Reg.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    2. Re:EPIC failure by unixisc · · Score: 1

      I thought that the Registed actually coined that term?

    3. Re:EPIC failure by unixisc · · Score: 3, Interesting

      The thing I loathe most about the Itanic is how it sunk 2 or 3 better CPUs before it - PA-RISC, MIPS V and Alpha. Compaq/HP should have left NonStop on MIPS and VAX on Alpha, and never gone the Itanic route w/ them. Heck, even Linux largely (except Debian) has abandoned the Itanic, and only FreeBSD, of the BSDs, did an Itanic port (I'm not sure that even the much ported NetBSD or OpenBSD has been ported to it). There is even less reason for VMS or NonStop to have gone Itanic.

      Two things the Itanic can be good for - supercomputing, and a test bed for Inferno/Plan 9.

    4. Re:EPIC failure by Archfeld · · Score: 3, Insightful

      Ditto that comment. I really hate the fact that HP gets any credit for NON-STOP, Tandems baby, or VAX and Alpha, 2 of the 3 great things that Digital brought forth into this world, the other WAS Alta-Vista. The only thing HP ever did well was printers and that time has LONG since passed...

      Note : I spent several years supporting all of the above machines and may be a bit biased.

      --
      errr....umm...*whooosh* *whoosh* Is this thing on ?
    5. Re:EPIC failure by K.+S.+Kyosuke · · Score: 1

      Hah, MIPS is still very much alive. Well, not on desktop, but still...

      --
      Ezekiel 23:20
    6. Re:EPIC failure by mjwalshe · · Score: 2

      Your forgetting RPN calculators and instrumentation

    7. Re:EPIC failure by unixisc · · Score: 1

      I said MIPS V - the R10000, R12000 and everything else in that line. Those CPUs were only used in SGI's & other servers. The ones that go into routers, or PlayStations or Nintendos are MIPS III or IV CPUs, afaik

    8. Re:EPIC failure by occasional_dabbler · · Score: 1

      Yep, this. HP RPN calculators were, and often still are, outstanding. And I remember as a u/grad on work experience running an aircraft engine vibration test using HP FFT analyzers back in the 80s. These bits of kit would still look modern and sexy today, back then it was like they'd dropped through a wormhole. Of course each one cost more than I paid for my first house...

      --
      "Our opponent is an alien starship packed with atomic bombs," I said. "we have a protractor"
    9. Re:EPIC failure by K.+S.+Kyosuke · · Score: 1

      R10000 and R12000 were MIPS IV, not MIPS V. Whatever was scrounged from the canceled MIPS V can only live in MIPS32 and MIPS64 implementations.

      --
      Ezekiel 23:20
    10. Re:EPIC failure by lowen · · Score: 1

      MIPS V apparently never actually hit silicon. R10K, R12K are still MIPS IV. (I have some SGI kit with those, a couple of the purple Indigo2 IMPACT systems, and an O2.....)

      If you're thinking MIPS64, well, you can find that in embedded devices, routers, etc. Look for Cavium Octeon processors.

      See https://en.wikipedia.org/wiki/List_of_MIPS_microprocessor_cores for which silicon is MIPS64.....

    11. Re:EPIC failure by mjwalshe · · Score: 1

      Yeah i think we had one of those at my first job at BHRA (based at CIT) cost the same as the small house about £250,000 in todays money

    12. Re:EPIC failure by Archfeld · · Score: 1

      WOW, you are very correct, it has been that long since I was in school that I had completely forgotten the absolute joy at getting a programmable calculator and putting away the slide rule. Dang I feel old now...

      --
      errr....umm...*whooosh* *whoosh* Is this thing on ?
    13. Re:EPIC failure by TheRaven64 · · Score: 1

      Compaq/HP should have left NonStop on MIPS and VAX on Alpha, and never gone the Itanic route w/ them

      You're missing HP-UX on PA-RISC and Tru64 on Alpha. This is why HP jumped on the Itanium bandwagon. They weren't big enough to be viable developing one CPU for in-house use and they had two (PA-RISC and Alpha) that they needed for their own product lines. Killing one and migrating to the other would not have gone down well with their customers or engineers, and wouldn't have solved the problem that successful microprocessor development is all about volumes: it doesn't matter if you've got a chip for a niche architecture that's twice as fast as Intel's, because they'll sell well over a hundred times as many as you and so you won't be able to compete on performance per dollar. IBM only manages it by sharing a huge amount of their designs between mainframe, supercomputer, and embedded chips, and even then the POWER line struggles relative to the Xeon - it's competitive, but it's not a clear winner.

      DEC paid Microsoft to port Windows to Alpha. If they'd also paid them to port Office and Visual Basic, and had given away free Alpha workstations to the top thousand Windows software development companies, then we'd probably all be using Alphas now. They missed the boat, and HP had to deal with the situation as they found it.

      The problem was not that they decided to go with an outsourced architecture, it was that the one they picked was a clusterfuck from the start. The philosophy behind the CISC movement was to produce chips that were easy for assembly writers to program. The philosophy behind the RISC movement was to produce chips that were easy for compilers to target. The philosophy behind the VLIW movement was to produce chips that are easy to design, but hard to program for humans and compilers. It failed the first three times Intel tried it, yet they managed to convince HP that this time it would work really well.

      A better strategy for HP might have been to follow Apple's example with the Apple-IBM-Motorola group, and set up a new consortium to make workstation and server CPUs. Sun and Fujitsu were already starting to run collaborate on designs. Between them and HP, they might have been able to produce one line of CPUs that would be easy to emulate SPARC, Alpha, and PA-RISC on and which could have kept the performance lead over Intel. By sharing the development costs between the three of them (maybe four, if Motorola had been interested), they'd have been able to push the unit costs down quite a bit.

      --
      I am TheRaven on Soylent News
    14. Re:EPIC failure by Megane · · Score: 1

      THAT'S THE JOKE.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    15. Re:EPIC failure by unixisc · · Score: 1

      By the time HP acquired Compaq, the latter had already abandoned the Alpha. Therefore, when HP acquired Compaq, they should have sold/spun off the VAX & Alpha lines to another company, so that they wouldn't be left w/ the responsibility of either Tandem or DEC. After all, HP bought Compaq for Compaq, not these 2.

      I agree that a consortium might have been a good idea, but PA-RISC was purely an HP architecture. That's why I suggested elsewhere in this page that since they needed to outsource CPU development, they should have sold PA-RISC outright to Intel, and let Intel develop the marketing strategy around it. As it is, the PA-RISC was close to or matching Alpha benchmarks when it retired, so had Intel taken it over at that point, they'd have started w/ an existing user base - HP's, and then proliferated it, either by having Microsoft port NT to it, or going fully Linux/BSD and getting all the Linux & UNIX guys to back it.

      On the VLIW history, it was HP who started it - acquiring 2 VLIW companies Multiflow & Cydrome - and sold the concept to Intel. While VLIW was easy to design @ a chip level, the actual cost savings over RISC were minimal, once it was found that the real estate savings on die was just something like 10% once one got rid of register renaming, speculative execution and so on. As it is, in Itanium, register renaming is back, so today, that CPU is more RISC than VLIW. Nonetheless, it now looks headed for the dustbin of CPU history.

  2. Meh by Anonymous Coward · · Score: 0

    Meh. This pretty much describes IA64/Itanic, as well as any "news" related to it.

    OTOH, you will be able to get those in eBay even cheaper, Debian runs on it just fine, and shellcode for IA64 is pretty much nonexistant.

    1. Re:Meh by cheesybagel · · Score: 1

      HP was like the last vendor standing. They even sued Oracle for stopping to support Itanium. Now they pull the plug themselves. Oh the irony.

    2. Re:Meh by unixisc · · Score: 1

      Wonder - if HP stops building boxes using the Itanium, can't Oracle point out in their defense that they were sued for discontinuing support to a platform that HP itself is no longer supporting?

  3. I suspect it is bcos of HP's TCPA connection by jkrise · · Score: 2, Interesting

    Not a single major hardware or device maker seems ready to support Linux on non-Intel architectures. Intel, MS, HP, Cisco etc. are part of the TCPA alliance; even Linux on ARM based servers have taken a very long time to arrive.

    --
    If you keep throwing chairs, one day you'll break windows....
    1. Re:I suspect it is bcos of HP's TCPA connection by kthreadd · · Score: 4, Insightful

      IBM supports Linux on their Power based systems, and I don't think they have any plans to stop that.

    2. Re:I suspect it is bcos of HP's TCPA connection by cyber-vandal · · Score: 1

      Are you saying Itanium is a non-Intel architecture?

    3. Re:I suspect it is bcos of HP's TCPA connection by armanox · · Score: 3, Interesting

      More importantly, major Linux vendors (Red Hat and Canonical in particular, I think Novell is the odd ball on this one) don't release for Itanium. Power is still supported by many, and ARM is a rising star, but IA64 seems to be heading the way MIPS went....

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    4. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      Not to mention s390x...

    5. Re:I suspect it is bcos of HP's TCPA connection by Lumpy · · Score: 2

      Because it requires paying competitive wages to skilled people. They dont want to do that.

      --
      Do not look at laser with remaining good eye.
    6. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 1

      And its zSeries mainframes too...

    7. Re:I suspect it is bcos of HP's TCPA connection by disposable60 · · Score: 1

      I think it was a sloppy phrasing of non-x86 arch. Itanium _can_ do x86, but not as efficiently ... IIRC (it's been over a decade since I've touched one)

      --
      You're looking for quotes? See my journal.
    8. Re:I suspect it is bcos of HP's TCPA connection by lowen · · Score: 5, Interesting

      Red Hat Enterprise Linx 5 is still available and supported for IA64. At least at the moment; this will give IA64 users a Linux soure base at least until 2017.

      I have personally rebuilt CentOS 5 from source for SGI Altix, which is an IA64 box, and am running a smallish Altix (30 CPU's, 54GB of RAM) in production for data analysis. (NASA's Columbia supercomputer was an IA64 Altix with 10,240 CPU's.....)

      But RHEL 6 is indeed not available for IA64.

    9. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 1

      Not a single major hardware or device maker seems ready to support Linux on non-Intel architectures

      LOL ANDROID

    10. Re:I suspect it is bcos of HP's TCPA connection by cant_get_a_good_nick · · Score: 3, Informative

      Err, I know Slashdot doesn't allow editing of comments, but Itanium is definitely an Intel architecture. I assume you really meant to put "non-Intel-x86 compatible". It's still significant since HP helped designed the chips.

      I forgot the code names, but the first Itanium was Intel designed. Had really bad performance, landed with a thud. HP (back when they had engineers and not marketers) designed the second set, which actually was a decent chip. HP had a lot vested in this, HP slowly moving away from Itanium is very very big.

    11. Re:I suspect it is bcos of HP's TCPA connection by cant_get_a_good_nick · · Score: 2

      (it's been over a decade since I've touched one)

      And your fingertips are still burnt. (Itanium as a marshmallow and hotdog heater joke)

    12. Re:I suspect it is bcos of HP's TCPA connection by jkrise · · Score: 1

      As another poster pointed out; I intended to say non-x86; not non-Intel. In 2001; I was buying about 250 desktops from HP(Vectra VE5 if I recall right); and the marketing folks from HP sang loud praises of the 'Merced' project which later morphed into the Itanium range. The guys claimed that the architecture was entirely done by HP (primarily to support HP-UX) so I presume even though Intel did the design and production of the chips; they could not implement TCPA in that.

      --
      If you keep throwing chairs, one day you'll break windows....
    13. Re:I suspect it is bcos of HP's TCPA connection by fuzzyfuzzyfungus · · Score: 1

      Nobody supports 'Linux on ARM based servers' at the size you appear to be thinking of, because there aren't any, more or less.

      Now, at the scale where actually-available-now-at-reasonable-prices-and-with-suitable-peripherals ARM cores are available, everybody supports Linux on ARM based servers, they're just called 'NAS'es, because they are small and feeble and typically just configured for light file-serving duty.

    14. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      This site is full of some seriously confused (borderline mentally ill?) people. The vendor politics around Itanium have nothing to do with "trusted computing".

    15. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      Doubtful, as MIPS went from servers to high-end embedded.

    16. Re:I suspect it is bcos of HP's TCPA connection by armanox · · Score: 1

      I wasn't quite thinking about embedded.

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    17. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      Android is not Linux. It's Google OS where Linux is just an implementation detail that 99+ % of the users don't know or care about.

    18. Re:I suspect it is bcos of HP's TCPA connection by rubycodez · · Score: 1

      no, that emulation project was a failure, needed software modules because the hardware in the itanic had issues, could do pentium II speeds

      Linux on Itanium doesn't use x86 mode

    19. Re:I suspect it is bcos of HP's TCPA connection by rubycodez · · Score: 1

      sure it is Linux. Linux is just a kernel, what is this talk of what OS it is?

    20. Re:I suspect it is bcos of HP's TCPA connection by K.+S.+Kyosuke · · Score: 1

      It's not, but support for Android on non-Intel architectures implies support for Linux on non-Intel architectures because Android contains Linux. Has-a is sufficient for that, while is-a isn't necessary.

      --
      Ezekiel 23:20
    21. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 1

      Debian supports it, and probably will for another ten years.

    22. Re:I suspect it is bcos of HP's TCPA connection by unixisc · · Score: 1

      Can't current CentOS 6 or later be recompiled for the Altix? Or Integrity servers?

    23. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      I could be mistaken, but I recall that Linux on the mainframes is via daughter cards that run an Intel processor.

    24. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      I have never worked with zSeries machines but if I read this Wikipedia page (which is of course always right) then it's compiled directly for the machine.
      http://en.wikipedia.org/wiki/Linux_on_System_z

    25. Re:I suspect it is bcos of HP's TCPA connection by kthreadd · · Score: 1

      So if Android is Linux and Linux is just a kernel then Android must be a kernel, right?

    26. Re:I suspect it is bcos of HP's TCPA connection by WuphonsReach · · Score: 2

      I forgot the code names, but the first Itanium was Intel designed. Had really bad performance, landed with a thud. HP (back when they had engineers and not marketers) designed the second set, which actually was a decent chip. HP had a lot vested in this, HP slowly moving away from Itanium is very very big.

      Itanium floundered and failed for a few reasons, but the top one was:

      A 64bit chip that gave horrible 32bit performance. Whereas AMD offered up their Athlon64 / Opterons which were 64bit capable *and* ran 32bit applications as fast or faster then the previous chips.

      So, when you are faced with upgrading to new servers, you know you want to go 64bit at some point, but you're not ready to make the jump just yet... do you go with the Itanium (expensive, poor performance) or the Athlon64/Opteron which runs all your current applications very well and is also 64bit future-proofed.

      While Intel tried to push everyone to 64bit Itanium land, the users decided to hedge their bets and go with AMD64 solutions.

      --
      Wolde you bothe eate your cake, and have your cake?
    27. Re:I suspect it is bcos of HP's TCPA connection by wagnerrp · · Score: 1

      To be fair, an ARM based system worth running a server on has taken a very long time to arrive.

    28. Re:I suspect it is bcos of HP's TCPA connection by lowen · · Score: 1

      Yes, it probably could.

      There are a few folks that have looked at it. It will likely be difficult to do, as you'll need to bootstrap your way up from the corresponding Fedora releases, beginning, IIRC, at Fedora 9 (that's the last Fedora with IA64 support).

      So you'd probably need to start at F9, and chronologically build F10, F11, F12, and F13. C6 is based off of a mix of F12 and F13. Oh, and major things happened between F9 and F10. The tool that sits at the guts of this is called mock, but it's a bit 'fun' to get started with. 'Chronological' in this case means by source RPM build timestamp. You'd start with a minimal buildsystem, and get that up to the desired release, then build the other packages. Mock makes this sort of build relatively straightforward, but it won't hold your hand and figure out for you when you need to rebase the buildhost itself. Oh, and while Fedora does have a stated goal of being self-hosting, RHEL does not. This is part of the reason it took so long for the RHEL rebuild projects to get version 6.0 out the door.

      Complicating things is the fact that you're going to be on your own with any patches you need to make to the upstream source; when upstream (Red Hat, in this case) is supported an arch it's not too bad; but RHEL6 has no IA64 in the source, and with the kernel especially that might be hard.

      To give a rough benchmark, just getting from Scientific Linux/CERN 5u4 (the last free RHEL rebuild for IA64; CERN dropped it at that point, even though Red Hat still builds for IA64 on EL5) up to CentOS 5.8 took close to a month of build time. I've built 5.9, and have 5.10 on my plate. With IA64 support in the source it's pretty mechanical, but even then there are challenges. Like composing install media, which I've not done as yet (I've just used the SLC5.4 install media, then rebased the repos to my own C5 repos, and used yum to update over to C5).

      Again, the biggest stumblingblock to C6 on IA64 is going to be maintaining any IA64-specific source patches, both in the build spec files and in the sources themselves.

      But feel free to get involved. :-)

      Otherwise, Debian is a good alternative, but with the mainline kernel losing support for IA64, it might get tough.

      I have the manpower to maintain our own in-house CentOS 5/IA64, but not to bootstrap C6 onto IA64.

    29. Re:I suspect it is bcos of HP's TCPA connection by rubycodez · · Score: 1

      android is an OS with a linux kernel. so is Debian, for example.

    30. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      What in the world are you babbling about?

      Things you got right: the Itanium architecture did begin life as a pure HP project, and it was intended to replace HP's older proprietary PA-RISC architecture in HP-UX and other systems.

      Things you got wrong: everything else. It's like you're on another planet.

      The reason why Itanium ended up being an Intel architecture is simple. The project started in the 1990s, right about when it was becoming clear that small in-house chip fabs like HP's were on the way out, thanks to the rising costs of keeping up with new process technology. HP's OS and systems people still really wanted Itanium, so HP went looking for a chip-industry partner to co-develop and manufacture it. They also decided to be open to letting that partner sell the product on the open market, in order to amortize R&D costs over a larger sales base. That partner, of course, turned out to be Intel.

      TCPA played no role in any of that, aside from being a technology which Itanium happened to support. It's bewildering that you apparently think a lack of TCPA is somehow responsible for unavailability of Linux on Itanium. No, you dunce, that's completely moronic. First, it is supported (see above). Second, even if it wasn't, the idea that the two companies which jointly own Itanium and who are also members of the TCPA alliance can't put TCPA in their own CPU is literally crazy. Like, how the fuck do you even think that? Third, not only is TCPA available if you want it, so was Linux. It was one of the very first operating systems available on Itanium. It's actually come and gone -- Red Hat was the vendor which provided it, and Red Hat cut off support at RHEL 5 several years ago.

      Not because TCPA, either. Rather, because nobody was buying. There were vanishingly few reasons for anybody who was interested in Linux to run it on Itanium hardware instead of x86. The hoped for non HP-UX market for Itanium fizzled and died.

      And that's the Itanium story in a nutshell, and the reason why HP made this announcement. They're down to legacy HP-UX customers who are pretty much locked in to Itanium by HP-UX Itanium binaries. That customer base has been shrinking over time as those locked-in customers increasingly came to the conclusion that the pain of migrating to other software was worth getting out of needing to buy Itanium systems. HP has finally arrived at the point where all the money they're throwing at keeping Itanium alive (they've literally been paying Intel's engineering bills; Intel would have shitcanned it years ago otherwise) is clearly not worth it. So now they're trying to announce a soft landing for HP-UX customers on HP x86 hardware, in hopes of retaining at least some of them.

      But I guess it's all TCPA!!!! (OMG IT'S EVIL GET YER TINFOIL HAT)

    31. Re: I suspect it is bcos of HP's TCPA connection by nbritton · · Score: 1

      IBM supports Linux on their Power based systems, and I don't think they have any plans to stop that.

      Hardly, Red Hat dropped support for POWER with RHEL 5. AIX is the only general purpose enterprise operating system that runs on POWER. Sure BSD might support it, but I challenge you to find someone running such an operating system on $100k+ hardware.

    32. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      In the early to mid stages the 64 bit performance wasn't that wonderful either except for "embarrassingly parallel" tasks, and if you had such tasks you could usually use multiple x86 machines for it lower cost and greater flexibility.

      If you had money to burn and wanted an expensive fast non-x86 proprietary system you would have bought IBM. They'd happily sell you one and charge you for its "daycare".

    33. Re: I suspect it is bcos of HP's TCPA connection by Patch86 · · Score: 1

      Hardly, Red Hat dropped support for POWER with RHEL 5.

      Not according to the horse's mouth:
      http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=%2Fliaam%2Fliaamdistros.htm

    34. Re:I suspect it is bcos of HP's TCPA connection by TheRaven64 · · Score: 1

      Sounds a lot like the Pentium Pro - great 32-bit performance, but terrible 16-bit.

      --
      I am TheRaven on Soylent News
    35. Re:I suspect it is bcos of HP's TCPA connection by the_arrow · · Score: 1

      Well MIPS still seems to live strong, at least in the embedded world.

      --
      / The Arrow
      "How lovely you are. So lovely in my straightjacket..." - Nny
    36. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      What do you mean the way MIPS went? MIPS is alive and wriggling in many home WIFI routers (albeit declining lately) and you can buy Chinese made laptops and tablets with MIPS CPUs running Linux. The only thing MIPS is lacking is mindshare.

    37. Re: I suspect it is bcos of HP's TCPA connection by unixisc · · Score: 1

      Since IBM itself supports it, they're not dependent on RedHat - they could use any of the distros out there, fine tune it and distribute it w/ their boxes

    38. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      There are no big fat Linux servers with 32 sockets. Until just recently, there was no 16 socket Linux servers, but "Bullion" is the first. And it is not fast either, look at the benchmarks. If you need a big 32 socket server, you need to go to Unix or Mainframes, there are no 32 socket Linux servers on the market, and has never been. I invite anyone to show link to a 32 socket Linux server. Sure, IBM has compiled Linux onto their Unix server P795, and SuSE(?) has compiled Linux to the HP Unix Integrity server - but those are Unix servers. Not Linux servers. You could also compile Linux to the Oracle M6 with 32 sockets server too, or the M9000 server with 64 sockets too - but it is still a Solaris server. Not a Linux server. The biggest server on the markets, are Unix servers with 32 sockets (or even 64 sockets). The largest Linux servers, such as SGI Altix or UV1000, have 1000s of cores and are clusters running a single image kernel. SGI themselves, admit that their Linux servers are all for HPC number crunching, and not made for Enterprise work typically made on large 32 socket servers. Only number crunching clusters can use 1000s of cores, and if you see a 1000s core server, it is a cluster. Google on ScaleMP, they sell also a large Linux cluster with 1000s of cores, running a single image Linux kernel. Their server runs a software hypervisor that tricks Linux kernel into believing it is running a single fat SMP server, when in fact it is large cluster.

      Until Linux performs well on SMP 32 socket servers, Linux will never venture into big Enterprise sector. 16-32 socket SMP servers are extremely expensive. Linux 1000s of cores servers, are very cheap (because they are a cluster). No one can run SMP workloads on a HPC cluster, that is the reason no one use Linux in large SMP settings, because such large Linux servers dont exist.

    39. Re:I suspect it is bcos of HP's TCPA connection by Blaskowicz · · Score: 1

      The ARM servers will come 2014, it's called ARMv8. It brings what you find on old PCs, like 64bit computing and virtualization extensions. Look up AMD Seattle for an exemple server chip, and it surely has similar competitors. Stuff like 16 cores, four 10GbE and an incredibly fast on-die bus plus coprocessors. Else, of course ARM is mostly used in low grade NAS (even the better consumer NAS tend to use an Atom instead), cell phones, embedded and shitboxes like the Pi.

      But ARMv8 will probably be used in generic web tasks, storage, networking, rented VMs (I've always wanted a $1/month box, hell that could be a nice place to self-host the server side for Firefox OS cell phone apps you use). In fact ARM could do the front end and infrastructure stuff while x86 would be relegated to back end tasks where they're still needed (because legacy, 2x/3x higher single-thread performance or whatever). There will still be a shit tons of them but more like when the big Unix servers were used for that and the generic x86 boxes did the lighter, simpler things.

    40. Re:I suspect it is bcos of HP's TCPA connection by Anonymous Coward · · Score: 0

      IBM supports it very nicely on their Power chips.

  4. given its failure out of the gate. by serviscope_minor · · Score: 4, Interesting

    given its failure out of the gate.

    For a multibillion dollar industry, "failure" is a rather strong term. It may be declining, but it topped over $4.4bn a year at one point. That's probably bigger than AMD.

    --
    SJW n. One who posts facts.
    1. Re:given its failure out of the gate. by gsnedders · · Score: 2

      Depends on the year, assuming we're talking revenue. AMD topped that in 2000, and then in every year from 2004 onwards.

    2. Re:given its failure out of the gate. by Big+Hairy+Ian · · Score: 3, Insightful

      Faliure??? I know of firms and organisations that still haven't retired their old IBM3000 mainframes!! Itanium will be around for a while to come.

      --

      Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.

    3. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      given its failure out of the gate.

      For a multibillion dollar industry, "failure" is a rather strong term. It may be declining, but it topped over $4.4bn a year at one point. That's probably bigger than AMD.

      Hey, it's not Linux on x86, so it must be a non-existent failure.

    4. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      The company I'm at is still using an IBM 7094 to maintain the database. You wouldn't believe how hard it is to maintain code for that thing.

    5. Re:given its failure out of the gate. by ZorinLynx · · Score: 1

      Fuck the code, what about the hardware? This machine was designed in the early 60s. :)

    6. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      Failure isn't defined by numbers alone. Not too surprising this got by you since you didn't do the research on the numbers in the first place.

      itanic was supposed to take off big, and they kept talking it up with obviously wildly over-optimistic "estimates" (you know the graphs I'm talking about), only, you know, it didn't deliver, and kept on failing to deliver. It lagged orders of magnitude behind "predictions", giving it a rather unmistakable "Baghdad Bob" flavour. Thus making it a good example of a failure.

      It got so bad that intel had to bow to AMD and implement AMD's x86_64 extensions (oh irony! and then double irony on you) just to keep up.

      So I don't know by what definition it wasn't a failure, but you're welcome to try and come up with one.

      Personally I don't mind the demise of this monster. Now if only we could get over it and get some new architectures to see the light. Even bringing back PARISC and Alpha (updated designs, newer processes, higher clock speeds) looks good at this point, but I'll take MIPS or something yet different again too. In their day those were very viable, insofar as that the x86 dominance allowed it, something itanic never was. Yes, indeed, very good, Alanis.

    7. Re:given its failure out of the gate. by dj245 · · Score: 4, Informative

      given its failure out of the gate.

      For a multibillion dollar industry, "failure" is a rather strong term. It may be declining, but it topped over $4.4bn a year at one point. That's probably bigger than AMD.

      It is a complete and dismal failure if you consider Intel's plan for this architecture. It was supposed to be the next i386, the architecture all processors would use. Instead it was a huge flop in the beginning, and only redeemed itself 2 generations later. AMD snuck in their own 64 bit architecture which became the de-facto standard for all 64 bit laptop/desktop processors. Itanium became the architecture of a few supercomputers, and gained a toehold into some miscellaneous scientific computing niches.

      In this respect it is about a big a failure as "new coke". Sure, selling it may have been profitable, but it failed to meet expectations and become the Next Big Thing.

      --
      Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
    8. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      Which means it was engineered to last, because I dunno, they knew how to do things then.

    9. Re:given its failure out of the gate. by jythie · · Score: 3, Informative

      When they speak of 'failure' they are referring to fashion, not business. At least they should be.....

      Itanium was not popular, it was not fashionable, it was not sexy, it didn't have geek credit, but it made a lot of money.

    10. Re:given its failure out of the gate. by Uteck · · Score: 1

      That is nothing compared to the money it took to design and fab the chips, and most of that money was fronted by HP, http://www.wired.com/wiredenterprise/2012/02/hp-itanium/ .
      Given the production costs and the number of customers using it, so it was always a high cost chip with mediocre performance.
      Intel would rather shut down thoughs fabs and make more x86 ships which make them more money.

      --
      no .sig found Please restart your browser.
    11. Re:given its failure out of the gate. by cant_get_a_good_nick · · Score: 1

      It's all relative. Itanium was slated to be *the only* 64 bit chip, replacing x86 with a new architecture. It was supposed to be the only server chip as it cleaned up all the RISC chips out of the market. It kind of did the latter - only Sparc and POWER still really exist, MIPS, PA-RISC, and Alpha are gones.

      But the goals were high. Destroy all other chips. even x86. Not have a second vendor (no more AMD making x86 chips) meant all the money went to Andy Grove. They never did close to any of that. Based on the money poured in, and the expectations, it is a failure. Maybe not Apple Newton level failure, but it is a failure.

    12. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      It's really interesting how SPARC keeps staying in business and is even running incredibly strong again. Who would have thought 5 years ago.

    13. Re:given its failure out of the gate. by jedidiah · · Score: 2

      > Hey, it's not Linux on x86, so it must be a non-existent failure.

      Linux on x86 is a big part of the reason that it is a non-existent failure. It also didn't help that Itanic was an engineering disaster in it's own right.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    14. Re:given its failure out of the gate. by Tore+S+B · · Score: 1

      That's a lie. There are no running 7094s in the world.

      --
      toresbe
    15. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      If it "didn't have geek credit," it still had way more geek cred than x86. People unfamiliar with any chip than x86 and insecure about it, who know nothing about CPU architecture besides the marketing codename salad Intel uses to promote x86 to people who are already buying it, shouldn't make comments like this because the story of CPU's since the beginning has been "the technically worst architecture wins for a combination of stupid business reasons, both internal and external to the CPU company."

    16. Re:given its failure out of the gate. by itzdandy · · Score: 4, Informative

      It kind of did the latter

      That's not even a stretch, it's completely false. Commodity x86/x86-64 clearly did the overwhelming bulk of eliminating other architectures by offering drastically better price/performance or maybe even more importantly, bringing the minimum server configuration down sub-$1000. Before the 'Xeon' and X86-64, servers were very much over powered and over engineered for many businesses.

      Placing a $20,000 HP-UX/HPPA server in a small business and getting a baseline of 3% usage put these systems out of reach for obvious reasons. A $1000 Xeon box that performed similarly was the obvious choice. Itanium was never in the discussion and had effectively nothing to do with the decline of the MIPS and RISC server market.

      --IMHO

    17. Re:given its failure out of the gate. by sjames · · Score: 1

      Given sufficient thrust, pigs fly just fine.

      The Itanic is practically the poster child for pigs with JATOs strapped on.

    18. Re:given its failure out of the gate. by cant_get_a_good_nick · · Score: 1

      I agree that x86-64 has cleaned up and killed 64 bit RISC chips (partly by being RISC at their core, with a CISC instruction set), I think you don't remember the timelines. Remember that there was no x86-64 back then.

      Itanium came out in 2001. AMD64 (who was going to support AMD in the enterprise?) came out in 2003. The first Intel x86_64 chips came out in 2004.

      For "big iron", there was no getting away from 64 bit Apps and servers. You needed > 4GB address spaces. PA-RISC, UltraSparc, MIPS, Alpha, all were 64 bit chips. Now they had real competition with Intel. SGI first wanted to move to the "dominant" Itanium, then when it fizzled went to Xeon only after. PA-RISC by definition got moved because of Itanium. Alpha, well, that's just a mess inside of DEC/Compaq/HP. They wanted a single chip, called Itanium, instead of supporting two chip lines.

    19. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      It's a shame Alpha was assassinated by Intel, had its development continued it would probably have outperformed anything itanium had to offer, and i guess intel knew that.

      Captcha text is "aborted"...

    20. Re:given its failure out of the gate. by Grishnakh · · Score: 1

      itanic was supposed to take off big, and they kept talking it up with obviously wildly over-optimistic "estimates" (you know the graphs I'm talking about), only, you know, it didn't deliver, and kept on failing to deliver. ...
      It got so bad that intel had to bow to AMD and implement AMD's x86_64 extensions (oh irony! and then double irony on you) just to keep up.

      There's more than that. The reason AMD beat Intel to the 64-bit extensions is because Intel refused to make their x86 CPUs 64-bit, because they didn't want to affect their itanic business. Their answer to everyone demanding 64-bit support: buy an itanic! Finally, AMD came out with their own extensions, and for a little while Intel still refused to get on board, because again their answer was that you should just buy an itanic system if you needed 64-bit capabilities, and they poo-pooed AMD's 64-bit CPUs as unnecessary. They finally changed their tune when AMD's CPUs sold like hotcakes, performed great, and made them look stupid. I remember this pretty well since I worked at Intel at the time, and I remember all the propaganda they fed us about that and other boneheaded moves they made under Craig Barrett, such as the RAMBUS fiasco and the P4 Netburst architecture.

    21. Re:given its failure out of the gate. by Grishnakh · · Score: 1

      x86 architecture is actually really quite good these days, but it took a while to get there. The real architecture is hidden behind a translation layer to stay compatible with the regular x86 instructions. It's a lot like the small-block Chevy V8 engines used in today's Corvette: it was not a great design to begin with, but they kept working at it, and throwing technology at it, for decades, to the point where it actually performs quite well despite its initial design shortcomings.

    22. Re:given its failure out of the gate. by Grishnakh · · Score: 1

      That's not even a stretch, it's completely false. Commodity x86/x86-64 clearly did the overwhelming bulk of eliminating other architectures

      Nope. itanic eliminated PA-RISC and Alpha, because both those architectures were owned by HP, and HP wanted to work with intel to make the itanic and replace those older architectures, and that's exactly what happened. Alpha was canned immediately after HP bought out the remnants of DEC in Compaq, and moved all the Alpha engineers to HP and Intel to work on itanic. (Remember, itanic was a joint venture between HP and Intel.) PA-RISC was eliminated sometime later after itanic got good enough to do so. Price/performance was not that much of a factor here; HP management wanted to move to itanic for various pie-in-the-sky reasons, and they couldn't simply backtrack and dump the itanic after pouring so much money into its development, since that would make HP management look stupid.

      MIPS was indeed wiped out by x86-64.

    23. Re:given its failure out of the gate. by Grishnakh · · Score: 1

      It was assassinated by HP as much as by Intel.

    24. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      No. Itanium was a massive failure.

      It may be declining, but it topped over $4.4bn a year at one point.

      Itanium definitely did not have $4.4bn of sales, in any year.

      Perhaps you mean that Itanium systems were selling at $4.4bn per year, at their height. Only a very small fraction of that went to revenues for the actual Itanium processor.

      Since Itanium systems often sell for more than $1 million, that means that HP was selling a few thousand of those systems per year at its height. That is less than they were selling before, on their old PA/RISC processors. Also, Itanium never gained any serious traction outside of HP. Basically it was a replacement for PA/RISC.

      That's probably bigger than AMD

      That's an invalid comparison. It's an apples-to-oranges comparison. You are comparing sales of itanium systems with sales of AMD processors (not systems). If you compared sales of systems with AMD processors, to systems with Itanium processors, the AMD systems would vastly exceed the Itanium ones, in both revenues and units shipped.

    25. Re:given its failure out of the gate. by itzdandy · · Score: 1

      Nope. itanic eliminated PA-RISC and Alpha, because both those architectures were owned by HP, and HP wanted to work with intel to make the itanic and replace those older architectures, and that's exactly what happened. Alpha was canned immediately after HP bought out the remnants of DEC in Compaq, and moved all the Alpha engineers to HP and Intel to work on itanic. (Remember, itanic was a joint venture between HP and Intel.) PA-RISC was eliminated sometime later after itanic got good enough to do so. Price/performance was not that much of a factor here; HP management wanted to move to itanic for various pie-in-the-sky reasons, and they couldn't simply backtrack and dump the itanic after pouring so much money into its development, since that would make HP management look stupid.

      MIPS was indeed wiped out by x86-64.

      That may have been HP's motivation, but the market did not care and Itanium did not displace non-x86* servers, rather the availability of commodity hardware with ECC RAM and other 'server' type options. It's really a give and take of hardware getting a bit better, vendors offering server solutions on that improving hardware, and hardware vendors upping the ante again etc etc.

      In other words, had Itanium never been drempt up, the server market would look basically like it does today but with HP dropping support for HPPA right now instead of Itanium. Actually, the environment might look much different in that Oracle may have never purchased sun because sparc may have survived(as in maintained market share) having that little itanium slice of the market and butterfly effect that out to MariaDB not existing and java being less controversial.

      MIPS really killed itself IMHO. x86 certainly kavorkianed it along, but nothing came out of the MIPS architecture to compete in a timely manner. MIPS is actually quite good, but like Alpha it had the wrong gameplan. Alpha was a trendsetter and Alpha boxes were amazing (formerly admin of a cluster of ES45 machines, Digital Unix) but digital/compaq got bought by HP and lost the war.

      Not to say that x86 actually won though, the only thing x86 about and x86 CPU is that it happens to have some x86 decoders on effectively RISC core(s), so in the end RISC wins and gets no credit. MIPS (a RISC) owns the embedded router market today, ARM owns mobile, and x86 is very RISCy. Heck, the 'R' in arm used to mean RISC (still applies but the name is now just 'ARM')

    26. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      Cue the "x86 is terrible!" whiners. x86 is still the most popular, it keeps getting faster, and it's amazingly affordable. Suck it, bitch, for as shitty as it is, it's still better than everything else.

    27. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      The real architecture is hidden behind a translation layer to stay compatible with the regular x86 instructions.

      That's a popular idea. It's also pretty much bullshit. The real architecture behind the "translation layer" is still an engine for running x86.

      To understand why, you have to understand that it never was "translation" to a truly foreign language. Traditional x86 ALU instructions have two operands. The semantics of the instruction are that the two data sources are read, a computation is done which produces a single result, and that result is stored back to one of the two source operands. Nearly all x86 instructions permit one or both of the two operands to be memory. It turns out that designing a high speed execution engine to track ALU operations and memory accesses as one indivisible unit is hard, so a long while back Intel and AMD started cracking these relatively complex instructions into their component parts: ALU operations and memory accesses. These cracked operations were usually called micro-operations (uops), or something similar. Uops were and are not some kind of radically different design, they're literally the same semantics as their source x86 instructions, just split up to make a bit out of order execution engine easier to design.

      Another key reason why it's bullshit: today's very best x86 implementations have gone in the opposite direction, preserving more x86 instructions whole. They don't crack as many memory accesses off as they used to. For Intel, I believe that anything from Sandy Bridge onwards keeps most ALU + single memory read instructions together. In fact, they go even further: the front end can now fuse ALU-only and memory-only instructions from the original stream together. With a back end capable of natively handling ALU+mem ops, fusing saves one execution slot in the back end.

      It's a lot like the small-block Chevy V8 engines used in today's Corvette: it was not a great design to begin with, but they kept working at it, and throwing technology at it, for decades, to the point where it actually performs quite well despite its initial design shortcomings.

      I'm not a real gearhead but I'm pretty sure you've got the wrong end of this one too. AFAIK, the small-block V8 was a great engine relative to its contemporary competition back when it was new, and what's interesting about it in today's concept is that they've managed to keep a relatively primitive basic design (pushrods instead of DOHC, etc.) competitive with newer technology through that process of successive refinement.

    28. Re:given its failure out of the gate. by TheLink · · Score: 1

      The Titanic was considered a failure not because it didn't "top" stuff (and it did in many things). It was because it sank.

      The Itanic on the other hand was a failure out of the gate because its inevitable sinking was obvious to anyone who knew how things worked. It was destined for failure not greatness. Just because inertia from "vendor lock-in" and HP's desperate pushing kept it moving upwards for a while doesn't mean it wasn't a failure.

      Of course most didn't throw away their VMS, Tandem and HP/UX stuff when the Itanic was announced as their upgrade path. But the sane ones started plans to get off that platform. These sort of plans don't happen overnight - they take years. Getting off HP/UX might not be so hard but there were and are no cheap and easy substitutes for the other stuff. So you keep paying them till you finally get free.

      --
    29. Re:given its failure out of the gate. by prionic6 · · Score: 1

      Wouldn't a Raspberry PI be enough to emulate it at perfect speed? ;)

    30. Re:given its failure out of the gate. by TheRaven64 · · Score: 1

      Depends on what you mean by 'cleaned up'. x86-64 replaced the old RISC servers, but they died because the companies producing them stopped developing them. And that happened because they'd all bet on Itanium.

      --
      I am TheRaven on Soylent News
    31. Re:given its failure out of the gate. by unixisc · · Score: 1

      It was assassinated by Compaq before Compaq got eaten by HP. Compaq sold everything about the Alpha to Intel - in fact, Intel could have rebranded the Alpha (the same way they rebranded StrongArm to XScale) and sold it, given what they got.

    32. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      Anti-HP $hills have been sent out by Larry €lli$$on to badmouth his former enabler and business partner.

      Of course HP is still in the same general league as IBM and it doesn't matter if they sell only 10000 CPUs a year, if every single CPU handles 100 million dollars in business transactions per year. For example, Deutsche Börse ran on Solaris and VMS until recently. Then telecoms, banking, huge SAP manufactuing support installations. Itanium has been and still is a cornerstone of many data centers around the globe.

      Larry is a slimy businessman and he has absolutely no manners whatsoever.

    33. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      If you have a multi-.billion dollar corporation (e.g. Daimler, Allianz, GE, P&G or the like) funding custom development work on Itanium and you get a nice hourly rate, I guess your qualms would wither away. Muppet.

    34. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      What you people discount is the enormous strength of HP's professional services organization, brand recognition and customer relationships. In the days of PA-RISC, HP hardware was cutting-edge and a prime option for large corporations to run their databases or ERP systems. These relationships transitioned to Itanium hardware and these projects and relationships are much, much more than only the CPU.

      If you can lose 20 million a day in your manufacturing operations, you simply don't care about those cheap Dell x64 machines (that will save 5 millions over 5 years), you play safely and buy from your trusted vendor of the last 30 years, HP Co.

      THAT is how the major league IT business works. Now replace HP/Itanium with IBM/S370/390. Works also with those two.

    35. Re:given its failure out of the gate. by Anonymous Coward · · Score: 0

      The point I want to make: Multi-billion dollar operations would be insane to save a few millions in the IT business and thereby threatening the smooth working of their core business.

    36. Re:given its failure out of the gate. by sjames · · Score: 1

      I didn't discount that at all. That's the JATO that made the pig fly.

      It was fairly unpleasant for anyone under the flight path and anyone who got a good look at it knew a crash was coming.

  5. Goes along with the VMS announcement by brausch · · Score: 4, Informative

    Earlier this year HP announced the end of the line for VMS. That was certainly connected with the Itanium retirement as well.

    --
    "Almost every wise saying has an opposite one, no less wise, to balance it." - George Santayana
    1. Re:Goes along with the VMS announcement by guru42101 · · Score: 1

      I'm surprised it's still around. It was dieing when I was assisting administrating one in college 15 years ago. All they used it for was DNS, DHCP, some web hosting of minor services (DCL Script ugh!!!), and forwarding of employee addresses (first.last@abc.edu to flast1@mail.abc.edu)

    2. Re:Goes along with the VMS announcement by hughk · · Score: 1

      I think the US military has been using VMS for mission critical applications - payroll!!!!

      --
      See my journal, I write things there
    3. Re:Goes along with the VMS announcement by sinator · · Score: 1

      Also, all the health care: CHCS runs on VMS and will continue to do so through 2018 or even later, depending on the speed of the DHMSM COTS acquisition process.

      --
      Three Step Plan:
      1. Take over the world.
      2. Get a lot of cookies.
      3. Eat the cookies.
    4. Re:Goes along with the VMS announcement by bpechter · · Score: 1

      Damned shame that they killed Alpha and with that move doomed VMS. The Itanium port didn't help expand the VMS base, since there wasn't enough support to VARs to keep the support for VMS in applications. There are only two viable OS choices now.
      Windows and Linux/Unix. (And the Unix part is weakening over time due to costs vs. Linix).

    5. Re:Goes along with the VMS announcement by TheRaven64 · · Score: 1

      The funny thing about the whole story is that the reason i386 has four protection rings was to make a VMS port from VAX easier. Instead, DEC ported it to Alpha, with only two...

      --
      I am TheRaven on Soylent News
    6. Re:Goes along with the VMS announcement by operagost · · Score: 1

      Just because your university was phasing it out didn't mean the platform was dead, did it?

      --

      Gamingmuseum.com: Give your 3D accelerator a rest.
    7. Re:Goes along with the VMS announcement by Anonymous Coward · · Score: 0

      VMS still has a strong following. It's an extremely reliable O/S and platform that pretty much defines the gold standard of "Clustered" systems. It has been declining, but much slower than even HP realizes. One of it's strengths is reliability. I know several systems that do not have any HP support, but have been running continuously for over a decade.

      While dependency on Integrity (and it's shrinking market share) is crippling OpenVMS, the major factors was Compaq's and HP's lack of ability to really market it, and more recently, the movement of all OpenVMS Engineering to India. There is a good market for emulated VAX and Alpha hardware that provides continued support for OpenVMS, though. In many cases, the emulated hardware (VAX or Alpha emulators on Intel using Windows or Linux) has better performance than many of the lower end systems.

    8. Re:Goes along with the VMS announcement by dpilot · · Score: 1

      And have you ever seen any x86 software use more than 2 rings, even though it has 4?

      --
      The living have better things to do than to continue hating the dead.
    9. Re:Goes along with the VMS announcement by Tore+S+B · · Score: 1

      To put the reliability into perspective. I was speaking with a VMS sysadmin when I was 19 years old, who exclaimed that he had support contracts on cluster with higher uptimes than I'd been alive.

      It is a really, really rugged OS. The clustering has an elegance that I miss on Unices.

      --
      toresbe
    10. Re:Goes along with the VMS announcement by Anonymous Coward · · Score: 0

      Yep -- OS/2 used ring 2 for some drivers. That's one of the reasons is so hard to support under most VM products.

    11. Re:Goes along with the VMS announcement by dpilot · · Score: 1

      Used OS/2 for a while, never knew it put any drivers in ring 2. I know both OS/2 and Windows used ring0 for the kernel, and I seem to remember that one of them initially used ring 1 for userspace, then in a subsequent release moved userspace to ring 3. Aside from that early use of ring 1, I thought pretty much everything since then put the kernel in ring 0 and userspace in ring 3.

      --
      The living have better things to do than to continue hating the dead.
    12. Re:Goes along with the VMS announcement by unixisc · · Score: 2

      Earlier this year HP announced the end of the line for VMS. That was certainly connected with the Itanium retirement as well.

      They should have announced an end to VMS/Itanium with it i.e. no new sales on that. On the above subject, I guess it's good that they are finding a home for Tandem customers. Really speaking, once Alpha/MIPS were dead for HPQ, they should have migrated both VAX and Himalayas to x64 instead of Itanic. That way, their customers would have had more options whenever HP decided to discontinue VMS, or transition NonStop.

      Anyway, at this point, I think the writing is on the wall for Itanic - it's now an HP/UX only home, and that too, not anywhere near as popular as PA/RISC was. Too bad, since Itanium III was starting to look good. Intel should either reduce its power consumption, increase the cores and explore the supercomputer market w/ it, or failing that, close it down.

    13. Re:Goes along with the VMS announcement by Darinbob · · Score: 1

      You can run VMS at home using the SIMH emulator. The instructions to install it may be a bit obtuse if you lack the wall of colored manuals (not sure what the last color was, but I remember blue, then orange, then grey). However there are some online instructions for it.

      The real drawback of DCL was that it was difficult to create your own efficient command language on VMS so you were sort of stuck with it. Unix had a simpler interface and thus it spawned a large variety of command line languages and scripting languages.

      I know at university that the VMS systems could handle more students at a time than BSD Unix on the same model of VAX. Unix was originally designed around the idea of have few users on a small machine, with each user getting all the access they wanted, whereas VMS was designed for many users at a time with resource management. But it had the drawback of being proprietary and single sourced, and wasn't all that special if you put it on a single user workstation.

    14. Re:Goes along with the VMS announcement by occasional_dabbler · · Score: 1

      higher uptimes than I'd been alive.

      Thank you for this, I had no idea anything could run this long. When you think that this is twice as long as Ubuntu has been around...

      --
      "Our opponent is an alien starship packed with atomic bombs," I said. "we have a protractor"
    15. Re:Goes along with the VMS announcement by Darinbob · · Score: 1

      This was mostly about the time period that things were implemented. The ring structure had a little bit of hardware support and efficiency but was also a bit inflexible and didn't offer much to the system's programmer. So the idea of using more than two virtual memory rings or protection rings was dying out by the time x86 was on the rise.

    16. Re:Goes along with the VMS announcement by unixisc · · Score: 1

      Doesn't it work this way - the hypervisor operates in ring 0, the VM in ring 1 or 2, and everything in the VM @ ring 3?

    17. Re:Goes along with the VMS announcement by F.Ultra · · Score: 1

      Does not the supposed realibility of VMS have more to do with the hardware (VAX) than the quality of the software (VMS), afaik the VAX could hot-swap cpu:s and ram live if the hw detected a failure.

    18. Re:Goes along with the VMS announcement by TheRaven64 · · Score: 1
      Three examples from the top of my head:
      1. OS/2 used different rings for kernel, drivers, and userspace.
      2. Novell Netware (pretty much dead now, but very popular in the 386-486 era) allowed plugins to run in rings 1-2 for extra speed without being able to compromise the kernel.
      3. And, the big one, Xen in a PV environment runs in ring 0, PV guests (including dom0) run in ring 1, userspace code runs in ring 3. Ring 2 is usually unused, although it could be used by some guests.

      And if we're not counting just the original 4 rings, there are a lot of things that run in the ring -1 that the virtualisation extensions provide.

      --
      I am TheRaven on Soylent News
    19. Re:Goes along with the VMS announcement by TheLink · · Score: 1

      VMS uptime has much to do with its clustering. They are measuring cluster uptime not node uptime. The difference between VMS clustering and normal webserver/appserver clusters is VMS supported single system image clustering: https://en.wikipedia.org/wiki/Single_system_image#Some_example_SSI_clustering_systems

      Tandem on the other hand had fancier hardware stuff like pairs of CPUs that ran in lock-step with each other...

      Both of these were bought by HP but they never really did much with them. The problem also was most people don't care so much about the high availability of the entire OS, they only care about high availability of certain applications/services. And they could achieve "good enough" HA of those apps/services without buying HPs stuff.

      --
    20. Re:Goes along with the VMS announcement by hughk · · Score: 1

      Does not the supposed realibility of VMS have more to do with the hardware (VAX) than the quality of the software (VMS), afaik the VAX could hot-swap cpu:s and ram live if the hw detected a failure.

      The machines were quite solid for the time but I'm not aware of models that supported hot swapping. However individual CPUs could fail as well as memory modules and the system would gracefully degrade. When the service engineer came along, you could shuffle your users onto another cluster node and continue until the node was fixed. The file system was usually structured so that the failure of a node would not impact availability.

      --
      See my journal, I write things there
  6. Microsoft knows this by Dr.+Manhattan · · Score: 4, Interesting

    I work on a product that supports Itanium, and we have a few customer that are still using Itanium servers, who knows why. We just discovered that unless you get the top-tier developer subscription to Microsoft Visual Studio, you don't get Itanium compilers.

    --
    PHEM - party like it's 1997-2003!
    1. Re:Microsoft knows this by fuzzyfuzzyfungus · · Score: 1

      Itanium has long been a signal, a signal that says "I really do cut POs that large. Soak me."

      Now that it's niche and dying, the fun will really start. Sure, the number of customers will shrink; but the last ones to go will be the ones who will pay almost anything for one last hit before they have to port...

    2. Re:Microsoft knows this by rubycodez · · Score: 1

      no, the Itanium did have impressive specs for certain kinds of computations, database and vector numeric. but that's five+ years ago

  7. #tandem4life by Anonymous Coward · · Score: 0

    Tandem on the x86! Intel is making an x86 cell phone. You know what this means? Tandem on a cell phone! Now all we need is a touch interface for TACL.

    #tandem4life

  8. IA64 ~~ IPV6 by CaptSlaq · · Score: 0, Troll

    Now if only the IPV6 community would see the parallels between IA64 and AMD64...

    1. Re:IA64 ~~ IPV6 by Anonymous Coward · · Score: 0

      Now if only the IPV6 community would see the parallels between IA64 and AMD64...

      What parallels?

      The main problem with IPv4 is that it ran out of bits for addressing. Is this like IA-32/x86 running out of bits for (RAM) addressing?

      AMD64 added more bits for addresses (in addition to other tweaks). IPv6 added more bits for addresses as well.

      Any way you cut it, there was going to be pain when going from IPv4 to "IPng". You had to expand data structures in the packet, and there wasn't a way AFAICT to do that in a backwards compatible way. You had systems that were designed to deal with only 32b and now had to deal with more-than-32b. There was going to be breakage regardless of what design was chosen for "IPng".

      The main problem with IPv6 IMHO is that everyone is dragging their feet. I can understand the trepidation from a business/money point of view, but technically rolling out dual-stack sooner rather than later was the best way. Do it slowly over time and you can work through the issues at a leisurely pace. Now we're running against the clock and when (not if) the IPv4 counter goes to zero there's going to be a lot of problems for a lot of people.

    2. Re:IA64 ~~ IPV6 by PlusFiveTroll · · Score: 1

      I'm not really sure where you're going with that one, with dual-stack any system that can run IPv6 can also run IPv4.

    3. Re:IA64 ~~ IPV6 by Anonymous Coward · · Score: 0

      And what contrasts with IPv6 in the same way IA64 compared with AMD64?

    4. Re:IA64 ~~ IPV6 by unixisc · · Score: 1

      Precisely, and as PlusFiveTroll pointed out below, any system can be dual stack and run both IPv6 & IPv4.

    5. Re:IA64 ~~ IPV6 by Anonymous Coward · · Score: 0

      IPv6 is certainly not the only way forward and is overkill (64 bits for your local network?) for replacing IPv4 as well as being too complex. The correct solution is compression within the current 32 bits - that way you can fit many more than 4 billion addresses. I hear there's a google project on this.

    6. Re:IA64 ~~ IPV6 by Alphadecay27 · · Score: 1

      IPv6 is certainly not the only way forward and is overkill (64 bits for your local network?) for replacing IPv4 as well as being too complex. The correct solution is compression within the current 32 bits - that way you can fit many more than 4 billion addresses. I hear there's a google project on this.

      I thought you might be trolling because you can't map a 128bit address space into a 32bit space without collisions when you have >32bits of unique information to store. It looks like there is a patent on this: http://www.google.com/patents/WO2013066969A1?cl=en registered to http://en.wikipedia.org/wiki/Cable_Television_Laboratories,_Inc. not Google. They are a consortium that develops cable modem standards (DOCSIS).

      The patent is for a form of NAT which handles 1-1 mapping and allows for collisions with actual/virtual ipv4 addresses by remapping those as well. Each IPv4 device behind the cable model would get a unique IPv6 that the world can see and would see external addresses as a translated IPv4 address. Apparently it is expected to break down when the number of unique connections exceeds 33K/day. Looks like a good transitional form of NAT for consumers who are still running older systems that don't support IPv6. It is not a general solution that could replace IPv6, in fact it requires IPv6 at the ISP level.

    7. Re:IA64 ~~ IPV6 by unixisc · · Score: 1

      This looks a bit like a combination of dual-stack lite overlaid on IPv4 mapped IPv6. As you say, it needs IPv6 to even get off the ground

  9. Ah, Itanium by 0123456 · · Score: 1

    Based on the amusing idea that compilers can more easily determine which instructions can be executed simultaneously at compile time than the CPU can at run time...

    Years ago one of my friends had the misfortune to have to write code generators for a CPU which required the compiler to determine whether a previous pipelined instruction had completed before reading the result because there were no interlocks to stall the CPU if it hadn't. He could have told Intel a thing or two about trusting software engineers to schedule instructions rather than CPU designers.

    1. Re:Ah, Itanium by KirbyCombat · · Score: 1

      That would have been the i860.... Ah, the days....

    2. Re:Ah, Itanium by jimbo · · Score: 1

      Heh; I seem to recall a marketing announcement of the Merced that was practically a copy of an earlier announcement for the i860.

  10. Oh the MEMEs by ArhcAngel · · Score: 5, Interesting

    Let me count the ways
    And there was much rejoicing!
    And nothing of value was lost.

    For those saying it wasn't a failure you must look at what Intel intended Itanium for. If they had succeeded Intel would have owned the 64 bit CPU realm on the desktop with a proprietary architecture effectively eliminating any competition in the space. To succeed they had to get all popular software including Windows to be rewritten for the new processor. This was a daunting task and few were ready at the time to make the switch to 64 bit. AMD introduced the Opteron in 2003 with their 64 bit extensions for the existing x86 architecture which allowed the reuse of the 32 bit code in existence. AMD's x86-64 was well received and Intel ultimately adopted the architecture in their own processors. So yes the Itinaium failed to succeed in its intended task despite lingering for over a decade.

    --
    "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
    1. Re:Oh the MEMEs by Lluc · · Score: 4, Insightful

      If they had succeeded Intel would have owned the 64 bit CPU realm on the desktop with a proprietary architecture effectively eliminating any competition in the space.

      Realistically, Intel would have licensed the IA64 architecture to AMD or some other third party. Intel would not want to have an absolute CPU monopoly and risk government intervention. It is much better for Intel to have a barely competitive company (currently AMD) operating in the same space but not offering any kind of threat to their market position.

    2. Re:Oh the MEMEs by ArhcAngel · · Score: 1

      It's not a competition if you set the terms for your competitors. Intel doesn't care if they get their money from direct sales or licensing. In fact licensing is a sweet deal since they get paid without having to produce anything. Much like how Apple makes millions just raking in licensing fees for power cords.

      --
      "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
    3. Re:Oh the MEMEs by fuzzyfuzzyfungus · · Score: 1

      Hard to say: having a nice 64-bit address space beats the hell out of PAE; but '32-bit = 4GB of RAM or less' was always only a Windows desktop thing. Server and workstation had PAE support. Had Intel wanted a gimp around, they might have been able to get away with AMD flogging PAE gear...

    4. Re:Oh the MEMEs by dpilot · · Score: 2

      The whole license issue wasn't sufficiently covered in any of this discussion, not in TFA, not even in the Wikipedia article. Reading the Wikipedia article, ia64 seems to have been driven by HP and joined by Intel. I had thought it was the other way around.

      Intel does not own IP on ia64, nor does HP. It was done that way on purpose. The ia64 IP is owned by a separate organization spawned by Intel and HP, and that organization licenses the IP back to Intel and HP. The reason... it's cross-license-proof. Intel and HP use other comanies' patents and vice-versa - that's normal practice. Pretty much everyone has to do some measure of cross-licensing, just to be in the business. Had HP or Intel owned the ia64 IP, sooner or later it would have gotten included into some cross-licensing agreement, the cat would have been out of the bag, and competition from clones would have started. The IP holding company is a NPE, so they have no need to cross-license with anyone. (Is this the only non-troll use of a NPE IP holding company?)

      It was all done this way to avoid competition with clones. That's why I thought ia64 originated with Intel - it's an anti-clone scheme. It's also Intel solving Intel's problems, rather than their customers' problems, which was what amd64 did. This is why I really hate seeing AMD fade - it removes market pressure from Intel and lets them wander into left field again. Hopefully ARM will keep them decent.

      Also, I'd tend to echo ArhcAngel's peer comment, that it's not really competition if you can set the license terms.

      --
      The living have better things to do than to continue hating the dead.
    5. Re:Oh the MEMEs by ArhcAngel · · Score: 1

      I wasn't aware they had created an NPE corp to hold the license. I'd still call that a troll use personally.
      I too originally though Intel had come up with the architecture until I looked at the information in the link I shared.

      --
      "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
    6. Re:Oh the MEMEs by Anonymous Coward · · Score: 0

      PAE was an interim step, a hack, and anyone with a functioning forebrain knew it. It harkens back to the bad old days of EMM, EMS, HiMemory, etc. "Oh, yes, you have the memory, but it's not the right kind of memory". Then when you get the right kind of memory, "Oh, yes, you have the right kind of memory but you haven't enabled PAE". Then when you have enabled PAE, "Oh, yes, you have enabled PAE, but you don't have application support...".

      On and on the curse goes. Those who knowingly feed it deserve the Nine Levels.

    7. Re:Oh the MEMEs by fuzzyfuzzyfungus · · Score: 1

      Oh, definitely. And that would be exactly the point of the strategy I was hypothesizing about: Had IA64 actually worked, Intel would have needed to keep the FTC off their backs; but would want to scoop up as much cash as possible.

      Having AMD 'supporting' systems with large amounts of RAM would be a useful talking point when dealing with the regulators; but the practical suckitude of such support would be a useful selling point when justifying rather alarming sticker prices. Intel would have wanted to avoid a second-source for IA64 parts, even 'almost as good, really, please? Buy some?' ones; but the FTC would have likely been called into action if your only options for more than 4GB of RAM were either Intel, or something even more expensive with mainframeish features from IBM.

      All largely irrelevant (except that a lot of common Linux distros are defaulting to PAE kernels, rendering obsolete some otherwise still useful Pentium M based hardware), since IA64 mostly flopped and AMD64 and we-aren't-bitter-at-all 'EMT64' have totally crushed any reason to use weirdo hacks to support extra RAM.

  11. OpenVMS by Anonymous Coward · · Score: 0

    Went on for too long? Itanium's the platform for VMS, as in, only platform if you want new iron that runs VMS w/o emulation. Plenty "legacy" control systems run on VMS, so we'll see where all that goes.

    1. Re:OpenVMS by rubycodez · · Score: 1

      Alphas for VMS were sold until 2007, so plenty of big companies will be using non-Itanium OpenVMS for about 10 more years

    2. Re:OpenVMS by unixisc · · Score: 1

      Does anyone know the relative installed base b/w Vaxen, Alphaservers & Integrity servers running OVMS?

  12. Itanium was a legend by onyxruby · · Score: 4, Informative

    Unfortunately it became a legend for all of the wrong reasons. Billions of dollars have been sunk into it over the years and many lawsuits have been filed over it demise by vendors desperate to get out of it or force another vendor to stay in it.

    http://www.eweek.com/servers/hp-to-seek-4-billion-in-damages-from-oracle-over-itanium/
    http://news.cnet.com/Allies-pledge-10-billion-to-boost-Itanium/2100-1006_3-6031773.html
    http://www.masslive.com/news/index.ssf/2013/09/hudson_intel_plant_closing_wil.html

    Unfortunately sales never came close to the billions of dollars that have been sunk into it, and it has been that way for years:

    http://www.theregister.co.uk/2005/02/28/itanium_04_sales/
    http://www.wired.com/wiredenterprise/2012/02/hpearnings/
    http://www.zdnet.com/photos/charts-mining-itanium/21115

    I'm sure someone has a comparison of how much money has been invested compared to how much money has been made in sales. I might be mistaken, but from what I've been reading from the beginning Itanium has never come close to breaking even for hardware or software sales. Certainly companies like HP and Oracle spent millions of dollars on their lawsuit trying to get out Itanium.

    Itanium has always been nothing more than a desperate multi-billion dollar effort to break free from the chains of x86.

    1. Re:Itanium was a legend by Anonymous Coward · · Score: 0

      multi-billion dollar effort to break free from the chains of x86

      To become more beholden to the particular company that invented x86...

      The idea was sound. The compilers were never up to the task though.

    2. Re:Itanium was a legend by green+is+the+enemy · · Score: 4, Insightful

      Don't look at Itanium in a completely bad light. It was a good microprocessor architecture experiment, and had the right motivations (break free of the x86 legacy cruft, design a truly scalable architecture). A lot of useful technology was developed along the way. This technology will be incorporated into future chips. Intel is rare among large technology companies to actually take huge long-term risks, and even survive failure. We need more high-risk projects like this to develop truly breakthrough technology.

    3. Re:Itanium was a legend by Anonymous Coward · · Score: 0

      > The idea was sound. The compilers were never up to the task though.

      Uh, is that the new way of saying "the idea was obviously idiotic from the start"? Compilers are crap, always have been crap and probably for a very long time to come will remain crap, even if you ignore the cases where a compiler just can't do anything because the knowledge will only be available at runtime.

    4. Re:Itanium was a legend by Anonymous Coward · · Score: 0

      If so...how come none of it is being used? We're still basically doing a batch of kludges on top of the stuff from back in the 70's.

      I stand by my pet name... (sh)Itanium.

    5. Re:Itanium was a legend by Anonymous Coward · · Score: 0

      Uh, is that the new way of saying "the idea was obviously idiotic from the start"?
      no but if you want to spin it that way...

      Compilers are crap, always have been crap and probably for a very long time to come will remain crap
      Yeah tell that to the whole generation of RISC cpus. They had pretty cool ideas with compilers that we use to this day.

      The Itanium compilers on the other hand... There was not enough work to keep them stuffed and doing things. They probably work very well in 'do this sort of thing on 2billion items' in a tight loop. And the 'thing' is some sort of operation that is done on all 2 billion. Where it failed was if you did not have tight loops where work needed to be done. Which at that point it was spinning memory bandwidth for nop instructions.

      This sort of niche is being trounced by the GPU's. So the idea was sound. Just that the compilers were not up to it at the time. Even back when they came out they were spreading the magic sauce of 'we will fix the compilers later'. By the time they did catch up the world had passed them by with wildly cheaper and better iops per watt.

      even if you ignore the cases where a compiler just can't do anything because the knowledge will only be available at runtime
      You may want to look at more recent compilers than say 1999. They have things called JIT (which is nothing more than a special kind of compiler at runtime) and whole program optimization and profile guided optimization.

      But if we ignore 15 years of compiler design then yeah you are sorta right.

    6. Re:Itanium was a legend by Anonymous Coward · · Score: 0

      > ... and had the right motivations (break free of the x86 legacy cruft, design a truly scalable architecture).

      No it didn't. The primary motivation was to make a proprietary architecture that the competitors (AMD and Cyrix, which was still alive at the time) could not implement. This would have given Intel CPU monopoly. All engineering decisions were secondary to this goal, and that is the primary reason why it failed.

      AMD, in the meantime, came up with x86-64. Intel was pissed and for a while refused to acknowledge it. When asked about x86-64, Intel spokesman literally said "it's just x86 with a memory controller bolted on it and 6 new instructions". But the market had spoken. No one wanted Itanic but the demand for AMD64 CPUs was overwhelming. Intel grudgingly ended up implementing x86-64 except of course they had to call it some other name -- EM64T.

      So two things saved us from Intel monopoly -- the fact that Itanic was largely designed by Intel's legal department, and the fact that AMD actually implemented architecture that everyone wanted.

    7. Re:Itanium was a legend by Anonymous Coward · · Score: 0

      Except desktop GPUs also moved away from VLIW MIMD and went plain old SIMD vector instructions.
      Why? Because even for something as embarrassingly parallel as shader kernels, writing a decent VLIW compiler is *hard*.

    8. Re:Itanium was a legend by Anonymous Coward · · Score: 0

      Funny you say that, because in /. everyone blames Intel for all the drag and legacy of x86. They tried to chance architecture and it was AMD the one dragging all the legacy to avoid rewriting code.

      Now that the whole new monopoly of the ARM architecture is covering most of the mobile market, for some reason, I don't see and /.er complaining.

  13. OpenVMS? by Dimwit · · Score: 1

    Looks like it's the end of the line for OpenVMS as well.

    I would pay good, American money, to have OpenVMS open-sourced instead of just languishing like other DEC OS's. Why can't RSTS/E or RSX-11 be free? What could that possibly cost HP? Same with OpenVMS at this point. It's a great system, and I would love to see it available to average joes.

    Someone who isn't as lazy as I am should start an "Open Source OpenVMS!" petition.

    --
    ...but it's being eaten...by some...Linux or something...
    1. Re:OpenVMS? by fuzzyfuzzyfungus · · Score: 1

      HP's secret, secondary, mission statement requires them to acquire and kill good technologies. It's the rules. In rare cases of dire necessity, they are allowed to spin them off; but that is frowned upon.

    2. Re:OpenVMS? by rubycodez · · Score: 1

      big problems with that, there are 3rd party proprietary wares in there, it can never be fully open sourced

    3. Re:OpenVMS? by unixisc · · Score: 1
    4. Re:OpenVMS? by jon3k · · Score: 1

      As a 3Par customer, I couldn't agree with you more.

  14. Bye Itanium by ErichTheRed · · Score: 1

    I'm sure HP has been staring this one down forever, saying "We sunk all this money into Itanium, there's no way we can abandon it." In fact, if you look at the documents from HP's lawsuit that Oracle helpfully put up on their website, you can see internal discussions of their intention to port HP-UX to x86 and the fact that they're basically paying Intel to keep developing Itanium processors for them.

    Itanium was an interesting idea, and the only way to get 64-bit non-Sun, non-IBM hardware until the Opteron came out. But it's a really good example of a technology hanging on way past the point where it's relevant.

    I wonder if they've inadvertently sent OpenVMS to the old folks' home by doing this...unless they're planning to port OpenVMS to x86. I know there's plenty of legacy OpenVMS stuff out there, but who knows if those customers would be willing to finance a port by buying machines from HP?

    I also wonder if at least some of the ProLiant line is going to get that awesome RAS (Reliability, Availability, Serviceability) that NonStop and the Itanium boxes have. That would be cool.

    1. Re:Bye Itanium by fuzzyfuzzyfungus · · Score: 1

      I don't doubt that it'll cost you, plenty, to have Intel not laser off their bits and HP not gimp their half of things in firmware; but my understanding is that Intel has every interest in looting Itanium's corpse for the interesting bits and offering those on (high end) Xeon SKUs.

    2. Re:Bye Itanium by Anonymous Coward · · Score: 0

      Itanium was [...] the only way to get 64-bit non-Sun, non-IBM hardware until the Opteron came out.

      Said a different way, at the time Itanium came out, x86 was the only major CPU without 64-bit pointers, for some values of "major". To some people, x86 wouldn't be included in the category "major" just because it was sold into lots of desktop garbage.

      x86 has come a long way and may be objectively efficient now, but it is a sloppy trashy instruction set, and at the time it was behind other architectures on multiprocessor features, iommu's, and probably a bunch of other stuff I don't understand. It's still unable to benefit from high-quality compilers as much as all the dead high-end cpu architectures.

    3. Re:Bye Itanium by rubycodez · · Score: 1

      not an issue, HP has already said OpenVMS is dead, support only from now on

      Meg said in June 2012 HP/UX will be ported to x86

      seems obvious HP is planning on killing Itanium totally, soon

    4. Re:Bye Itanium by Agripa · · Score: 1

      I'm sure HP has been staring this one down forever, saying "We sunk all this money into Itanium, there's no way we can abandon it."

      This does not have to be attributed to the sunk cost fallacy. The economics could simply be, "Supporting Itanium at this level will yield the lowest loss."

  15. I do often wonder what the point of Itanium was. by ZorinLynx · · Score: 1

    Did Itanium have any performance advantage over x86_64? It certainly didn't have a price advantage, if anything it was horrendously expensive for the performance you got.

    We only have a SINGLE Itanium based server here, purchased more out of curiosity than anything else, years ago when the platform was new. There's nothing special about it whatsoever.

    I keep thinking the platform should have been declared a failure years ago, unless there was some specific thing it was really good at that I'm not aware of...

  16. That wasn't Itanium's intended task by Anonymous Coward · · Score: 0

    It's intent was to kill DEC's Alpha chip. In that it succeeded.

    1. Re:That wasn't Itanium's intended task by PlusFiveTroll · · Score: 1

      Other then it pushed Alpha in to AMD's hands giving birth to the Opteron, Intel snatched defeat from the jaws of victory there.

    2. Re:That wasn't Itanium's intended task by Anonymous Coward · · Score: 0

      Alpha was a benchmark champ, but it was not a commercially successful platform & DEC was going under.

      It's real intent was to take on IBM, and in that role it failed.

    3. Re:That wasn't Itanium's intended task by Agripa · · Score: 1

      I would attribute the failure of MIPS as well which was used in workstations to Itanium.

  17. Re:I do often wonder what the point of Itanium was by Anonymous Coward · · Score: 0

    It's point was that it came out before the AMD x86_64, so if you adopted early how can you even compare.

  18. John Titor through Stein's gate. by Anonymous Coward · · Score: 0

    > How hard it is to maintain code for that thing.

    It's that hard. That company (hint: US gov't) actually had to hire a time-travelling confederate soldier of fortune to fetch an 1975 era IBM 5100 desktop debug system of that platform for them them. No kidding!

  19. And that's what they killed the Alpha for... by Anonymous Coward · · Score: 1

    Leaving us with the crummiest architecture of all contenders as the market leader.

    But why should hardware have it better than software?

  20. Not so fast. by attemptedgoalie · · Score: 2

    Until there is a supported COBOL environment in Linux, HP-UX on Itanium will be around for a long time.

    I work in the power industry, and we use some very specific applications that are only available on HP-UX and AIX. HP-UX is by far their largest install base.

    These apps are used by the power plants/coal mines for everything. As you'd expect, there are very few applications that are certified for use by the power industry that meet the regulations. The one we use will begin supporting LDAP instead of NIS next year.

    There's no incentive for new players in this software market due to the small number of potential customers and the massive trust curve they'd have to meet to make somebody switch.

    We're one of the reasons there's a pretty long road map for Itaniums and HP-UX.

    --
    My mom says I'm cool.
    1. Re:Not so fast. by rubycodez · · Score: 1

      what!!??? The mainstream COBOL compilers have been available on Linux for over a decade: MicroFocus COBOL and Fujitsu NetCOBOL,

    2. Re:Not so fast. by attemptedgoalie · · Score: 2

      And yet ABB won't port their HP-UX app over. We use MicroFocus on UX, so it should be easy.

      But no.

      --
      My mom says I'm cool.
    3. Re:Not so fast. by rubycodez · · Score: 1

      but it only depends on how HP views the market, 80-90 percent of HP Itanium do so to run Oracle on "big unix" . Your power and mining companies that are bound to it may not be enough of a chunk to influence HP. The big "energy" company I used to contract for used IBM Mainframe software for their fleet of power and natural gas production plants.

    4. Re:Not so fast. by evilviper · · Score: 1

      Until there is a supported COBOL environment in Linux, HP-UX on Itanium will be around for a long time.

      Even HP doesn't believe that. Sorry.

      We're one of the reasons there's a pretty long road map for Itaniums and HP-UX.

      That road map ends in a few years, or 1-2 Itanium generations. Maybe you call that "a long time" but I wouldn't.

      You've got several years to work out an alternative, and you'd be foolish not to do so.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  21. HP/UX still not ported by rubycodez · · Score: 1

    when HP/UX x86-64 port is out, then Itanium2 will be dead

    1. Re:HP/UX still not ported by fuzzyfuzzyfungus · · Score: 1

      when HP/UX x86-64 port is out, then Itanium2 will be dead

      Which happens first: HP/UX gets ported to x86, or Xeons pull far enough ahead of now-stagnant Itanium2s that somebody can release a (probably very expensive) Itanium VM that runs at adequate speed?

    2. Re:HP/UX still not ported by Anonymous Coward · · Score: 0

      I've always wanted to run the worst unix on the worst CPU architecture, and now it will be possible. But, is there any way I can pay more to do it?

    3. Re:HP/UX still not ported by rubycodez · · Score: 1

      pfft, you haven't been around. SCO Open Desktop was the very worst.

    4. Re:HP/UX still not ported by rubycodez · · Score: 1

      oh it's already ported in HP's labs, Meg Whitman said it would happen last June 2012

    5. Re:HP/UX still not ported by unixisc · · Score: 1

      Not needed - if people have to migrate, they can migrate from one Unix to another as well. HP just has to migrate customers from HP/UX-Itanic to Lintel, and they'll be just fine. Itanium is already dead w/ this last move.

    6. Re:HP/UX still not ported by rubycodez · · Score: 1

      it is needed for users of proprietary apps that have hp-ux-isms in them. these will be apps that move money and have man-decades of code in them

    7. Re:HP/UX still not ported by unixisc · · Score: 1

      So was OSF/1//Digital UNIX//Tru64. But HP didn't port it to x64 or even Itanic - they simply killed it.

    8. Re:HP/UX still not ported by rubycodez · · Score: 1

      not quickly, there were years of overlap (osf/1 finally stopped being sold in 2010 and supported till 2012). and HP/UX is alive, with updates, new versions.

      Not my favorite Unix either, but I don't think it will be quickly killed.

    9. Re:HP/UX still not ported by rubycodez · · Score: 1

      just as an interesting bit of history, Itanium port of OSF/1 did exist briefly in 1999 at Compaq, but project killed. http://www.tgdaily.com/technology/19507-compaq-tru64-unix-runs-on-intels-merced-simulator

  22. Re:Netcraft Confirms It by Tridus · · Score: 1

    Ah, classic.

    --
    -- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
  23. 15-core E7 v2? by ArcadeMan · · Score: 1

    What are the people at Intel thinking? Where did they get 15-core from? Are they making a 16-core CPU knowing there's always going to be one bad core? Why not make a 17-core CPU instead? 15-core seems odd, it's always been 1,2,4 or 8 cores AFAIK.

    1. Re:15-core E7 v2? by roothog · · Score: 2

      It's just a grid of cores on the chip layout. Nothing wrong with a grid that's 3x5. A 2-dimensional grid does not force the number of cores to be a power of 2.

    2. Re:15-core E7 v2? by kry73n · · Score: 1

      Expecting that one core will have a defect and can be disabled is a too long shot IMHO, usually a defect is more likely to occur in the big areas like caches that cannot be easily be deactivated. My take on this is that 15 is probably just the number of cores that'll fit on the DIE.

    3. Re:15-core E7 v2? by ArcadeMan · · Score: 1

      A grid does make sense, it's just that they went from single core to dual core to quad core and then eight cores. I thought it needed to be a power of 2. You know, computers and all.

  24. Re:I do often wonder what the point of Itanium was by afidel · · Score: 1

    HP had Intel put a ton of RAS features that are needed for the Nonstop and Superdome lines into the Itanium chip, in addition it ran modified 64bit code originally targeted at Alpha, MIPS, and NonStop processors, something which couldn't be done with x86. Basically it was a way for HP to jettison all the legacy hardware from their acquisitions over the years and merge them into one "commodity" chip that they could buy from Intel.

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  25. Now how am I... by cephus440 · · Score: 0

    ... going to write FORTRAN 77 code in OpenVMS? No seriously, what's OpenVMS going to do?

  26. Design by Comittee by kent.dickey · · Score: 4, Interesting

    IA64 started as an HP Labs project to be a new instruction set to replace HP's PA-RISC. VLIW has a hot topic around 1995. HP Labs was always proposing stuff and the development groups (those making chips/systems) ignored it, but for some reason this had legs.

    The HP executive culture is: HP hired mid-level executives from outside. They would then do something big to get a bigger job in another company. A lot of HP's poor decisions in the last 20 years can be directly traced to this culture. And there was no downside--if you failed, you'd go to an equivalent job at another company to try again.

    So enterprising HP executives turned HP's VLIW project into a partnership with Intel, and in return HP got access to Intel's fabs. This was not done for technical reasons. Intel wanted a 64-bit architecture with patents to lock out AMD, and would never buy PA-RISC. So it had to be new. HP was behind the CPU performance curve by 1995 due to its own internal fab not keeping up with the industry due to HP not wanting to spend money. So HP could save billions in fab costs if Intel would fab HP's PA-RISC CPU chips until IA64 took off. So, for these non-technical reasons, IA64 was born, and enough executives at both companies became committed enough to guarantee it would ship.

    For a while, this worked well for HP. The HP CPUs went from 360MHz to 550MHz in one generation, then pretty quickly up to 750MHz. I thought IA64 would be canceled many times, but then it became clear that Intel was fully committed, and they did get Merced out the door only 2 years late. IA64 was a power struggle inside Intel, with the IA64 group trying to wrest control from the x86 group. That's where the "IA64 will replace x86" was coming from--but even inside Intel many people knew that was unlikely. Large companies easily can do two things at once--try something, but have a backup plan in case it doesn't work.

    But IA64 as an architecture is a huge mess. It became full of every performance idea anyone ever had. This just meant there was a lot of complexity to get right, and many of the first implementations made poor implementation choices. It was a bad time for a new architecture--designed for performance, IA64 missed out on the power wall about to hit the industry hard. It also bet too heavily on compiler technology, which again all the engineers knew would be a problem. But see the above non-technical reasons--IA64 was going to happen, performance features had to be put in to make it crush the competition and be successful. The powerpoint presentations looked impressive. It didn't work out--performance features ended up lowering the clock speed and delaying the projects, and hurting overall performance.

    1. Re:Design by Comittee by UnknowingFool · · Score: 1

      Also the Itanium fiasco was the beginning of the SCO-IBM issue. At the time, all the players thought Itanium would be a major server architecture. Santa Cruz and IBM collaborated to bring Unix to Itanium in Project Monterrey. However, Intel was late and by the time the chips were ready, many players had doubts. IBM completed their portion but saw that the future was Linux instead of Unix. Santa Cruz did not make a big deal about it until Darl McBride took over as CEO and used the failed collaboration as an excuse to sue IBM.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    2. Re:Design by Comittee by unixisc · · Score: 1

      As I mentioned above, HP would have done a lot better by simply selling Intel the entire PA-RISC, along w/ patents & everything. Intel would have gotten a CPU which at its top end on Intel's own fabs was competitive w/ the Alpha, and support from HP/UX, Linux and BSD. They could then have either worked w/ Microsoft to add Windows XP 64-bit support, or failing that, just worked w/ Apple on making it an OS-X platform (NEXTSTEP was ported to PA-RISC, remember?)

      Also, as it turned out, VLIW may have been theoretically perfect, but RISC was what was practically optimal. Both the Pentium & Itanium lines prove it.

    3. Re:Design by Comittee by kent.dickey · · Score: 1

      You would have made a terrible HP executive. Maintaining and growing a profitable business gets you nowhere--no one wants to make a person like that CEO of a smaller company.

      You gotta shoot for the moon and miss, and fail upwards slightly. Succeed, and you fly upwards to CEO of a large company. Most silicon valley CEOs just got lucky at some point in their life. Too bad luck doesn't repeat like skill.

      And there's no way Intel would have bought PA-RISC. They needed the cover of developing something new. Basically, any deal with Intel would have gone badly for HP, and many at HP knew it. It was a short term boost (before IA64 shipped) at the expense of long-term business. Intel at the time wanted to go after the RISC server market, they wanted some of that money for themselves, by creating chips that they could sell to HP competitors to keep HP under control. If IA64 took off, it still would have gone badly for HP, in that HP would have more competitors than ever selling the same chips they were. At least IA64 now is squarely aimed at expensive servers, and HP doesn't have many IA64 competitors.

      Lots of people think IA64 was just a big fiasco done by stupid people. It was a smart ploy to crush Unix servers by Intel (who would have been happy if IA64 worked as well, so win-win). On that score, it was very successful.

    4. Re:Design by Comittee by unixisc · · Score: 1

      The reason HP doesn't have many IA64 competitors is that the CPU itself was a boondoggle. If Itanium had turned out to be everything it promised & more, you'd have seen everything migrate to it - Windows, Solaris, Unixware, Linux, BSD, IBM OSs and everything else. SGI would have been successful w/ the Altix, and you would have seen Itanium workstations from everybody - Dell, HP, Compaq (while it lasted), Sun, and who have you.

      I was talking w/ benefit of hindsight. Today, Itanium hasn't done squat for HP, and in the process, HP lost its HP 9000 PA-RISC workstations betting on it. Had HP sold PA-RISC and Intel bought it, then today, HP would be buying a CPU that had a huge legacy software base - HP being big in not just servers, but Unixstations as well. HP/UX would still be big, and HP would have had a Linux platform all its own and would have been competing only w/ IBM (since Oracle doesn't promote OEL on SPARC). Remember, the reason HP did any deals w/ Intel in the first place is that it was getting too expensive to maintain their own CPU, which is why they did this joint project w/ Intel, after acquiring VLIW research companies like Multiflow & Cydrome. Intel was to design & fab their chips, which HP would just then buy, being one of several customers. With selling PA-RISC, the same would have been achieved, but w/o sinking HP's legacy Unix line of workstations. Also, unlike Itanium, PA-RISC was already competitive against the Alpha & would have held its own against the Core line as well: Intel could have created multi-core PA-RISCs just like they had multi-core Pentiums.

      Also remember that one of Intel's initial goals was to wipe out x86, and AMD w/ it. They did not want to do x64, particularly when Microsoft made it clear that anything they did had to be AMD-64 compatible. They were pretty much dragged kicking & screaming into 64-bit CISC, due to the Itanum fiasco. Had Itanium or an Intel owned PA-RISC been a success, Intel could have abandoned the x86 market and gone ahead w/ a fully patented CPU for 64-bit.

    5. Re:Design by Comittee by evilviper · · Score: 2

      IA64 was a power struggle inside Intel, with the IA64 group trying to wrest control from the x86 group. That's where the "IA64 will replace x86" was coming from--but even inside Intel many people knew that was unlikely. Large companies easily can do two things at once--try something, but have a backup plan in case it doesn't work.

      Except Intel DIDN'T have any backup plans! 32-bit memory limitations had been a problem for quite some time, and PAE was getting old. Intel's only path to 64-bit was Itanium.

      It's immensely lucky for Intel that AMD had a different plan. AMD's path to 64-bit became Intel's path to 64-bit when Itanium floundered, and Intel has been immensely successful with it. Companies that were paying big bucks for proprietary 64-bit systems up and switched to Intel's x86-64 chips, and the world doubled-down on x86 instead of picking one of the alternative architectures and getting economies of scale going for some other chip maker.

      What's happening now with Intel versus ARM could well have happened back in 2005 over the lack of 64-bit memory addressing. MIPS, SPARC, Alpha, or POWER were all viable competitors that could have started eating Intel's server market share. Instead, x86-64 got its foot in the door.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    6. Re:Design by Comittee by Anonymous Coward · · Score: 0

      HP killed Alpha to keep Itanium alive...

      That still pisses me off

      meh, get offa my lawn you damn kids!

    7. Re:Design by Comittee by Anonymous Coward · · Score: 0

      For me, and I'm sure many others, Itanium was also closely linked to several other Intel initiatives that failed big time. They were:

      Rambus DRAM
      Slot 1

      There may have been others but these were the high profile ones. It gave me some confidence that any vendor in this market sector, no matter how big or influential, could be brought to heel by a determined group of partners. Just because it's the 900 pound gorilla's idea doesn't make it a good idea.

    8. Re:Design by Comittee by Anonymous Coward · · Score: 0

      Well, HP would have had to respond intellgently to the "rise of the cheap beige box". I am not sure they could have done that wihout a strategy of "cheap, beige PA RISC box". But that implies a transformation from expensive+low numbers+speciality applications ==> cheap+high volume+commodity applications.

      HP would have had to ride the armored chevalry charge right into the camps of Microsoft, Intel, Oracle and SAP. Instead they chose to ride into the sunset while gobbling up as much minicomputer and semi-mainframe business was left. MBA types cannot think it terms of technology warfare; they think in terms of "incremental fine-tuning of existing business". But the mini and semi-mainframe business is slowly dying or is already dead. The expensive workstations are dead. Google and FB run massive systems on beige boxes. Admitting defeat and riding into the sunset wasn't the worst option.

    9. Re:Design by Comittee by unixisc · · Score: 1

      But Itanium was supposed to be both - the cheap CPU that would replace x86, as well as the high performance CPU that would replace PA-RISC, and knock off Alpha, POWER, SPARC and everything else. VLIW was supposed to be the silver bullet - being minimal on hardware, manufacture would have been cheap, and given the perfect (elusive) compiler, performance would have been great. HP wasn't thinking about going from expensive/low to cheap/high - they were probably going for market segmentation using just 1 architecture.

      Once Merced failed and Intel was forced to embrace x64, that should have been the point to change strategy. By then, Compaq had already sold Intel everything about the Alpha, so that was one choice they had. Another would have been to buy off PA-RISC from HP, and fine tune that to different segments - low power, high performance, customizable cores & what have you. That way, Intel would have had a proprietary platform which wouldn't be starting from scratch, but which they could have grown. Of course, that too would have struggled against x64, so a better option might have been to dump Itanium altogether.

    10. Re:Design by Comittee by Anonymous Coward · · Score: 0

      if you have too many crown jewels you really need to crush some of them. MBA 101.

  27. Re:I do often wonder what the point of Itanium was by 0123456 · · Score: 2

    Itanium would have allowed Intel to dump all the x86 baggage and move the world to a Brave New Shinier CPU that was 64-bit and appeared to offer substantially better performance.

    And it would have made them sole supplier for the mainstream CPU market, taking out AMD and the other clone x86 makers.

    Unfortunately, the early compilers sucked and x86 emulation really, really, really sucked, so no-one with a big investment in x86 software was going to make the switch. If I remember correctly, it was also years late, so performance that would have been impressive at the initial release date had become 'meh' by the time it actually hit the market.

  28. Good... Let it die. by Anonymous Coward · · Score: 0

    The (sh)Itanium was a boondoggle for Intel, HP, and others- more that it's execution was so flawed from the get-go than anything else.

    Time to let it die and pour effort into something with better legs. MIPS and ARM come immediately to mind as good front-runners if you're going the "ditching X86" route. X86 probably ought to go the same route. While it's "fast" it's because all the effort that could've been put into real performance enhacnements went into kludging the beast. If you put the same effort into either of the currently extant usable performance RISCs, you'd get even higher levels of performance with less power consumption (Though more than with the current MIPS and ARM answers...).

  29. NonStop by kbahey · · Score: 1

    For those who don't remember.

    NonStop used to be Tandem, whic was acquired by Compaq, which got acquired by HP.

    Tandem had proprietary hardware, proprietary operating system, and even proprietary languages. It was big in high availability stuff, like bank networks running ATMs, ...etc.

    1. Re:NonStop by sconeu · · Score: 1

      It was big in high availability stuff, like bank networks running ATMs, ...etc.

      It still is.

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    2. Re:NonStop by unixisc · · Score: 1

      Tandem was MIPS based, which was the most widely adapted RISC platform at one point in time - SGI, DEC, NEC and a few others made computers based on it.

    3. Re:NonStop by Anonymous Coward · · Score: 0

      I remember demos where cpus could fail but a NonStop machine just kept running.

      What's powering those applications where the NonStop used to be ?

    4. Re:NonStop by baegucb · · Score: 1

      Tandem was awesome for where I worked, Power failure (circa 1999 in Seattle) and every other computer failed. It stayed up. Weird OS though.

    5. Re:NonStop by klui · · Score: 1

      You've gone that far, might as well finish the loop: Tandem was started by HP employees whose product was two HP mini computer systems running in tandem.

  30. Re:Netcraft Confirms It by Anonymous Coward · · Score: 0

    less than a fraction of 1 percent

    99999/100000 is a fraction, so are you saying it is now 99.998%, which rounds up to 1%?

  31. Unix choices for Itanic by unixisc · · Score: 1

    Linux ports of just about every major CPU exists - SPARC, MIPS, Power/POWER, PA-RISC, Alpha, Itanic, in addition to x64. Main issue is that of these, Alpha, PA-RISC and MIPS V are dead, and of the remainder, current Linux distros have dropped support. Red Hat, for instance, supported SPARC at one time, but no longer does. IBM supports Linux on POWER, which is why it's there. HP pushes mainly HP/UX for Itanium, aside from legacy customers who bought Integrity servers for VMS or NonStop. As a result, most Linux distros are x64 only.

    If one has an Itanic box - the only one I know of is the Integrity line from HP which they are converting now to x64 - then the only choice as far as Linux goes is Debian, which never retires any CPU. Or, if one prefers the BSDs, one can go w/ FreeBSD. Other than that, w/ the Integrity, one can go HP/UX, and w/ other Itanic boxes, such as ex-SGIs, one is stuck w/ Linux or FreeBSD.

    1. Re:Unix choices for Itanic by Grishnakh · · Score: 1

      I wonder how long the Linux kernel will continue to support all these other CPUs however. They've already dropped support for i386, since it's so ancient. I wouldn't be too surprised to see them drop support for some of the other really ancient ones too, such as Alpha. Heck, I'm surprised they haven't dropped i486 support by now. There's no telling if some of that code even works any more; I seriously doubt much of it ever gets tested since no one uses these old systems any more.

      then the only choice as far as Linux goes is Debian, which never retires any CPU

      Except i386; Debian is bound by what the upstream kernel supports.

    2. Re:Unix choices for Itanic by jonwil · · Score: 1

      Just as long as they dont drop x32 support for my Pentium 4 Gentoo box...

    3. Re:Unix choices for Itanic by Grishnakh · · Score: 0

      It'd be better for everyone if they did drop support for the P4. It's a horrible processor, and you really should get rid of it and get something newer. You'll recoup the costs in a few months from power savings very quickly.

    4. Re:Unix choices for Itanic by jonwil · · Score: 1

      I dont use the box in question enough for the power savings to matter. (my last power bill was only $1.78 per day and that covers a lot more than my Gentoo box)
      Mostly I only turn it on to do the semi-regular emerge runs or (more usually) to do development/compiling for my Nokia N900 phone.
      If I had any spare cash I would replace my Core 2 Duo main box with a Core i7 and then turn the Core 2 Duo into a Gentoo box but I am unemployed right now and cant afford an upgrade.

    5. Re:Unix choices for Itanic by Grishnakh · · Score: 1

      Yes, if you only power it on occasionally, the power savings won't be significant. I was assuming you kept it on all the time.

  32. Re:Once you go x86 by unixisc · · Score: 3, Interesting

    Once this line goes x86, how are they different from anybody else - their own ProLiant line, or top end servers from IBM or Dell? Also, are they planning to migrate HP/UX to x64, or will they simply migrate HP/UX customers to Lintel (Linux on x64)? If it's the latter, their customers have probably beaten them to it by probably more than a decade

    So once this line is x64, there will be nobody who's making Itanium servers, will there? Or will it be a China only CPU - w/ customers like Huawei? So does that mean that Intel will finally put the Itanic out of its misery?

  33. MIPS by unixisc · · Score: 1

    Those were 2 different MIPS line. MIPS V was what went into servers from SGI, and got replaced first w/ Itanic, and then w/ x64. The MIPS that goes into high-end embedded or even low end embedded is MIPS IV and III (R8000 & R4x00)

    1. Re:MIPS by K.+S.+Kyosuke · · Score: 1

      MIPS V was what went into servers from SGI

      ...while Wikipedia says that "MIPS V implementations were never introduced"...?

      --
      Ezekiel 23:20
    2. Re:MIPS by unixisc · · Score: 1

      MIPS V was R10000 and above - what SGI used in Onyx, Oxygen & other such workstations/servers running Irix. MIPS IV was R8000, MIPS III R4x00, MIPS II R3000 and MIPS I R2000(?)

    3. Re:MIPS by Dahan · · Score: 2

      No, Wikipedia is right... as Section 1.1 of the MIPS R10000 Microprocessor User’s Manual says, "MIPS has defined an instruction set architecture (ISA), implemented in the following sets of CPU designs: MIPS IV, implemented in the R8000 and R10000"

      The R10000 is MIPS IV, not MIPS V

  34. Layoffs coming soon? by billcarson · · Score: 1

    Everyone seems to be cheering at this event, but it seems to me HP just wants to close down some of its NonProfitable(tm) divisions.
    First VMS, now this. This won't end well.

  35. My favorite Itanium chart by AcidPenguin9873 · · Score: 1

    Well, it may be multi-billion-dollar industry, but it spectacularly failed to meet its sales projections. My absolute favorite Itanium sales chart can be found here. Granted some of those initial projections were crazy stupid. But it fell short of even the much more modest, revised projections from 2002 and 2003.

  36. Alpha, PA-RISC & Intel by unixisc · · Score: 1

    Damned shame that they killed Alpha and with that move doomed VMS. The Itanium port didn't help expand the VMS base, since there wasn't enough support to VARs to keep the support for VMS in applications. There are only two viable OS choices now. Windows and Linux/Unix. (And the Unix part is weakening over time due to costs vs. Linix).

    I fully agree w/ this. Compaq would have done better keeping the Alpha, and HP should have sold Alpha to someone other than Intel. Alpha would have been a perfect platform for 64-bit Windows, in addition to OpenVMS. HP turned out to have made a bad call in deciding to migrate from PA-RISC to Itanium: if PA-RISC was expensive to design & maintain, it would have been cheaper for them to simply sell it to Intel (which was already fabbing it anyway) and ask Intel to design & make it for them. Intel could then have competed at the high end against POWER & Alpha w/ PA-RISC, while still having x86. They wouldn't have had to license x64 from AMD, but instead, since PA-RISC was already well supported by HP/UX & Linux, they could have either promoted PA-Linux or gotten Microsoft to port 64-bit Windows to the platform. That way, they would have gotten a successful architecture exclusively their own, w/o the failure that came w/ the Itanic.

  37. Re:I do often wonder what the point of Itanium was by unixisc · · Score: 2

    No, it didn't. Reason HP went w/ it was the perception that since RISC was faster than CISC, which got proven by Intel building in all sort of RISC based concepts into the Pentium, which included moving some of the complexity of a CPU to compilers, VLIW could be faster as a result of moving all of the complexity of a CPU - even a RISC CPU - into the compiler.

    Main issue w/ that, even before the project started - was the fact that in VLIW, since everything - register renaming, speculative execution - is moved from the CPU to the compiler, w/ every CPU generation, unless all you do is bump up the GHz as well as the cache, any change to a CPU would necessitate recompilation of existing software to get any performance improvement: running existing binaries would show no improvements whatsoever. That alone should have killed the idea.

    As it turned out, RISC was an optimal spot b/w CISC & VLIW. While Pentium adapted a lot of RISC concepts like superscalar execution, expanded register sets and branch prediction, Itanium too smuggled in RISC practices like Register Renaming, which is supposed to be gotten rid of in VLIW. In the meantime, RISC CPUs such as Alpha 21364 & POWER adapted some VLIW concepts such as smarter compilers that extract more parallelism, MIMD operations and so on. So HP would have done better in selling Intel the PA-RISC and Intel improving that rather than starting out w/ this VLIW concept.

  38. Witanic by unixisc · · Score: 1

    Is Windows 2003 server on Itanic native, or does it run under x86 emulation?

    1. Re:Witanic by kthreadd · · Score: 1

      Windows on IA-64 has always been running native.

  39. Re:I do often wonder what the point of Itanium was by Darinbob · · Score: 1

    Itanium was planned before 64-bit versions of x86 arrived. So you've got the question backwards: what were advantages of x86_64 over Itanium?

    Itanium was trying to ditch x84. Just like many people, Intel also hated the x86 and hated being tied down to it with a never ending backward's compatibility ball and chain. Meanwhile RISC was doing great, and all the decent workstations out there were running on RISC chips whereas x86 was stuck on lower end PCs, and compilers were getting good enough to get decent performance out of RISC as well. So that was the plan: get a "modern" CPU and remove reliance on the old stuff that wasn't scaling up.

    What happened though was getting the 64 bit extensions to x86, allowing larger memory spaces without breaking compatibility with Windows, plus advances in Pentium allowed them to get RISC like performance under the hood while having a CISC decoder on top. Over time the 64-bit extensions expanded and became more useful as well, until there was a full 64-bit architecture. The drawback of course was that it's essentially a 64-bit system with a 32-bit leftover kludge bolted on, exactly the same as the 386 was a 32-bit system with a 16-bit kludge for compatibility reasons. And the IA64 architecture still retains a lot of design decisions that wouldn't make sense in a designed-from-scratch system.

    Itanium didn't fail because it wasn't as good a design, it failed because it wasn't a series of small incremental improvements. Thus lots of development costs up front which are necessary for ANY new high performance design. After some time that funding slows down. Meanwhile lots and lots of funding is still going into continuous small improvements to x86 style chips, and Intel is stuck with it.

  40. Re:I do often wonder what the point of Itanium was by codealot · · Score: 1

    Alpha and MIPS are completely different than IA64. Alpha was a true RISC chip with a fixed 32-bit instruction length, superscalar, out-of-order execution. IA64 was a VLIW chip with in-order execution that relies on the compiler to do anything efficient.

    HP made a fatal mistake cancelling PA-RISC and Alpha in favor of IA64. The could have picked either of the other two as a successor, and have been better off as a result. Instead they chose a dead-end, probably because (at the time) it looked like the entire hardware industry would go that way. Before SGI, IBM, Dell and others backed out.

  41. Re:I do often wonder what the point of Itanium was by afidel · · Score: 1

    HP didn't want to be in the chip business, which is why they sold the IP and engineers to Intel in exchange for long term contracts to produce Itanium. I very much realize that Itanium is vastly different from either PA-RISC or Alpha, but code originally written for either could and was ported to Itanium, something which could not be easily done with x86 (remember this is pre-x64 aka AMD64). You say it was a fatal mistake, but the HP Enterprise business group still brings in billions a year more than a decade after they jettisoned the baggage of making chips, and now they get to move the customers who are still with them over to x64 which means they can stop paying Intel whatever fees they are paying to keep making new Itanium chips further reducing their overhead. As long as the cost reduction through stopping the chip business was less than the lost revenue from whatever businesses jumped ship it was a sound economic decision and based on the size and profitability of the enterprise group I'd say it was.

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  42. Re: Once you go x86 by nbritton · · Score: 2

    or will they simply migrate HP/UX customers to Lintel (Linux on x64)?

    One can only hope, HP-UX has been walking dead for years. 11.31 is six years old, 11.00 was released in 1997. It is at best an edge on an edge case, I want both the Itanium and HP-UX to go away. We have enough choice with Linux, Solaris, and AIX.

  43. Re:I do often wonder what the point of Itanium was by TheLink · · Score: 1

    The platform was declared a failure by many years ago. The reason it survived so long was HP had VMS and Tandem customers. And HP made it such that the Itanic was their only ship sailing on their routes. Those who could leave got off along the way, the rest keep on paying.

    If you look at the old SPEC figures you can see that it was a few times faster in a few tasks (and slower in others). However I believe many of those tasks were "embarrassingly parallel". So instead of buying one Itanic box you could buy two or more x86 boxes for the same price and get about the same performance for that workload and have more flexibility (better performance for other tasks). And possibly not use that much more power either - the Itanic was quite power hungry too!

    --
  44. Yeah: M.B.A. by Anonymous Coward · · Score: 0

    The MBA crapper who ran HP then (Lew Platt) could not think in terms of "let's outfox semiconductor behemoth Intel". All he could think was "oh, let's admit defeat and become their vasall. They are sooo much bigger in their semiconductor ops".

    HP had tremendous talent, thrown in front of the MBA pigs. Pigs are only interested in morsels, not talent. So, a fine company WASTED.

    Engineers - let the MBAs take over at the expense of your own future.

    1. Re:Yeah: M.B.A. by unixisc · · Score: 1

      Issue was that at the time, there were other forces @ work. Apple, IBM & Motorola had formed the AIM consortium to push PowerPC, MIPS seemed to be making inroads w/ workstations, particularly since it supported NT as well, and Alpha too was topping the charts. In the meantime, HP saw that it wasn't cost effective to keep maintaining their own CPU, and hence this partnership w/ Intel.

      It wasn't a bad idea - the bad idea was making VLIW the vehicle for a new architecture. To an extent, Transmeta demonstrated that VLIW could be a vehicle for architectures, if its instruction set was just a vehicle for a different one, such as x86. Itanium did a fine job running PA-RISC binaries, and in this department, actually outperformed PA-RISC. However, it was a bad idea for running x86, given the dependence on the compiler. In Transmeta's case, all that they did was code morphing, w/o trying to keep deep & filled pipelines: that way, they didn't have to struggle to make a perfect compiler the way Intel or HP did.

      Once Merced bombed, HP/Intel may have done well by taking that chip, and going w/ the code morphing strategy - it may have worked better. But make no mistake - PA-RISC was economically unsustainable for HP, which is why they got into this partnership w/ Intel in the first place. Also, VLIW was HP's baby, not Intel's

  45. Re:Good... Let it die. by Anonymous Coward · · Score: 0

    Your comment not a rational assessment of the actual situatuon. x86 code is indeed a bit kludgy. But it is also much more compact than typical RISC code. Variable instruction length is actually a virtue !

    It will matter a lot when it comes to cache efficiency and to generl memory efficiency. "RISC is better than x86" is like saying "Central planning is better than free enterprise". In some ways central planning is indeed better. Say, when you need to design and build make nukes at the fastest possible schedule. But you know what ? Blinky cars, yoghurt and choclatte bars won the cold war.