Intel levert vijf jaar na vorige generatie weer nieuwe Itanium-processors

Intel is begonnen met de eerste leveringen van de Kittson-generatie Itanium-processors. Het is de eerste nieuwe generatie na Poulson uit 2012. Volgens geruchten is het de laatste generatie Itanium-chips.

Het gaat voorlopig om testleveringen aan enkele klanten, de leveringen op grote schaal volgen later dit jaar, zegt een Intel-woordvoerder tegen Infoworld. Kittson staat al sinds 2007 op de roadmap van Intel en de generatie volgt Poulson van 2012 op, maar opvolgers voor Kittson zijn niet bekend.

Daarmee lijkt het om de laatste generatie van de high-end chips voor servers te gaan, iets waar geruchten al langer op zinspelen. De levensvatbaarheid van Itanium staat al jaren ter discussie, vooral sinds IBM, Dell, Oracle, Microsoft en Red Hat zijn afgehaakt wat de ondersteuning betreft.

In feite blijft Hewlett Packard Enterprise daarmee over als drijvende kracht. HP heeft Itanium samen met Intel ontwikkeld en het platform moest de concurrentie met IBM's Power- en Suns Sparc-architecturen aangaan, maar Intel richt zich inmiddels volledig op Xeons, die in tegenstelling tot Itanium op x86 gebaseerd zijn. Xeon heeft inmiddels een aandeel van meer dan negentig procent op de markt voor serverchips.

Reacties (95)

[millman]

Kan iemand mij uitleggen waarom deze processors eigenlijk bestaan? In welk opzicht zijn ze beter dan een xeon? Wat is t voordeel van de niet x86 instructieset? Heeft x86 teveel overhead en is er in theorie een betere performance te halen als je voor een andere instructieset programmeert? Enlighten me pls!

[Rob Coops]

Er zijn een aantal redenen dat deze processoren ontstaan zijn. De meest belangrijke is een bedrijfje dat DEC hete dat een processor architectuur maakte genaamd DEC Alpha. Zij bouwde in feite een RISC processor en hadden daar redelijke succes mee, uiteindelijk kwam deze technologie terecht bij HP die vrolijk door ging met het leveren van deze technologie omdat er veel bedrijven erg blij waren met hun bestaande systemen.

Na verloop van tijd moeten er betere processoren komen en HP die nog veel van de DEC engineers in dienst had en een goede relatie had met Intel was het redelijk logisch om samen aan de nieuwe processor te werken. Op dat moment had HP al aardig wat werk verzet. Je kan je voorstellen wat er gebeurde toen het relatief kleine team dat al maanden aan de nieuwe processor werkte een groot Intel team kreeg om mee samen ter werken aan hun baby... Koppel dat aan een hele erg lastig process omdat de twee bedrijven op management niveau elkaar niet vertrouwden en dus toegang tot de repo's voor elkaar onmogelijk maakte waardoor het uitwisselen van dat extreem lastig was.

Uiteindelijk liep dit uit op een fiasco, go figure, en besloten Intel en HP dat Intel de ontwikkeling zou voortzetten. Intel (DE x86 shop) deed de processor geen goed en plempte erg veel compatibility features in de processor waardoor de Itanium processor een erg lelijk ding is (zeker in de beginnen) en een stuk minder goed presteerde dan mogelijk was gebaseerd op het originele ontwerp.

Intel heeft niet zo veel behoefte aan een tweede architectuur naast haar bestaande x86 wereld en besteed dus heel erg weinig aandacht aan de nieuwe processoren. De roadmap met Kitsson er op was al rond 2007 beschikbaar en toch duurt het al jaren voordat Intel eindelijk eens een nieuwe processor uitbrengt.

Intel heeft echt geen zin in het ontwikkelen en onderhouden van een nieuwe processor architectuur...
Zeker omdat dat de zeer lucrative server markt kan versnipperen en zij dan op twee fronten enorme hoeveelheden geld in R&D zal moeten steken om de concurrentie voor te blijven. ARM die steeds meer een bedreiging vormt voor de low power high tread (web server) markt. Klanten als Oracle en andere die liever niet hun software willen moeten optimaliseren voor meerdere processor architecturen en natuurlijk klanten die een niet overzichtelijk aanbod hebben van Intel processoren bedoeld voor servers.

Ik kan Intel dan ook geen ongelijk geven maar HP heeft zeer slim het contract met Intel op zo'n manier opgesteld dat het voor Intel bijna niet mogelijk is om te stoppen met de Itanium processor (volgens geruchten tot 2020 of na Kitsson dat is nog steeds niet geheel duidelijk). De roadmaps die ik gezien heb in het verleden hebben nooit iets na Kitsson gehad. Dus ik vermoed dat dat het punt is waarop Intel niet meer hoeft en simpel weg de stekker er uit trekt.
Verkoop van de Itanium architectuur lijkt me sterk maar een teruggave aan HP ook niet alleen om de intellectual property problemen maar ook omdat HP al lang alle DEC ontwerpers heeft ontslagen en dus helemaal niets kan doen met een processor als deze. Een stille dood is dan ook het meest waarschijnlijk als je het mij vraagt.

(veel van deze informatie heb ik van een van de processor ontwikkelaars van toen bij HP voor mensen gaan roepen bronnen, bronnen )

[robvanwijk]

Intel heeft echt geen zin in het ontwikkelen en onderhouden van een nieuwe processor architectuur...

Dit deel van je verhaal klinkt me vreemd in de oren. Op het moment dat Itanium werd ontwikkeld draaide "de hele wereld" op x86. Er zijn slechts twee bedrijven die x86-CPUs kunnen leveren (Intel en AMD) en het is uiterst onwaarschijnlijk dat daar ooit nog een derde bij komt. Niet alleen vereist het ontwerpen van een competitieve CPU een gigantische investering, waarvan het helemaal niet duidelijk is hoe je die ooit terug gaat verdienen, het echte probleem is dat x86 juridisch helemaal afgeschermd is. Intel heeft de rechten (want zij hebben het zelf ontwikkeld) en AMD heeft die rechten (want lang verhaal ), maar daar blijft het ook bij.

In de tijd dat de wereld de 32-bit processor begon te ontgroeien en het tijd werd voor de 64-bit processor, toen waren er in feite twee mogelijkheden: een evolutie (x86 uitbreiden naar 64 bit) of een revolutie (iets helemaal nieuws). Helemaal opnieuw beginnen heeft niet alleen enorme voordelen vanuit de technische kant (gigantische ladingen "legacy" hoef je niet langer mee te slepen; stokoude ontwerpkeuzes waar je al jaren spijt van hebt kun je herzien), ook vanuit juridische kant is het een unieke kans om AMD volledig buiten spel te zetten. Als Itanium de markt had veroverd, dan was Intel's verkooppraatje hartstikke simpel geweest: "onze concurrent maakt mooie museumstukken, bij ons kun je (als enige!) moderne CPUs kopen". Na een korte overgangsperiode hoeft Intel dan nog steeds slechts één architectuur te onderhouden, maar die zit technisch veel beter in elkaar en ze hebben op legale wijze een monopolie-positie veroverd. Het wil er bij mij echt niet in dat Intel die kip-met-gouden-eieren willens en wetens zou saboteren.

[Dreamvoid]

