Intel stopt met Itanium-processors

Intel heeft de Itanium 9700-lijn van processors voorzien van de end-of-life-status. Daarmee trekt de chipfabrikant definitief de stekker uit zijn Itanium-platform, dat gericht was op high-end servers en de markt voor high performance computing.

Intel stopt met de Itanium 9720, 9740, 9750 en 9760, oftewel de Itanium Kittson-familie van processors, meldt Intel in een document over product discontinuance. Tot uiterlijk 29 juli 2021 blijft Intel de processors leveren. De impact voor klanten is minimaal, zo tekent AnandTech aan. HP is de enige afnemer van de processors, voor zijn HPE Integrity Superdome-systemen met HP-UX 11i v3-OS.

De Itanium 9700-lijn verscheen in 2017, waarbij Intel al liet weten dat er geen opvolger in de planning stond. De 9700-lijn was al een bescheiden update voor de 9500-reeks met codenaam Poulson uit 2012. Itanium heeft zijn oorsprong bij HP, die onderzocht hoe het very long instruction word-ontwerpen voor processors kon inzetten voor enterprisesystemen. Bij dit soort ontwerpen bevatten words meerdere instructies zodat deze in een enkele klokcyclus afgehandeld kunnen worden.

HP werkte er oorspronkelijk aan onder de naam PA-WideWord, maar in 1994 startte de samenwerking met Intel, waarna de architectuur verder ging onder de namen IA-64 en Itanium Processor Architecture. In 2001 verscheen de eerste Itanium-processor. Gaandeweg werd duidelijk dat x86-64 ook voor de enterprise de betere keuze was, ook omdat de prestaties van Itanium tegenvielen en de productie van de chips door hun omvang duur was. Bovendien staakten IBM, Dell, Oracle, Microsoft en Red Hat hun ondersteuning voor Itanium, waarna alleen HP als klant overbleef.

Reacties (74)

Sinds dag 1 heeft het nooit echt indruk gemaakt...
reviews: Intel Itanium sneak preview
Al zijn er workloads die enorm goed schaalden op de het platform icm Red Hat
@Rctworld er komen ook weer architecturen voor terug, ondanks dat ook daar de adoptie langzaam gaat

Tsja, als je test-procedure is om x86 code te laten draaien op een Itanium processor dan is het geen wonder dat het geen snelheidsbeest is. Ook een Ferrari rijdt niet snel als er drempels in de straat liggen zullen we maar zeggen.

quote: https://tweakers.net/revi...-testing-the-itanium.html

The advice we got was to focus on x86 performance because, especially in the beginning with the scarcity of IA-64 software, this would be almost as important as the performance in IA-64 mode. The benchmarks we took along will for this reason look quite familiar. On the one side that's nice because it gives you lots of comparable material, on the other hand it's too bad if you can't get a good impression of the performance doing what it was built to do: IA-64.

Itanium was een prima architectuur, maar het loslaten van de backwards compatibility was natuurlijk een behoorlijk risico. Ze hebben het zo'n twintig jaar volgehouden, wat toch wel een prestatie is. Maar nu ingehaald door de realiteit.

In welk opzicht prima? In principe werd instruction scheduling (wat bij x86 in de CPU gebeurt) naar de compiler verplaatst. De meeste compilers deden dit niet, dus moesten aangepast worden. Dat gebeurde te langzaam (want het viel niet mee). Daarnaast heb je daar niets aan voor bestaande closed-source software. Tevens (maar hier ken ik de details niet genoeg van) zie ik niet hoe een statische compiler dit beter kan doen dan een cpu met een ingebouwde scheduler die dynamisch is (maw. meekijkt naar wat er gebeurt). Compilers optimaliseren voor een happy-path maar als je use-case daar vanaf wijkt kan de performance tegenvallen (zie de likely() macro in de Linux kernel om de compiler te helpen). Een CPU die op basis van gedrag scheduled heeft dit probleem minder: het happy-path is afhankelijk van het gedrag van de applicatie.
Dus wellicht is Itanium een pure architectuur (als in: breekt met het verleden) maar ik zie niet waar het een prima architectuur is die aansluit bij wat mensen van een computer verwachten.

Ik ben dit niet helemaal met je oneens, echter is er natuurlijk ook voldoende non-branchy code waar een hoop scheduling gebeurd door de CPU (eerst de omzetting naar uOps, vervolgens het verdelen van de uOps over de execution units) die in principe prima door een compiler gedaan zouden kunnen worden.