Idd, Intel bouwt alleen nog Itanium chips vanwege dat langdurige contract met HP. Het gaat om zeer kleine aantallen voor upgrades/vervanging van oudere HP-UX systemen, er is al jarenlang geen klant meer zo gek dat die een nieuw Itanium systeem gaat opzetten.

Overigens ik weet niet helemaal waar dat conspiracy verhaal over dat Intel bewust Itanium heeft gesaboteerd, ze hebben er zelf destijds ook hard op ingezet. Pas toen de boel volledig flopte in de markt heeft Intel het opgegeven en is de leukste features uit Itanium (hypertheading, virtualisatie extensies) naar de Xeons gaan halen.

[Reactie gewijzigd door Dreamvoid op 24 juli 2024 04:51]

[Rob Coops]

Dat verhaal komt van een van de engineers die aan dat project werkte. Hij vertelde hoe het erg lang erg lastig was tussen de twee. Na dat Intel het project overnam werd de nadruk verlegt van puur PA-RISC vervanger naar een soort hybride x86 chip. De architect aan de HP kant was hier niet blij mee en houd nog steeds vol als dat niet gebeurd was deze chip een stuk succesvoller zou zijn geweest dan deze nu is geweest.

Ik heb geen enkele reden om aan het verhaal van een goede vriend te twijfelen

[Blokker_1999]

De Itanium is ouder dan x86-64 en was ontwikkeld om een performante 64bit CPU neer te zetten. Intel had ook plannen om op termijn de IA64 architectuur naar de desktop te brengen maar AMD kwam af met de AMD64 architectuur welke een uitbreiding was op de bestaande x86 instructieset.

Microsoft heeft toen beslist dat ze van Windows voor consumenten slechts 1 64bit instructieset gingen ondersteunen en doordat AMD een heel stuk eerder klaar was heeft MS daarop ingezet en is Intel moeten volgen.

De Itanium (IA-64) kan potentieel veel performanter zijn omdat een hele hoop legacy instructies uit de CPU gehaald kunnen worden maar is altijd een niche gebleven net omdat vele mensen liever een iets tragere CPU hebben waar veel meer compatibele software voor bestaat.

[MSalters]

Je zit mis met de rechtvaardiging voor de Itanium

Itanium is geen CISC of RISC architectuur, maar een zogenaamde VLIW: Very Large Instruction Word. Elke instructie is 128 bits breed. Daarin zitten dan 3 sub-instructies verpakt.

Itanium heeft bovendien nog een ander uniek feature, speculative instructions. Historisch moet je bij een IF-statement wachten met het ophalen van volgende instructies totdat het resultaat bekend werd. x86 voorspelt het resultaat, en haalt alvast de instructies op die daarbij horen. Itanium is radicaler: die voert beide opties uit - in parallel! Zodra het resultaat van de IF bekend is wordt 1 van die twee speculatieve runs afgebroken, en de andere tot werkelijkheid gepromoveerd. Nog radicaler: die speculatieve uitvoeringen kunnen zelf ook een geneste IF statement uitvoeren.

Hier zij je meteen waarom je geneste instructies in die 128 bits wil: je kan op die manier zowel de TRUE instructies als de FALSE instructies in 1 code flow kwijt. Of in het geval van numerieke code, zowel de kleiner-dan, gelijk-aan en groter-dan instructies.

Hoe effectief die is, hangt af van de kwaliteit van de compiler. De pech voor Intel: niemand kreeg dit fatsoenlijk werkend.

[84hannes]

Een deel van je verhaal herken ik, maar volgens mij is een VLIW-processor er (ook) op gericht om verschillende instructies tegelijkertijd uit te voeren. Als je een optelling doet, en de volgende instructie een vermenugvuldiging, waarbij de uitkomst van de ene niet op de ander hoeft te wachten, dan kan x86 deze out-of-order uitvoeren, maar VLIW kan ze tegelijkertijd uitvoeren. Een leuk concept, dat op paier voordelen heeft, maar voorzover ik weet is er nog nooit een commercieel succesvolle VLIW-processor gemaakt. De Toshiba/Sony Cell process kon als VLIW-processor functioneren, Philips (later NXP) had de TriMedia-processor en HP/Intel de Itanium. Misschien dat ik niet goed op de hoogte ben van dedicated purpose DSP's, maar de consument heeft er volgens mij geen één (meer) in huis.

[Squee]

dan kan x86 deze out-of-order uitvoeren, maar VLIW kan ze tegelijkertijd uitvoeren.

Een x86, of eigenlijk zo goed als alle out-of-order cores kunnen deze werkelijk tegelijkertijd uitvoeren - hoeveel dat is hangt af van het ontwerp, meestal uitgedrukt in "issue width". Het verschil zit hem er in dat bij VLIW het parallelisme tussen de instructies statisch gescheduled is (het staat namelijk vast, in de instruction words), en dat een out-of-order core het dynamisch doet. Daarom wordt het ook wel dynamic data flow genoemd; de dependencies tussen de instructies worden geidentificeerd tijdens de Rename stage en daarna kunnen onafhankelijke instructies tegelijkertijd gescheduled worden. Het grote nadeel van VLIW is wanneer je niet goed weet hoe je instructies gescheduled zullen worden, bijvoorbeeld omdat het af hangt van een variabele latency, zoals of je data in je cache staat of niet. Dan zal je vaak het zekere voor het onzekere moeten nemen en je instruction word moeten bijvullen met lege instructies (NOPs).

Er zijn nog wel meer bekende VLIW processoren geweest, zoals bijvoorbeeld Sun's MAJC, en ook de processors van Transmeta. Wat ook geen toeval is; Transmeta was door een paar ex-Sun MAJC mensen gestart.

[MSalters]

Dat is wat ik zeg over de 3 sub-instructies: met VLIW kan je een optelling en een vermenigvuldiging en nog een derde sub-instructie in één 128-bits bundle stoppen.

[marcovtjetje]

Het is niet het VLIW maar het EPIC aspect dat belangrijk is. (Explicit Parallel Instruction ???, C weet ik niet meer)

Bij Itanium moet je per "VLIW" (dat al meerdere instructies kan bevatten) aangeven of deze vliw bundle parallel uit te voeren is met de volgende of niet.

Je kan dus aangeven dat b.v. 12 instructies parallel uit te voeren zijn. De itanium processor weet hoeveel hij er parallel kan uitvoeren en voert dit dan uit, desnoods in meerder kloks. Het voordeel is dat dezelfde code redelijk efficient is op verschillende generaties Itanium (met verschillende parallelle verwerkings eenheden), en de benodigde analyse erg beperkt is.

Sinds de Pentium Pro is X86 superscalar out of order en zoekt dat dynamisch uit (ook techniek van Dec Alpha EV6 overigens) Dat heeft voor en nadelen. De techniek die M Salters noemt (speculatief uitvoerenv van beide takken van een branch) gebeurt dus ook al, maar bij EPIC krijgt de CPU dus wat meer informatie hierover door middel van de bitjes per bundle. De speculatieve stukken kunnen hierdoor ook langer zijn.

De itanium manier vergt veel van de compiler, maar de uitvoering/decodering is relatief goedkoop. Bij korte procedures kan de compiler echter weinig parallelliseren, maar moet je dus vrijwel lege VLIW bundles met maar een instructie erin erdoor duwen, en staan de andere execution units uit hun neus te boren.

Het idee was op decoding en allerlei analyse (branch/superscalar/speculativ) logica te besparen, en net als RISC de kleinere, eenvoudigere cores dus hoger te kunnen klokken.

Dat is mis gegaan vanwege twee redenen: omhoogklokken boven de 3GHz was destijds erg lastig (en nu 10 jaar later raken we pas 4GHz voor stock processoren), en steeds maar sneller geclockte cores waren bijna niet te voeden, en de steeds groter worden caches waren een groter probleem dan de decoding logica bespaarden.

De itanium had echter een extreem goede floating point unit en gigantische caches, dus kon in het begin, zelfs op lage frequencies nog aardig meekopen in het HPC circuit. Maar de verbeteringen gingen te langzaam, en de volumes bleven laag, en Intel werd door AMD (athlon64) gedwongen om 64-bits x86 uit te brengen, zodat ze niet langer konden volhouden dat "Itanium" de toekomst was.

[Reactie gewijzigd door marcovtjetje op 23 juli 2024 23:00]

[Sebazzz]

Hoe effectief die is, hangt af van de kwaliteit van de compiler. De pech voor Intel: niemand kreeg dit fatsoenlijk werkend.

Voor wie het overigens leuk vind om wat technische details over de instructieset te lezen kan ik de Itanium series van Old New Thing aanraden.

[InsanelyHack]

fantastisch uitgelegd! Was de tijd ver vooruit en wellicht vandaag de dag wel goed aan de praat te krijgen met goede verbeterde compilers. Echter de markt verschuift juist van insane complex naar commodity spul.

[MSalters]

Ererlijk gezegd: nee. Itanium is al jaren op de markt, en dus zijn dergelijke VLIW compilers meer dan academische theorie. Desondanks is het niet erg succesvol.

[marcovtjetje]

Veel oudere GPU's zijn ook VLIW

Pas nieuwere generaties (b.v. AMD met GCN) stappen daar vanaf.

[Verwijderd]

Heeft te maken met HP welke een opvolger van zijn PA-RISC architectuur zocht en het te duur vond om het zelf te ontwikkelen en te maken. Ze hadden ook een 'revolutionaire' techniek uitgevonden waarbij er op compiler niveau de code wordt aangepast zodat er mee instructies parallel uitgevoerd konden worden.

Intel wilde een architectuur die niet de legacy had van de x86 architectuur, een clean sheet. Daarnaast wilde zij het onmogelijk maken voor concurrenten om ook de architectuur te fabriceren, door deze af te schermen met patenten.

In de praktijk bleek het niet te werken omdat er teveel software voor x86 was ontwikkeld en niemand zelfs de moeite wilde nemen om te hercompileren.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 04:51]

[Dreamvoid]

Dat zou enkel een kwestie van tijd zijn, maar het probleem was vooral dat ook nieuw ontwikkelde code helemaal niet sneller bleek te zijn op IA64.

[Kirth]

Itanium en de IA64 instructieset waren een poging tot de volgende generatie van processoren; waar AMD64 (x86_64) een evolutionaire groei is, een superset van x86.

Het revolutionaire zat hem in het Explicitly Parallel Instruction Computing (EPIC, dus ) design waarbij het aan de compiler (en dus niet de processor in run time) is om de parallele executie van instructies te beheren. Dit moest onder andere de hoge performance penalty van branch mispredictions mitigeren.

[rjmno1]

Het is dus een x64 processor gebaseerd op de 2012 product lijn.
Het is de zogenaamde merced gebaseerde processor en is verbonden met quick path technologie.
Volgens mij proberen ze deze processor nieuw leven in te blazen, en dus bij deze weer kleiner te maken zodat hij zuiniger is en niet zo warm word.
Hij kan x 86 emuleren zodat de software ondersteuning optimaal is.
Of deze sneller is of gelijk aan een xeon processor zou ik niet weten.

[Cave_Boy]

Zijn mooie cpu's alleen ik snap niet hoe deze cpu's nu op je moederbord vastgezet worden. Is dit met insteken op een gleuf-socket of ergens opleggen met pins? De Pentium 2 en 3 zijn in gleuf socket uitgekomen sindsdien heb ik ze eigenlijk nietmeer gezien. maar de zijkant van de CPU toont koperen banen.

Edit: zelf inmiddels gevonden het is gewoon op het socket en niet met een gleuf socket. De zijpaden worden vermoedelijk gebruikt voor testen van de cpu?

[Reactie gewijzigd door Cave_Boy op 24 juli 2024 04:51]

[Crp]

Het lijkt er meer op dat de "gleuf kant" als voeding word gebruikt. Je monteerd de cpu op een koelbloek waarbij de gleufkant op een ¿voedingsbord? word vastgeschroefd. De hele module (cpu/koeling/voeding) kan dan op het moederbord worden gemonteerd. waarbij de CPU pinnen in/op de socket vallen.

http://www.itinstock.com/...k-AD389-2100C-14154-p.jpg

https://ic.tweakimg.net/ext/i/1110829316.jpg

[Reactie gewijzigd door Crp op 24 juli 2024 04:51]

[Cave_Boy]

Die plaatjes maken veel duidelijk. Top!

[Fairy]

O dat 2e plaatje doet me denken aan zo'n orb koeler van vroeger. My goodness wat een ellende waren die dingen (lawaai).

[Cave_Boy]

Die ORB koelers waren met koeling wel goed alleen inderdaad ze konden aardig wat lawaai maken. Oplossing was vaak een iets groter model kiezen en dan de fan langzamer laten lopen.

[Fairy]

Uiteindelijk ben ik destijds overgestapt op die grote waaiers van Zalman.

Je wil niet weten hoeveel kilo's koper er bij mijn ouders op zolder in de dozen van oude computerzooi staat.

Binnenkort een langsgaan en naar de ijzerboer brengen, zou me niks verbazen dat het geld waard is Stond er van te kijken hoeveel van de koelers ik in de loop der jaren bij elkaar gekocht heb.

[Reactie gewijzigd door Fairy op 24 juli 2024 04:51]

[ATIradeon8500]

4-5 Euro per kilo voor je koper denk ik zo....

[InsanelyHack]

Als je een beetje naar de oude titanium kijkt kan je je wel een voorstelling maken hoe de nieuwe in een moederbord geplaatst zal worden. Meer de oude Pentium 2 - 3 methodiek met een soort van "cartridge". Wat ik me afvraag, een nieuwe CPU uitbrengen is één maar daar hoort toch veel meer bij? Chipset enz? Enorm dure actie en wie gaat daar dan nog aan beginnen om dit als product in de markt te zetten? Je kan volgens mij beter dan de data migreren als dit nog op een titanium platform stond te draaien. Beetje IT manager had dit toch moeten bestempelen als een enorm risico en zal zeker de afgelopen 5 jaar gekeken hebben hoe hij van dit "vendor abandoned" platform af had moeten komen lijkt me.

Nog wat plaatjes gevonden: link CPU compleet & Moederbod met Afgemonteerde CPU

[Reactie gewijzigd door InsanelyHack op 24 juli 2024 04:51]

[GekkePrutser]

Intel houdt de ontwikkeling vooral in stand vanwege een deal met HP (tegenwoordig HPE) die daar honderden miljoenen voor heeft betaald. link