Vergelijk het met C++, dat is voor veel toepassingen ook sneller dan de JVM ondanks dat een VM dynamisch allerlei slimme keuzes kan maken op basis van de daadwerkelijke taskload van een stuk software.

Dat gezegd hebbende heeft het ook als groot nadeel dat zodra de processormaker met iets nieuws slims komt, i.e. de verhouding of de mogelijkheden van verschillende execution units verandert, je de instructies zou moeten aanpassen en dat is toch wel weer vervelend. Ook dingen als hyperthreading maken dat de execution units sowieso al beter gebruikt kunnen worden.

Lineaire scheduling is redelijk triviaal, daar zit het probleem niet in. En C++ sneller dan een JVM.Tsja, ik doe al 20 jaar Java dus ben wat bevooroordeeld, maar ik ken weinig gevallen waarin C++ relevant sneller is dan Java (in de deelgebieden waarin ze actief zijn). Een inner rendering loopje van m'n nieuwe game engine zou ik niet snel in Java doen. Niet omdat het niet snel genoeg zou zijn, maar eerder vanwege de GC jitter die impact heeft. Net zoals ik er niet aan moet denken om een internet facing applicatie te maken in C++ (of C) omdat je jezelf te eenvoudig in je voet schiet.

Gelukkig hebben we nu RISC-V. Dat maakt wellicht een kans over een jaar of 10.

Dat heeft totaal andere use-cases Het mooie aan RISC-V is dat het helemaal open is en uit een gebruikersgroep komt (basis wetenschap) en nu ook door industrie wordt opgepikt.

RISC-V sillicon is er al en je kan het makkelijk in een FPGA gieten. https://riscv.org/risc-v-cores/

Toch kan het x86 en ARM behoorlijk dwars gaan zitten. Het is wachten op vergelijkbare use-cases. Vandaar mijn 10 jaar opmerking.

Nu snap ik'm Ja, er zullen zeker gebruikersgroepen bijkomen wanneer de architectuur gaat schalen. Wanneer je kijkt naar bijv. Intel+Altera (FPGA technologie) in een SoC kan je ook RISC-V techniek meenemen. Misschien is dit ook wel een weg die Intel op den duur wil inslaan.

Wij hebben nochtans relatief zware, maar specifieke database loads kunnen draaien op 2 bakken met elk 2 Itanium 9150N processoren. Toen we die machines 7 jaar later hebben vervangen door Ivy Bridge-gebaseerde servers, waren bepaalde onderdelen nauwelijks sneller (grote datasets en heel veel memory ops). Dat waren dan 4 machines met elk 2 Xeon E5-2650 v2's. De software was specifiek geschreven voor IA64, dus geen emulatiepenalty. Itanium had dus zeker zijn plaats, maar de ontwikkeling ging stukken langzamer dan bij x86. Samen met prijs waren dat de redenen dat wij overgestapt zijn.

Ik ken je specifieke load niet, maar je schijft "veel memory ops" waarin ik aanneem dat je data in het geheugen past. Dan is mijn vermoeden dat je database goed in elkaar stak (veel joins op indices en gebruik van integer waardes). CPU snelheid is voor veel queries niet zo belangrijk. IO throughput en latency (of als alles in geheugen past RAM throughput en latency) zijn veel belangrijker. Ik denk dat deze queries op nieuwere E5s dan ook nauwelijks sneller zullen zijn.

Zeker jammer. De insteek op HPC maakte het voor mij erg interessant, maar de prijs is altijd erg hoog gebleven. Dan heb je voor 2x een x86_64 oplossing meer "bang-for-buck". Ook geen wonder dat er nauwelijks supercomputers/clusters zijn op basis van Itanium (ik kan welgeteld 2 initiatieven vinden: hier en hier, beiden uit de begintijd).

En toen kwamen de GPU's, die voor heel weinig geld erg goed presteerden voor bepaalde applicaties.

En niet te vergeten natuurlijk OpenVMS wat op Itanium draaide. Deze wordt geschikt gemaakt om op x86 te draaien. OpenVMS wordt volgens mij nog maar beperkt gebruikt in NL, ik vond het in ieder geval een fijn OS, zeker met DCL scripting language.

[Reactie gewijzigd door patjer73 op 1 februari 2019 08:24]