HP wil dit weer ivm support contacten voor hun HP-UX lijn (en ook OpenVMS maar daar weet ik minder van). Die draait nergens anders meer op. Een x86 port is er niet. Bij ons op het werk zie ik bijvoorbeeld nog Oracle servers die op HP-UX draaien. De Oracle software zelf is tegenwoordig wel beschikbaar voor Linux / x64 maar met ERP systemen zit je dan met custom connectors die vaak voor de oudere systemen zijn ontwikkeld. Zeker als je toch al toekomstplannen hebt voor een ander systeem dan is het vaak goedkoper om een nieuwe server te halen.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 04:51]

[RJG-223]

OpenVMS draaide alleen op IA64 (en daarvoor op Alpha, en daarvoor op VAX). Enige tijd geleden heeft HP OpenVMS afgestoten, en de nieuwe eigenaar is bezig met een port naar x86_64, waarvan een eerste versie volgend jaar klaar moet zijn. Een jaar later moet het helemaal klaar zijn.

[GekkePrutser]

Maar daar betekent niet dat alle klanten gelijk op x86 over kunnen. Er zal nog veel legacy spul zijn dat de migratie tegenhoudt.

[InsanelyHack]

Deze is cruciaal te begrijpen: ...maar met ERP systemen zit je dan met custom connectors die vaak voor de oudere systemen zijn ontwikkeld....
Wat bedoel je precies met custom connectors?

[Fairy]

Volgens mij bedoelt hij een (bijvoorbeeld) windows applicatie die de vertaalslag doet naar het ERP systeem. Zodat de gebruikers wel in een Windows omgeving kunnen werken in plaats van bijvoorbeeld een terminal te moeten gebruiken.

Correct me if I'm wrong

[GekkePrutser]

Nee dat juist weer niet. De Windows client applicaties zijn zelden een beperking voor een upgrade van het server platform. In tegendeel. Vaak wordt je desktop Windows upgrade gedwarsboomd omdat de oude client niet op de nieuwe Windows werkt en de nieuwe client versie de oude ERP core niet meer ondersteunt. Zoals ik hieronder zei is het upgraden van zo'n ERP systeem vaak heel erg duur. Dus ziedaar de reden dat bedrijven miljoenen betalen voor bijvoorbeeld extra support op Windows XP. Of emulatie lagen van derde partijen.

[GekkePrutser]

Speciaal ontwikkelde software om gegevens te koppelen aan andere systemen. Zo'n ERP systeem beheert de volledige financiën van een groot bedrijf. Moet ook dingen aansturen enzovoorts. Dus heeft veel data nodig. Handmatige invoer is duur en foutgevoelig. Een wirwar van koppelingen is het gevolg.

Die moeten allemaal getest en eventueel geupgrade worden voor je naar een andere versie van je ERP kan. ziet als het ook op een andere architectuur moet. Dit is heel erg duur en tijdrovend. Want je hebt het niet over een handvol koppelingen. Voor een multinational loopt het al gauw in de honderden.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 04:51]

[Condor70]

Moderne Itaniums hebben een "normale" LGA1248 socket, maar de foto is van een vorige generatie Itanium met PPGA611 socket, die inderdaad net als bij Pentium 2/3 zijwaarts gemonteerd worden.

[SpamLame]

Je bedoelt zeker de PAC611 socket, een vorm van PGA.

Hoe dan ook Itanium2 wordt niet "zijwaarts" als P2/3 gemonteerd.
Het is of LGA of PGA.

[mission]

Vroeger zaten ze gewoon in een min of meer reguliere zif socket..

[Reactie gewijzigd door mission op 24 juli 2024 04:51]

[RoestVrijStaal]

HP heeft Itanium samen met Intel ontwikkeld en het platform moest de concurrentie met IBM's Power- en Suns Sparc-architecturen aangaan

Nou, dan heeft het project iig wel de doelstelling bereikt, maar niet door Itanium zelf.

Van POWER en SPARC hoor je steeds minder van. Microsoft en Sony gebruiken al geen POWER-cpu meer voor hun nieuwe XBOX en PlayStation ten gunste van de x86 architectuur en Nintendo ten gunste van ARM voor haar nieuwe Switch. Oracle heeft sinds de overname van Sun Microsystems niet veel liefde aan SPARC gegeven.

[Squee]

Oracle heeft sinds de overname van Sun Microsystems niet veel liefde aan SPARC gegeven.

*proest* Sorry... heel erg offtopic misschien, maar dat meen je niet? Oracle heeft sinds de overname van Sun serieus geinvesteerd in SPARC en in de afgelopen 7 jaar in totaal 7 nieuwe SPARC processoren op de markt gebracht;

• SPARC T3 (2010)
• SPARC T4 (2011)
• SPARC T5 (2013)
• SPARC M5 (2013)
• SPARC M6 (2013)
• SPARC M7 (2015)
• SPARC S7 (2016)

Dat noem je "niet veel liefde"?

[edit]: En een roadmap tot 2021

[Reactie gewijzigd door Squee op 24 juli 2024 04:51]

[devilkin]

Sparc is echter wel ten dode opgeschreven. Buiten een paar niches, en Oracle zelf, zijn alle grote spelers aan het weggaan van het Sparc platform. Oracle heeft daar trouwens zelf goed aan toegedragen, met z'n idiote licentie/support politiek.

Op m'n eigen werk was het vroeger één van de grote platformen, nu... draait er bijna niks meer op. Een paar dino's, die binnenkort ook weggaan.

[Dreamvoid]

Dat is ook helemaal de bedoeling niet, Oracle ontwikkelt SPARC voor zichzelf, om Oracle servers mee te maken. Itt Sun destijds zijn ze totaal niet geinteresseerd dat concurrenten hun chips gaan gebruiken.

[Kirth]

Er is nochtans veel commotie in de OpenPOWER community [1]. IBM doet hard hun best om met een waardige concurrent te komen voor de Intel Xeon, en slagen daar misschien ook wel in [2]. Op de desktop zie ik de komende jaren dan weer niks dan x86_64.

[1] https://openpowerfoundation.org/
[2] http://www.anandtech.com/...art-2-server-applications

[BitJager]

Ik denk dat je de console markt niet echt kan vergelijken met server producten. De PowerPC in de X360 heeft niet veel gemeen met die in een IBM mainframe.

Me dunkt zijn er 3 factoren die doorslaggevend zijn voor de keuze van een CPU in een console.

- Prijs
- TDP vs Performance
- Instructieset in 't voordeel van API's

--
Het voordeel dat x86-64 me dunkt nu heeft in verhouding tot eerdere generaties voor consoles is ->

Games worden alsmaar complexer dus moet men meer en meer gebruik maken van engines zoals Unreal, Unity, ... om nog kost efficient iets te kunnen produceren binnen een redelijke termijn zo kost efficient mogelijk. Weinig ontwikkelaars ontwikkelen nog een engine van scratch. Deze engines zijn inititeel ontwikkeld voor x86-64.
Zeker voor MS heeft de x86-64 een groot voordeel aangezien ze zelf al decennia ervaring hebben in het bouwen van compilers voor die architectuur en dus software development tools. MS heeft sinds de originele Xbox altijd een streep voor gehad bij de ontwikkelaars omdat ze het platform aanboden waarvoor het makkelijkst te ontwikkelen was. Bijvb. ports van PC naar Xbox hebben op het vlak van performance amper problemen. Vandaag zitten we zelfs in een situatie dat men eerst ontwikkeld voor Xone of PS4 en dan de boel port naar PC.

Soit nu ben ik erg ver afgeweken van het initieele onderwerp. Velen moeten ook begrijpen dat Itanium een Mainframe platform is en je dergelijke machines bijna nooit zal terugvinden bij een kleine KMO (KBO - GMBH) maar eerder in zeer grote bedrijven die nood hebben aan dergelijke machines waarvoor dikwijls in huis software voor ontwikkeld wordt. Denk aan groot-banken, internationaal monetair verkeer en dergelijke meer.

[Dreamvoid]

Wtf? De ontwikkeling van SPARC is juist sinds de Sun overname gigantisch versneld, Oracle steekt er miljarden in. In de eindjaren van Sun verslofte de boel nogal door geldgebrek maar de trein dendert weer aardig door nu - de snelste cpu ter wereld is inmiddels weer een SPARC.

[Verwijderd]

IA64 was toch veel beter geoptimaliseerd dan x86-64? Het is van de grond af opgebouwd dus je zit niet met allerlei legacy troep wat bij x86 wel het geval is. Maar ik vraag me dan af in hoeverre deze nieuwe chips beter presteren dan x86-cpu's.

[FreezeXJ]

Dat hangt ervan af hoe goed je software geoptimaliseerd is voor 64-bits. Voor 'gewone windows' is dat dieptriest, die drijft vooral op 32-bits code, idem met de meeste programmas. Alleen als je alles opnieuw schrijft voor itanics dan gaat het snel (en ook echt snel). Wil of kun je dat niet, dan zijn ze niet vooruit te branden.

Het liefst wil je dan ook nog je compiler vertellen dat hij itanic-specifieke instructies kan gebruiken, zodat hij probeert meerdere dingen naast elkaar af te handelen, in plaats van een generieke oplossing die op x86 werkt.

Raad eens hoe goed je gemiddelde software-pakketje het hierop doet, en dan weet je meteen waarom het geen doorslaand succes geworden is

[Reactie gewijzigd door FreezeXJ op 24 juli 2024 04:51]

[Verwijderd]

Het liefst wil je dan ook nog je compiler vertellen dat hij itanic-specifieke instructies kan gebruiken, zodat hij probeert meerdere dingen naast elkaar af te handelen, in plaats van een generieke oplossing die op x86 werkt.

De compiler bepaalt juist het meeste. Code wordt geschreven tegen (Windows) API’s en meegeleverde libraries. Dus ik vraag me af wat je bedoelt met:

Alleen als je alles opnieuw schrijft voor itanics dan gaat het snel (en ook echt snel).

Code wordt op een veel hoger level geschreven dan instructies tegen de processor.

[Verwijderd]

Ja, en nee.
Ik kan in Perl of zelfs BASH al prima gebruik maken van kennis van de hardware. Ik kan een algoritme memory of CPU intensief maken, naar gelang wat het beste zal uitpakken.
Een C programmeur kan nog veel verder gaan en code zo optimaliseren dat de compiler dat op je, voor Itanium, juiste manier oppakt.
Het is de combinatie van programmeur, taal en compiler die het resultaat bepaalt.

[Verwijderd]

Ja, maar memory en CPU zoals jij ze noemt hebben niks met de onderliggende instructieset te maken. Ik zeg ook niet dat je in hoger liggende talen geen kennis hoeft te hebben van de hardware.

En code optimaliseren in C? Testen inderdaad, want de compiler optimaliseert namelijk ook en die kan je nog wel eens in de weg zitten, door vreemde constructies te bedenken, waarvan je zou denken dat ze sneller zijn.

Maar er zullen ongetwijfeld best practice patterns zijn voor je C code om deze optimaal te laten draaien voor de Itanium.

[rjmno1]

Het licht er ook aan wat er gecompileerd moet worden, je moet de software wel laten weten wat voor een hardware matige instructie de cpu heeft.
Hoe beter de software geprogrammeerd is hoe beter hij loopt.
Je moet de software laten weten hoeveel cores een bepaalde processor heeft hoeveel intern en cache geheugen alleen dan kan een processor echt alles uit de kan halen wat er in zit en of dat nu een litanium is of een ia 64 variant of sparc.

[FreezeXJ]

Je hebt code en code, meestal zet je een Itanic niet in om websites te serveren... Het meeste worden ze zover ik weet gebruikt voor High Performance Computing (HPC) waarbij je het liefste alles door je C-compiler haalt (ok, Java of C++ mag ook), en je tegen een zo simpel mogelijk OS aan praat (lees: *NIX, Windows heeft in deze markt niks in te brengen). De code hier is meestal enigszins parallel, en dat is waar de Itanic voor ontworpen is, heel veel dingen tegelijk afhandelen (12 instructies naast elkaar voor de vorige Poulson, als hij de kans krijgt. Zelfs je moderne SkyLake doet er maximaal 6). Echter moet je daarvoor handig herschedulen van instructies, en dat vereist fine-tuning. Dus ja je compiler heeft heel veel invloed, hoewel de meeste inmiddels op ongeveer gelijk niveau spelen.

Het punt is dat lang niet alle code opnieuw gecompileerd kan/mag worden voor IA-64, en dat is waar Intel zich behoorlijk in vergist heeft. Recompile je niet (wat ik bedoelde met herschrijven), dan draait je Itanic in ge-emuleerde x86-mode, en dan is de performance rampzalig, ongeacht hoe goed je code ook voor x86 goptimaliseerd is.

[Creesch]

(lees: *NIX, Windows heeft in deze markt niks in te brengen).

Ik betwijfel dat *NIX varianten het dominante OS zijn op de itanium servers die in gebruik zijn. Er is een reden dat HP als één van de weinige bedrijven hier nog support op levert en dat heeft niet alleen te maken met het feit dat ze aan Itanium hebben meeontwikkelt.

Itanium is vooralsnog het enige "moderne" platform waar OpenVMS nog op kan draaien en laat dit OS nu van HP zijn.

Er zijn nog diverse bedrijven die kritische software hebben draaien op het OpenVMS platform. Vaak bedrijfskritische systemen die een oorsprong hebben in de jaren 80/90 waar stabiliteit een vereiste was. Want dat doet OpenVMS best aardig, het is behoorlijk solide en betrouwbaar.

Veel van die bedrijven zijn wel bezig met migratie trajecten om bijvoorbeeld de software op linux te laten draaien maar dat is een langdurig process en tot die tijd hebben ze nog steeds support contracten bij HP.

[Reactie gewijzigd door Creesch op 24 juli 2024 04:51]

[RJG-223]

Itanium is vooralsnog het enige "moderne" platform waar OpenVMS nog op kan draaien en laat dit OS nu van HP zijn.

HP heeft OpenVMS enige tijd geleden afgestoten. Die nieuwe eigenaar is overigens bezig met een port naar x86_64...

[Creesch]

Dat klopt dus niet helemaal, OpenVMS is nog steeds van HP en het support contract dat veel bedrijven hebben loopt dan ook gewoon via HP.

Wat HP heeft gedaan is de code in licentie aan VSI uitbesteed en dit bedrijf werkt dan ook aan de port naar x86_64.

De release van VSI OpenVMS die draait op x86_64 staat overigens ergens in de planning voor 2018.

[Dreamvoid]

Het belangrijkste platform voor Itanium is HP-UX, da's een Unix.

[Creesch]