Op het moment is OpenVMS bij ProRail sowieso nog in gebruik bij diverse systemen op het gebied van trein aansturing maar daar zijn ze ook erg hard bezig met deze systemen wat o.a. inhoud dat alle regels code van één van deze systemen is omgezet van pascal naar C++, hier nog een artikel aangezien de support op Itanium OpenVMS in 2020 ten einde loopt.

Waarom omzetten?

Beide zijn geen interpreter talen.

Beetje zonde van de resources.

Hint: die blauwe lijntjes onder tekst geven aan dat het een hyperlink is. Daar kun je op klikken, en dan ga je naar de pagina waar het uitgelegd staat. Maar om je een beetje te helpen: Omdat C++ wél onder Linux werkt.

(Bovendien heb je veel meer programmeurs, en C++ is al lang bewezen in life-criticial systemen)

Pascal werkt ook prima onder Linux hoor. Nog niet zo heel lang geleden een klein stukje pascal code uit een oud project opnieuw gecompileerd. Geen enkel probleem. Wellicht is DEC pascal erg afwijkend.

Blijft staan dat geen hond meer Pascal leert programmeren en C++ een prima keuze is. De vraag blijft wel hoe onderhoudbaar een dergelijk systeem blijft op de lange termijn.

[Reactie gewijzigd door divvid op 1 februari 2019 09:57]

Pascal heeft veel meer divergentie. C++ wordt actief gestandaardiseerd (meest recente standaard is van 2017; voor 2020 staat de volgende in de planning) . ISO pascal heeft z'n laatste update in 1990 gehad, 29 jaar geleden. Alle ontwikkeling daarna is verschillend per compiler. En niet zo'n beetje ook. ISO pascal heeft niet eens strings, laat staan Unicode support.

Free Pascal's laatste update was eveneens in 2017 en in 2015 was de laatste *grote* update, dus overschakelen van Pascal naar Free Pascal had gekund. Neemt niet weg dat ik met je eens ben dan C++ uitgebreider is en beter te onderhouden want meer programmeurs, but I'm just saying...

https://www.freepascal.org

Bestaat nog maar 25 jaar.

Er mogen wel niet veel Pascal-programmeurs meer zijn, maar dat neemt niet weg dat het prima onder Linux draait, dus je argument klopt niet.

Een stuk software wat bestaat uit 1,3 regels zeer gespecialiseerde code compleet vanaf de grond opnieuw schrijven kost in dit geval simpelweg meer resources en tijd die niet beschikbaar is. Je moet je beseffen dat het hier niet gaat om relatief generieke software of uberhaubt software waar vergelijkbare alternatieven voor zijn.
Procesleiding is het systeem waarmee men het spoor in Nederland bedient en waar een hoop onderliggende beveiligingslagen mee worden ontsloten naar de verkeersleiders. Er zitten in al die regels code enorm veel logica die specifiek is afgestemd op diverse situaties zoals deze zich voordoen op het Nederlandse spoor. Logica die er letterlijk over enkele decennia aan ervaring is ingebouwd. Die ervaring en kennis neem je, zelfs met goed gedocumenteerde code, niet zomaar mee als je het gaat herschrijven.
Het omzetten van de code zorgt er voor dat de logica en software zelf grotendeels intact blijft en kan de focus liggen op het geschikt maken voor een andere platform.

Leuk leesvoer wat dat betreft, een moderner artikel wat dat betreft.

Dus stel, iemand komt op het onzalige idee om bv nieuw besturingssysteem te schrijven 'just for fun, nothing serious', dan zou dat een slecht idee zijn?

Je kan er op rekenen dat het tientallen jaren duurt voordat het een systeem is dat een significante deuk in de bestaande besturingssysteemduoopolies van, laten we zeggen, Unix en Windows, kan slaan. Ik denk niet dat ProRail daar op kan wachten.

Hangt ervanaf. Google heeft Fuchsia in relatief korte tijd van de grond gekregen en als ze nu met die voormalige Apple-man goede marketing doen, dan komt er zeker een deuk in Unix en Windows' marktaandeel. Niet enorm, maar het zal wel iets doen.

Wat @Yev volgens mij bedoelde, was Linux. Unix en Windows stellen niet zoveel meer voor. Ja, op sommige servers zal je nog een Unix-distributie tegenkomen, en als je goed zoekt vind je nog wel een persoon die een PC/Laptop gebruikt (buiten de werkplek), en daar zou Windows of macOS (Unix) op kunnen draaien, maar het grootste deel van de computers zijn embedded devices en die draaien, vrijwel zonder uitzondering, net als de meeste(?) servers op een besturingssysteem waarvan Linux Torvals in 1991 (dus alweer 28 jaar geleden) schreef

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.

Klopt, ik bedoelde Linux, maar grappig genoeg had ik wel Fuchsia in gedachten voor de huidige situatie.

Hoewel het doorontwikkelen van legecy software duidelijk voordelen heeft zoals door @Creesch met de gelinkte artikelen mooi wordt beschreven, heeft het ook duidelijk nadelen, zoals bv een stuk software die anders niet kan worden veranderd omdat de andere software dan niet meer werkt; denk idd aan de Linux Kernel vs Zircon microkernel.

Bij andere software zal de afweging een stuk genuanceerder liggen maar om te zeggen dat je nooit geheel opnieuw moet gaan bouwen is dus een te boude uitspraak.

Dat gezegd hebbende lijkt mij geen zinnig mens het geheel opnieuw bouwen van dat NS Appje te durven voorstellen

Unix-achtig, daarentegen, is nog wél populair. Met name QNX en het wordt ook steeds populairder, vooral in de auto-industrie (wordt gebruikt voor de on-board computers).

[Reactie gewijzigd door TheVivaldi op 1 februari 2019 17:54]

Vanuit redenering van tweede link wel.

Bij OS komt heel veel kijken en een paar boeken van Tanembaum (o.a. Minix) voor Os inrichting en een paar boeken van W. Richard Stevens (o.a. tcp/ip illustrated) is niet voldoende om samen met eigen inzicht en ervaring tot een OS te komen die vandaag de dag door derden als bijzonder gezien zal worden.


Zie het als Linux distro.
De kans dat er ooit een distro erbij komt die met marktleiders kan meten is nihil.

Maar het wel leerzaam om http://www.linuxfromscratch.org een keer te doen zodat je afwegingen van marktleiders kunt zien en becommentariëren.

De kans dat er ooit een distro erbij komt die met marktleiders kan meten is nihil.