Ben benieuwd of je daar cijfers van hebt Kan best zijn dat je gelijk hebt hoor, moet eerlijk bekennen dat mij statement dat OpenVMS wellicht meer gebruikt word gebaseerd is op mijn ervaringen en ik HP-UX niet zo vaak ben tegengekomen.

Overigens gelden de problemen die bedrijven ondervinden met OpenVMS en de onzekere (niet bestaande) toekomst van Itanium daar ook, HP-UX is zover ik bekend ben ook niet beschikbaar voor de x86_64 architectuur.

[The Third Man]

Het liefst wil je dan ook nog je compiler vertellen dat hij itanic-specifieke instructies kan gebruiken, zodat hij probeert meerdere dingen naast elkaar af te handelen, in plaats van een generieke oplossing die op x86 werkt.

Waarom zou je uberhaupt code op je itanium compileren als x86? Je compileert toch juist altijd voor het platform waar je het voor gaat gebruiken? IA64 dus? Dat is niet een vlaggetje hier of daar (dit is geen MMX), dat is een complete andere architectuur, net als ARM of Sparc.

De vraag was niet of de Itanium goed x86-32 kon draaien, maar als je native code gebruikt je efficienter bent dan x86-64.

[Reactie gewijzigd door The Third Man op 24 juli 2024 04:51]

[FreezeXJ]

You wish... Probeer op dit moment van je software-leverancier maar eens een IA-64-pakketje los te peuteren. Moet je net geluk hebben, want vermoedelijk doen ze x86, x86-64, en misschien nog iets als ARM, en dan houdt het snel op. De meeste gewone programmas vinden Linux-support al lastig...

Simpel gezegd: als je beide native code voert wint de Itanic, maar tenzij je het zelf bouwt is er geen native code voor IA-64 beschikbaar. Ergo: ding is 'traag'.

[Reactie gewijzigd door FreezeXJ op 24 juli 2024 04:51]

[The Third Man]

Maar welke code zou dat dan zijn? Je kan toch de reguliere HP-UX of een IA64 linux (RedHat bijv) draaien en daar de binaries van bijvoorbeeld nginx voor gebruiken? Of desnoods gewoon nginx source clonen en lokaal compileren?
Ik zie niet zo snel een voorbeeld waarbij je closed source nodig zou hebben, waarbij je dan voor IA64 hebt gekozen... Je kiest toch juist voor IA64 als je het wil gebruiken voor een toepassing die in IA64 beschikbaar is of te compileren is?

Misschien begrijp ik je verkeerd, maar je lijkt iets te zeggen als 'ja een elektrische auto is wel sneller, maar je kan niet overal opladen, dus wat heb je er dan aan'. Terwijl als je de auto in een omgeving gebruikt waar opladen geen probleem is (bijvoorbeeld omdat je op je werk kan opladen en hij alleen woon/werk gebruikt wordt), dan valt dat argument toch weg?

IA64 is wat mij betreft net zo'n nicheproduct als een Cray, je gebruikt hem als je er wat aan hebt. Niet als zomaar 'een cpu' alsof ze tussen de andere x86-xx cpu's liggen om er vervolgens achter te komen dat het daar niet voor bedoeld is. Om dezelfde reden dat je geen RPi voor desktoptoepassingen gaat gebruiken om vervolgens te klagen dat hij niet snel is, ja daar is hij ook niet voor gemaakt.

[Reactie gewijzigd door The Third Man op 24 juli 2024 04:51]

[Timoo.vanEsch]

In die laatste alinea heb je ook precies het hele punt: Itanium is een niche-product, waar nog maar weinig mensen op zitten te wachten. En dus verdwijnt het langzam uit de schappen...

[The Third Man]

Natuurlijk, maar dat was juist niet het punt. De vraag hierboven was

IA64 was toch veel beter geoptimaliseerd dan x86-64? Het is van de grond af opgebouwd dus je zit niet met allerlei legacy troep wat bij x86 wel het geval is.

En FreezeXJ bleef hameren op het probleem dat als je x86-32 wilde draaien je slechter af was... Terwijl je daar normaal gesproken niet een Itanium voor koopt, dan had je wel een reguliere Xeon gekocht.

[Free rider]

Dat leveranciers dat niet leveren heeft natuurlijk een andere oorzaak: ze hebben zelf geen/onvoldoende Itanium machines om hun producten mee te testen. Bedenk dat leveranciers een goede werking moeten garanderen en dat is een lastig verhaal als het nog nooit op zulke machines heeft gedraaid.

[Verwijderd]

Jij doelt op de slechte x86-emulatie op IA64-hardware. Dat is inderdaad waarschijnlijk debet geweest aan de mislukte overstap voor consumenten. Echter dat bedoel ik niet. Ik heb het over software die voor IA64 is gecompileerd. Dan is er volgens mij een enorme boost t.o.v. x86.

Overigens is Microsoft van plan om x86 te emuleren op ARM. Natuurlijk is het nog even afwachten of het plan doorgaat en wat de prestaties zullen zijn maar het idee van emulatie is dus niet losgelaten. Mogelijk hebben ze de emulatielaag in de afgelopen jaren flink verbeterd. En aangezien deze nieuwe Itaniums ongetwijfeld een stuk sneller zullen zijn dan die van 2012 zou het mij niets verbazen als Microsoft hier alsnog een fatsoenlijk Windowssysteem van zou kunnen bouwen. Waarmee ik overigens niet zeg dat we daar op moeten rekenen, maar x86 eindelijk een keer loslaten zou toch geen slecht idee zijn.

[MSalters]

Sorry, nogal grote onzin. Itanium kan niet eens 32 bits code uitvoeren, maar gewone programma's in C++ of Java of C# zien daar niets van. Je hoeft dus ook niets opnieuw te schrijven.

En nee, je hoeft een Itanium compiler niet te vertellen dat die Itanium-specifieke instructies mag gebruiken. Zo'n compiler kan simpelweg anders, die weet niets eens iets van x86 of ARM instructies af.

[batjes]

De gewone Windows is niet diep triest en is al sinds Vista netjes 64 bit. Sterker nog, Windows XP was orgineel ontworpen om een volledig 64bits OS te zijn, waar MS vanaf gestapt was omdat de hardware nog 32 bits was in die tijd.

Hoe 32 bit werkt binnen een 64 bits Windows is juist een vernuft stukje techniek en optimalizatie. 32 bit applicaties draaien deels virtueel om op die manier ook nog voordelen te kunnen halen uit 64bit instructies.

Windows zelf draait niet eens echt op 32bit code, of 64bit code. Het enige wat echt op 32bit en/of 64bit code draait binnen Windows is het stukje binary blob binnen de NT Kernel wat zelf met de CPU praat. Voor de rest van het OS maakt het eigenlijk geen bal uit op welke instructie set het OS draait, want net als Linux kan het in principe elke architectuur draaien. NT had ook gewoon netjes ondersteuning voor IA64 en Windows kan hier gewoon netjes (en optimaal) op draaien als MS dit zou willen, of hier een markt voor ziet.

[Free rider]

Windows XP ontworpen voor 64 bit? Raar verhaal. De voorlopers van Windows XP waren juist ontworpen om processor-onafhankelijk te zijn, zo kon je Windows NT 4.0 aanschaffen voor Intel x86, MIPS, DEC Alpha, en PowerPC. Later kwam ook Itanium.
Voor Microsoft was het de eerste keer dat ze een OS processor-onafhankelijk was, eerdere besturingssystemen als MS-DOS, Xenix en Windows (3.x / 9x) waren juist gebonden aan een architectuur en geoptimaliseerd daarvoor.