Niet alleen zal dat er natuurlijk en volledig zeker komen (denk aan een paradigma verschuiving of simpeler, een nieuwe taal of methode waarmee makkelijker en sneller vanaf de grond af aan een nieuw besturingssysteem kan worden gebouwd (misschien zelfs weer het afschuwelijke proprietary).

Maar ik durf wel de stelling aan dat Google Fuchsia binnen 10 jaar zelfs in de top 3 staat

Je weet dat bij Google vele Linux en GNU hackers werken en gewerkt hebben?

Het is niet zo dat die zircon kernel zonder kennis en ervaring van scratch gemaakt is.

Ik begrijp niet helemaal wat je punt is

Ja ik weet dat (juist) bij Google enorm veel GNU/Linux experts in dienst zijn en geweest. Google maakt zelfs meerdere Linuxen zoals natuurlijk Android maar ook een eigen DE gebaseerd op Debian (ze zijn al een aantal jaar afgestapt op een gemodificeerde Ubuntu dat Goobuntu in de wandelgangen werd genoemd) maar ook in hun datacenters gebruiken zij een zwaar getweakte Linux.

Daarom zijn zij misschien wel het beste toegespitst op het ombouwen van LittleKernel tot Zircon. Maar daarmee dus wel een essentieel andere kernel dan Linux, die trouwens (soft) realtime is.

Maar omdat het dus oa Android moet gaan vervangen op telefoons, tablets en tv's, maar ook als pc/laptop besturingssysteem geschikt is en vrij waarschijnlijk daarvoor ook zal worden gebruikt, durf ik daarom te beweren dat het binnen 10 jaar binnen de top 3 besturingssystemen zal staan maar mogelijk zelfs al op plek 1.

Ik heb nog geen performance tests gezien van Zircon, maar het zou zomaar ook geschikt kunnen zijn voor hun datacenters.

Wat mij betreft na seL4 de spannendste ontwikkeling sinds tijden!

Linux is alleen de kernel de rest is grotendeels GNU.

Ja dus?

Als het de bedoeling is om een bestaand systeem te vervangen met feature parity en dezelfde functionaliteit dan zou het vanuit een kosten en baten overweging inderdaad zo kunnen zijn dat het voor een bedrijf niet zo'n goed idee is. Allemaal afhankelijk van context, dus beetje flauwe vergelijking

Allemaal afhankelijk van context, dus beetje flauwe vergelijking

Klopt maar het was dan ook met een knipoog bedoeld want zoals ik elders schrijf zou geen zinnig mens die NS software opnieuw durven schrijven in de huidige situatie en context

"Modern artikel" geeft "food for thought" immers eerste reactie is van scratch beginnen zinvoller is.

Zelf zou ik ik toch voor scratsch hebben gekozen omdat je dan de kennis en handjes in huis hebt. Terwijl dat met legacy migratie niet hoeft te zijn.

Zeker als je bepaalde specifieke businessprocessen op bepaalde manier hebt opgelost die buitenstaander niet zomaar zal begrijpen.

Zelf zou ik ik toch voor scratsch hebben gekozen omdat je dan de kennis en handjes in huis hebt.

Mja, dat is ook hoe je van de mega grote projecten krijgt die helemaal uit de klauwen lopen aangezien er toch veel meer bij komt kijken om het te reproduceren dan men initieel dacht waardoor je weer kamervragen gaat krijgen, etc, etc.

Overigens is het eerste artikel hier net zo goed van toepassing.

Mag toch aannemen dat..

Er zitten in al die regels code enorm veel logica die specifiek is afgestemd op diverse situaties zoals deze zich voordoen op het Nederlandse spoor. Logica die er letterlijk over enkele decennia aan ervaring is ingebouwd.

..dit dan ergens geborgd is, en het daarmee toch zeker niet onmogelijk is.

Onmogelijk is het niet, maar kennis op papier is nog geen parate kennis. Bovendien is veel logica afhankelijk van de huidige opzet van de applicatie, als je gaat voor een rewrite zal je alsnog een hoop logica opnieuw moeten vormgeven waarbij het zeer goed mogelijk is dat je veel rand gevallen pas in productie tegenkomt.
Daardoor zal het opnieuw schrijven sowieso meer tijd in beslag nemen, tijd die er simpelweg niet is.

Het lijkt me dat dat een ding is zo van nu we toch bezig zijn de boel om te gooien. C++ is een taal die veel meer programmeurs kunnen namelijk.

juist omdat het geen interperter talen zijn zal je code moeten aanpassen om voor een andere architectuur te compilen.

Omdat DEC Pascal niet draait onder Linux.

Draait prima onder Linux.

Zijn ze daar nog mee bezig? Ik liep daar in 2006 al rond en ze waren er druk mee..

Over 10 jaar zullen zij er gegarandeerd nog mee bezig zijn.

Het is net zoiets als de Belastindienst. Wie durft te beweren dat het huidige automatiseringsprobleem binnen 15 jaar kan worden opgelost verteld gegarandeerd onzin. Dat is nl zo complex dat dit stukken langer zal gaan duren en heeel misschien dat er over 30 jaar een nieuw van de grond af aan opgebouwd pakket dat werkt zal zijn opgeleverd.

Probleem is geen politicus zoiets durft te beweren bovendien is die toch al weer binnen 4 jaar ergens anders.

[Reactie gewijzigd door Yev op 1 februari 2019 15:14]

Dat zal verkeersleiding zijn geweest, dit is procesleiding net een iets ander systeem.

Ik had eerlijk gezegd niet gedacht dat Itanium het nog zo lang vol zou houden.
Jammer, het was een mooi platform dat de opvolger van x86 had kunnen zijn, al weet ik niet of AMD dan nog bestaan zou hebben. AMD heeft zichzelf weten te redden door Itanium te ondermijnen met een backwards-compatibele upgrade voor x86. Dat was fijn voor de korte termijn, maar eigenlijk maar een kleine stap vooruit. Ik had liever een grotere stap gezien zoals Itanium wel bood.

De gok met Itanium was dat compilers voor Itanium efficienter konden zijn dan x86 compilers. De ondergang van Itanium is daar direct aan gekoppeld; zo effectief zijn die compilers namelijk niet. En x86-64 was voor die compilers wél een grote stap vooruit. Een groot aantal extra registers, zelfs als we AVX negeren, met veel meer vrijheid in het gebruik ervan. Ja, toegegeven, de x86 instructie codering is complex. Boeien - dat is een lookup table. O(1) complexiteit. VLIW scheduling betekent dat je een hele serie van instructies op dependencies moet checken, en bij Itanium komt daar nog de explicit speculative execution bij. Dta maakt die depdencies nog complexer. Theoretisch exponentiële complexiteit.

De register allocator op een x86 daarentegen doe ik niet met een lookup table ;-) Maar idd. VLIW scheduling is op zijn best naar.