Toen x86-64 processors verschenen in 2005 kregen Windows Server 2003 en Windows XP werd ondersteuning voor deze processors toegevoegd, door het verschijnen van aparte versies. Maar je kan echt niet zeggen dat Windows XP voor 64 bit is ontworpen, het was met zijn voorgangers juist onafhankelijk van processors ontworpen.

[MSalters]

" Het enige wat echt op 32bit en/of 64bit code draait binnen Windows is het stukje binary blob binnen de NT Kernel wat zelf met de CPU praat. "

Je haalt hier twee dingen door de war. Er is een klein stukje _x86 assembly_ in de _source code_ van de NT kernel. De rest van de code is in C geschreven, maar wordt ook gewoon naar x86 gecompileerd. (of x64/ARM uiteraard)

En het hele OS praat direct met de CPU. Dat geldt zelfs voor native applicaties. Javascript. .Net en dergelijke praten niet direct met de CPU, maar via de interpreter.

[ApexAlpha]

90% van de server markt in handen van Xeon al. Wow, netjes. Heeft AMD niks in te brengen op de server markt?

[Kirth]

Niet in het domein van de (high performance) Xeon. AMD heeft besloten zich op andere markten te focussen waar ze het op vlak van kosten en technische mogelijkheden wel konden concurreren met Intel. De laatste generatie Opterons dateren bij mijn weet al van 2013; erg ferm waren die niet.

Ondertussen modderen ze maar wat aan in de server ARM-markt. Iets waarvan al jaren wordt geroepen dat het the next big thing wordt. In de praktijk kunnen ook die producten niet concurreren met Intel server hardware. Deels een hardwareprobleem: bij ARM kies je voor een relatief performante, snelle core óf een trage, zuinige core. Het lukt de ARM-server pioneers niet om dezelfde energiemanagementprofielen te bouwen zoals Intel. Ook een groot software probleem: zo heeft MySQL for ARM last van race-conditions waardoor er vage problemen ontstaan met je transacties. Je moet al helemaal gek zijn om op zo iets je (productie)systemen te willen bouwen.

[Eikeltje]

Hopelijk komt hier wel verandering in met AMD zijn nieuwe Architectuur.

[tedades]

AMD heeft nu ~1% van de server CPU markt in handen, in 2006 zaten ze nog op ~26% (ten koste van o.a. de Itanium). Op de consumenten markt heeft AMD tegenwoordig helaas ook weinig in te brengen, hopelijk komt daar verandering in met de nieuwe Ryzen line-up.

Wat cijfertjes over marktaandeel:
<20% actief gebruik AMD CPU: https://www.cpubenchmark.net/market_share.html
~30% AMD GPU: http://www.anandtech.com/...but-nvidia-remains-on-top
~1% server markt aandeel: http://marketrealist.com/...are-server-gaming-sector/

Als je dit vergelijkt met Itanium is het opzich nog positief, AMD lijkt de komende periode weer wat op te krabbelen.
Verhouding X86 / RISC was in 2012: 80,4 / 19,6.
In het deel RISC was Itanium maar 18% (dat is dus 3,5% van de bovenstaande 100%), en het is nu 5 jaar later natuurlijk dus dit cijfer zal de trend doorgezet hebben en veel lager liggen nu.
http://searchsap.techtarg...m-for-optimal-performance

[Verwijderd]

is dit geheel uit vrije wil of ivm allerlei rechtzaken?

[Bart©]

Zo klinkt het wel inderdaad. Waarom in godsnaam deze procesoren uitbrengen terwijl HP de enige is die ze ondersteund èn Xeon ook nog eens 90% van de serverchip-markt in handen heeft.

[musje83]

Lijkt mij dat ze het vooral doen om de (slinkende) userbase van deze alternatieve architectuur niet van de een op de andere dag te laten vallen. Je kunt als gebruiker niet zomaar je hele hebben en houwen overzetten op Xeon-based (x86) machines, althans niet zonder enorme concessies te moeten doen. Xeons zijn goed voor entry-, mid- en high-end market maar in veel gevallen totaal niet geschikt voor enterprise (hoewel dat een vrij rekbaar begrip is) en al helemaal niet voor Mainframe.

Enige echte optie is de overstap maken naar Power (wat ik toejuich) of Sparc, maar ook dat kan voor enorme overgangsproblemen zorgen, nog buiten het feit dat het duur, heel erg duur kan zijn om zo'n switch te maken. Database migratie specialisten zijn bepaald niet goedkoop, en die ga je wel een flink aantal uurtjes nodig hebben als je een beetje gemiddelde database draait.

Persoonlijk denk ik dat Intel alle mogelijkheden open gaat houden en niet nu al de deur voor enterprise-grade CPU's in het slot gaat gooien. Je weet namelijk nooit hoe de markt er over 5-10 jaar uitziet, zeker met de enorme golfbeweging van on-premise naar (hybrid-)cloud. Zoals het er nu naar uit ziet, zal mainframe nog wel een poosje aanblijven als de backbone voor de enterprise markt.

[Blokker_1999]

Maar je weet als gebruiker al heel wat jaren dat het platform ten dode is opgeschreven. Als je nog niet bezig bent met migratieplannen ga je altijd te laat komen imho.

[musje83]

In zekere zin wel, maar in deze hoek van de markt duurt zo'n migratie een pak langer dan in de 'gewone' server/database hoek. Ik heb genoeg klanten die 10+ jaar oude mainframe en/of AIX/ i / AS400 machines hebben draaien en al 2-3 jaar aan het plannen(!) zijn en nog lang geen zicht hebben op een daadwerkelijke migratie.

't is how it is

[Barsonax]

Maar waarom duurt dat zo lang dan? Gewoon luiheid of?

[musje83]

Het is vaak een kwestie van, je verwacht het niet, geld. Mainframes en high-end database machines zoals IBM Z, Power, Sparc e.d. zijn ontwikkeld voor extreme mission-critical high availability, oftewel enorme compute en I/O performance tegen 99,9999% uptime. Bij IBM zit het zelfs in de naam, Z(ero downtime). Het probleem is dat dit een soort luxe-probleem veroorzaakt, want juist omdat het zo betrouwbaar is, is de behoefte het te vervangen veel kleiner dan bij reguliere systemen. Ook zijn ze ontwikkeld op scalability, wat zoveel betekent dat je tot in het extreme kunt 'bijprikken' zodra je meer performance/capaciteit nodig hebt.

Migreren betekent risico nemen, en dat is met mission-critical machines uit den boze. Het plannen ervan is vaak al een fulltime functie an sich. En dat kost natuurlijk allemaal... geld.

[Creesch]

Nee absoluut geen luiheid, maar veel van het soort systemen waar dit op draait zijn bedrijfskritische systemen die al in de jaren 90 ontworpen zijn en gebouwd op langdurig gebruik.
Het gaat hier vaak om backend systemen waarbij stabiliteit en betrouwbaarheid een must zijn die behoorlijk ingewikkeld in elkaar steken (miljoenen regels code).
Eind jaren negentig en begin van deze eeuw was het nog lang niet zo duidelijk dat Itanium geen groot success zou worden.

Daar komt nog bij dat veel van deze applicaties niet eens op een Unix/Linux draaien maar bijvoorbeeld op OpenVMS een OS dat in handen is van HP en die op het moment ook niet te installeren is op servers met x86 processoren. De keuze hiervoor was in het verleden overigens hartstikke logisch, het is namelijk een enorm solide en betrouwbaar OS. Sterker nog, het nog steeds is in veel gevallen betrouwbaarder dan Linux systemen en heeft nog legio andere zaken geïmplementeerd die je niet tegenkomt in de meeste server besturingssystemen.

Een migratie houd dan dus in dat je een volledige keten aan software niet alleen moet compileren naar een andere proces architectuur maar dat je ook alles geschikt moet maken voor een totaal ander OS. Sterker nog, met een beetje pech is je gehele software keten ook nog eens geschreven in een taal die niet of niet hetzelfde compileert op andere besturingssystemen.

Met dat in het achterhoofd heb je het al snel over een voorbereidingsfase die flink pittig is en waarbij er eerst een hoop tussen stappen genomen moeten worden voordat er daadwerkelijk gemigreerd kan worden.

bron: Ik ben nu zelf betrokken bij een dergelijk traject

[Reactie gewijzigd door Creesch op 24 juli 2024 04:51]

[Wim-Bart]

Een migratie houd dan dus in dat je een volledige keten aan software niet alleen moet compileren naar een andere proces architectuur maar dat je ook alles geschikt moet maken voor een totaal ander OS. Sterker nog, met een beetje pech is je gehele software keten ook nog eens geschreven in een taal die niet of niet hetzelfde compileert op andere besturingssystemen.

Met name dat laatste heb ik zelf meegemaakt met code omzetting naar x86 omgevingen. Compiler doet zijn werk goed. Alleen bleken daar de byte-order in een WORD INT en dergelijke behoorlijk parten te spelen.

Code waarbij een word via een type definitie zowel benaderbaar is als value.w en value.hibyte, value.lowbyte wat onder x86 omgewisseld is bijvoorbeeld. Geen compiler die je daar voor waarschuwde maar ondertussen moet je wel met 10 man handmatig 100k regels code aflopen....

[Creesch]

Geen compiler die je daar voor waarschuwde maar ondertussen moet je wel met 10 man handmatig 100k regels code aflopen....

Ja niet leuk inderdaad, het traject waar ik nu bij betrokken ben gaat het om enkele miljoenen regels code die bovendien eerst van de ene taal over moeten naar de andere.

[Reactie gewijzigd door Creesch op 24 juli 2024 04:51]

[Bart©]

complexiteit van omgevingen. Het is vaak niet zo dat alleen het systeem dat gebruik maakt van oudere hardware geraakt wordt met een migratie maar vaak ook een of zelfs meerdere applicatieketens.

[Wim-Bart]

Heb een aantal VMS projecten meegemaakt waarbij het zo makkelijk lijkt om te migreren naar bijvoorbeeld *nix of Windows. Voor een aantal onderdelen klopt dit aardig maar zitten de nuances in speciaal geschreven modules waarvan de ontwerper/bouwer/leverancier inmiddels 2 meter onder de grond ligt, de vele koppelingen, de complexe data modellen en de stabiliteit. Er zijn HP-UX, Sun, VMS systemen die een OS up-tijd hebben/hadden van jaren, ooit een AS/400 doos die 9 jaar uptijd had (9 jaar geen onderbreking op de software).

Mainframe op Enterprise niveau is/was met andere oplossingen bijna niet te evenaren. En men is ook zeer behoedzaam (en dus traag) met het migreren van functionaliteit.

[OruBLMsFrl]

9 jaar uptime is ook 9 jaar geen besturingssysteem upgrade...

[Wim-Bart]

Met VMS en OS/400 ook niet echt nodig als het stabiel is. Daarnaast kwamen er ook geen updates meer uit omdat het OS en hardware platform "EOL" was en niemand het ook uit durfde te zetten.

[OruBLMsFrl]

Dat soort angst herken ik wel ja. Men blijft er maar liever vanaf. Bij de Itanium en HP-UX nog wel updates. Als je dan nog een tijd moet met een applicatie en toch nog een laatste keer nieuwe hardware koopt dan krijg je een nieuwer OS.

Wil je dan vervolgens de 'oude' hardware (nu backup) systemen upgraden om zo weer overal een uniforme en gepatchte OS versie te hebben dan wordt het complete herinstallatie en validatie. Toch weer even kleine Itanium projectjes erbij om het goed te doen.

[Wim-Bart]

Dat soort angst herken ik wel ja. Men blijft er maar liever vanaf. Bij de Itanium en HP-UX nog wel updates. Als je dan nog een tijd moet met een applicatie en toch nog een laatste keer nieuwe hardware koopt dan krijg je een nieuwer OS.

Wil je dan vervolgens de 'oude' hardware (nu backup) systemen upgraden om zo weer overal een uniforme en gepatchte OS versie te hebben dan wordt het complete herinstallatie en validatie. Toch weer even kleine Itanium projectjes erbij om het goed te doen.

Blijf het overigens mooi spul vinden die Itanium HP-UX systemen. Maar dat geldt ook voor de oudere PA-RISC in combinatie met HP-UX.

[MSalters]

Daar denk je weer teveel Windows/Linux. High-end systemen kunnen transparante OS updates doen.

[Creesch]

Mja zo simpel is het echt niet, deze systemen zijn sowieso vaak ontworpen om veel langer mee te gaan omdat ze een andere functie vervullen dan 90% van servers out there.

Het gaat vaak om zeer complexe bedrijfskritische systemen met zeer specifieke software die ontworpen zijn om jarenlang hetzelfde process foutloos te kunnen draaien.

Hier heb ik er wat uitgebreider over geschreven

[Verwijderd]

HP had al eerder Oracle (ja, echt, in die volgorde) aangeklaagd omdat oracle was gestopt met de ontwikkeling van Oracle voor itanium.

[MSalters]

Geheel uit vrije wil, in de zin dat Intel geheel uit vrije wil een contract met HP heeft gesloten voor de ontwikkeling van Itanium en er daarna aan vast zat. Dat is dus ook meteen de reden dat dit vermoedelijk de laatste Itanium is: het contract loopt af en Intel heeft geen zin in een nieuw contract.

[Verwijderd]

Itanium is feitelijk dood.

Het verbaast mij dat ze nog zo lang er mee door zijn gegaan. Waarschijnlijk zit Intel contractueel vast aan het blijven ondersteunen van Itanium, anders waren ze er al lang mee gestopt.

Ik voorspel dat RISC-V de volgende revolutie wordt. Goede kans dat veel Chinese bedrijven hier groot op in gaan zetten. Samsung gaat ook processoren op deze architectuur maken.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 04:51]

[musje83]

IBM heeft al de OpenPower Foundation en het basisprincipe van open-source hardware is prachtig, maar ik betwijfel of het revolutionair gaat blijken.

[Verwijderd]

Wel als bedrijven als Samsung zich er mee gaan bemoeien.

Ik betwijfel dat OpenPower echt 'open' is zoals de naam doet vermoeden. IBM zal toch gewoon alle patenten erop houden. Ik zie vaak namen van organisaties die beginnen met 'open' maar allesbehalve dat zijn.

[Dreamvoid]

Haal dat 'waarschijnlijk' maar weg, dat is volop bevestigd: HP betaalt Intel al jaren voor het in leven houden van Itanium, voor hun overgebleven HP-UX klantenbestand.