Lag al in de lijn der verwachting. Jammer dat afwijkende architecturen steeds meer naar de achtergrond verdwijnen.

Vind het wel raar dat als tech website nog steeds HP gelijk wordt gesteld aan HPE. "HP is de enige afnemer van de processors, voor zijn HPE Integrity Superdome-systemen met HP-UX 11i v3-OS." HP is opgesplitst in Hewlett Packard Enterprise (server / storage / networking) en HP Inc (laptops / desktops / printers), juridisch gezien zijn dat compleet onafhankelijke bedrijven geworden. HP is dus zeker niet meer de afnemer van Itanium.

Jammer dat afwijkende architecturen steeds meer naar de achtergrond verdwijnen.

Of juist niet jammer, hoe minder diversiteit er op dit soort dingen is, hoe makkelijker je hiervoor kunt ontwikkelen. Je hoeft immers maar één ding te maken wat overal op werkt. Ik ben blij dat x86(-64) zo breed inzetbaar is dat er geen/weinig behoefte is aan specialistische instructiesets, op ARM na.

Of juist niet jammer, hoe minder diversiteit er op dit soort dingen is, hoe makkelijker je hiervoor kunt ontwikkelen. Je hoeft immers maar één ding te maken wat overal op werkt. Ik ben blij dat x86(-64) zo breed inzetbaar is dat er geen/weinig behoefte is aan specialistische instructiesets, op ARM na.

Op korte termijn is het wel makkelijk. Op lange termijn kweek je afhankelijkheden waar je eigenlijk niet meer vanaf komt. Software zal zich steeds meer voegen naar de grillen van een bepaald stuk hardware, dat vroeg of laat verouderd zal zijn. Het bekendste voorbeeld van dat proces is IE6. Toen het zo ver kwam dat er websites gebouwd werden die zich hadden aangepast aan de eigenaardigheden van IE6 kwamen andere browsers enorm in de problemen, inclusief nieuwere versies van IE die steeds gekkere sprongen moesten maken om nog compatible te zijn. Op een bepaalde manier nog steeds niet helemaal af, de problemen die MS nu heeft met de overgang van IE naar Edge zijn er een uitvloeisel van.

Een lang verhaal om te zeggen dat diversiteit op lange termijn fijn is. Dat voorkomt dat valse afhankelijkheden en verborgen incompatibiliteit.

ARM is RISC
X86 is CISC

https://cs.stanford.edu/p...o/projects/risc/risccisc/

Ik verwacht dat RISC uiteindelijk CISC zal verdrijven in de komende decennia.

Net zoals Itanium nu "achterhaald" is door o.a. gebrek aan schaal voordeel.

Als straks energie prijs nog een grotere rol gaat spelen is RISC superieur aan CISC.

Hier een longread over Intel x86 en Qualcom ARM in server omgeving:

https://blog.cloudflare.com/arm-takes-wing/

[Reactie gewijzigd door totaalgeenhard op 1 februari 2019 09:12]

ARM is RISC
X86 is CISC

20 jaar geleden was dat zo.

Tegenwoordige processoren zijn eerder een mengsel van de concepten van RISC en CISC. Moderne ARM64 processoren hebben meer complexe instructies dan de x86 CISC CPU's van 20 jaar geleden hadden, en moderne AMD64 processoren van Intel en AMD vertalen de CISC achtige instructies intern naar uOps die meer weg hebben van de klassieke RISC instructies.

Er zijn nog wel bepaalde karakteristieken die blijven bestaan zoals geen load-calculate op ARM/RISC en een 'strong memory model' voor Intel/AMD alhoewel ook daar inmiddels uitzonderingen op bestaan bij bepaalde instructies.

X86 is tegenwoordig allang RISC. De pipelining maakt het een soort hybrid.

Pipelining kan op alle vormen van processoren (de arm's doen het ook gewoon) en is niet cisc/risc specifiek. Wat je waarschijnlijk bedoelt is dat de microcode een extra decode layer vormt welke daarna in een risc-like core gaat.

Als je naar de HW implementatie kijkt kan je het wel als een hybrid zien. Vanuit de SW heb je gelijk. Ik ben een echte HW man :-)

x86 kan nooit RISC zijn. RISC staat voor Reduced Instruction Set CPU.
X86 is CISC (Complex instruction set cpu) en het belangrijkste van die cpu is compatibiliteit en daarmee behoud van de CISC.

Als je naar de SW kant kijkt en het chip design negeert klopt dat.

Als we het even voluit schrijven "Reduced Instruction Set Architecture". De instructieset van x86 is nooit gereduceerd, enkel uitgebreider. In die zin is de "Complex" in x86 complexer dan ooit. CISC of RISC gaat in stricte zin dus enkel over de instructieset.

Wel is zo dat enkele architectuurkenmerken van de processor, die in het begin voorbehouden waren aan RISC, later ook op CISC toegepast konden worden. Dat kun je evenwel eerder als een gevolg van de Wet van Moore beschouwen, dan als dat x86 opeens RISC is geworden.

Als ik chip designs zie dan is het allemaal complex en dus allemaal cisc.

De scheidingslijn tussen RISC en CISC is nogal wazig geworden. Zo draait een moderne x86 processor met microcode, met daaronder RISC achtig gedrag, en zijn nieuwe ARM processoren uitgerust met functies die nogal CISC achtig zijn.

zie o.a. deze pagina.

Supercomputing komt steeds meer op het bordje van gpgpu of variatie daarvan,
nieuws: Universiteit Antwerpen toont Nvidia DGX-2-supercomputer met piek van ...
dat concept heeft zich al dubbel en dwars bewezen,

en daarnaast maakt ASIC/FPGA een heel harde opmars want dat kan nog simpeler worden opgebouwd dan een gpu en werkt taken nog sneller af.

Structuren zijn nog simpeler dan die van CISC/RISC en dat is dan ook gelijk hun zwakte. Ze zijn geen goed allrounders en blijven beperkt in hun inzetbaarheid.

Als je een SIMD probleem hebt is GPU een goede keuze. Voor een MIMD probleem al een stuk minder. Dus GPU computing is voor een bepaalde subset van problemen leuk. Een van de zaken die zich er voor leent is AI. En laat dat nu net een hype zijn waardoor GPU computing gezien wordt als het beste ding sinds gesneden brood. Over 3 jaar is dat weer helemaal anders.

PA-risc was ook risc, in ieder geval in 32-bits mode. En itanium had het idee het beste van pa-risc en x86 te gebruiken. Maar dan in puur 64 bits.

Wat superieur is hangt vooral af van het gebruik. Kijk naar de grafische kaarten en omstreken. Wie kent de term 'transputer' nog. Allemaal varianten van processors die beter zijn in de taken die ze uitvoeren.

Cpu is maar een onderdeel van het app-platform, OS is veel belangrijker. En dan nog de frameworks meegeleverd. (Android RunTime, .NET, IOS). Dan zijn er nog OS's waar ik niets van weet, Sun OS, Z/OS.

Heb de Itanium in de eerste generatie nog meegemaakt. HP UX servers. Erg geschikt en nogal wat sneller dan de x86 tegenhangers toendertijd.

Dit was toch al bekend nieuws?

Jouw link staat letterlijk in het artikel:

De Itanium 9700-lijn verscheen in 2017, waarbij Intel al liet weten dat er geen opvolger in de planning stond.

Het verschil is nu natuurlijk dat de daar aangekondigde serie nu daadwerkelijk End-Of-Life gaat en er dus een datum bekend is dat de laatste bestellingen gedaan kunnen worden.

Hmmmm

Jaren geleden las ik ook een bericht dat Intel zou stoppen met de Celleron processor. deze word nog steeds gemaakt als low budget processor.

Voor de taken waar VLIW geschikt is zijn GPUs denk ik de logische opvolger - die oogsten de voordelen echt.
Business processing en databases bestaan meer uit geheugen heen en weer slepen en pointer chasing. Echt rekenen is maar een fractie van wat er gebeurt. (Een salarisstrook zal niet meer dan 100 rekenbewerkingen zijn - wat betekent dat een desktop CPU die op 100 GFLOPS zit alle salarisstroken ter wereld in 100 seconden kan doorrekenen. Ja, dit is geen floating point, mensen hebben meer dan 1 baan, etc, maar het gaat om een inschatting van de verhoudingen.) Dat rekenwerk paralleliseren schiet niet op als de volgende input ergens op een SSD staat.