Intel brengt allerlaatste Itanium-generatie van processors uit

Intel is donderdag de levering gestart van de allerlaatste generatie van Itanium-processors voor servers. De chipgigant heeft bevestigd dat na de nu verschenen 9700-serie van processors, geen nieuwe Itaniums meer verschijnen.

Intel begon de leveringen van testchips voor de nieuwe Itaniums al eerder dit jaar maar is nu, zonder er ruchtbaarheid aan te geven, de levering op grotere schaal aan klanten begonnen. Tegenover PCWorld heeft Intel laten weten dat er geen opvolgers komen voor de Itanium 9700-chips, ook wel bekend onder de codenaam Kittson.

Kittson is een bescheiden update voor de 9500-reeks met codenaam Poulson. Net als die chips worden ze op 32nm geproduceerd en ondersteunen ze tot aan ddr3-1067-geheugen. Er verschijnen vier modellen, die waarschijnlijk voornamelijk in de Integrity i6-servers van Hewlett Packard Enterprise terechtkomen.

Er gaan al heel lang geruchten dat Intel de stekker uit Itanium wil trekken. In de voorgaande jaren staakten IBM, Dell, Oracle, Microsoft en Red Hat hun ondersteuning voor Itanium. Daarmee is alleen Hewlett Packard Enterprise over als belangrijke partner. Intel ontwikkelde de architectuur oorspronkelijk met HP, maar het chipbedrijf richt zich al jaren volledig op Xeons, waarmee het een aandeel van meer dan negentig procent op de servermarkt heeft.

Intel Itanium 9700-serie (Kittson)
	Cores/ Threads	Kloksnelheid	L3 cache	Tdp	Prijs*
Itanium 9760	8/16	2,66GHz	32MB	170W	$4650,-
Itanium 9750	4/8	2,53GHz	32MB	170W	$3750,-
Itanium 9740	8/16	2,13GHz	24MB	170W	$2650,-
Itanium 9720	4/8	1,73GHz	20MB	130W	$1350,-

*Kosten gebaseerd op vergelijkbare Poulson-modellen. Bron: AnandTech

Reacties (85)

[GTX2GvO]

Wat zou eigenlijk nog het voordeel zijn van een Itanium ten opzichte van welke andere Server CPU nu op de markt?

[kdekker]

Ik weet niet welke andere server CPUs je kent, maar het grote verschil tussen de Itanium en de Xeons is de mate van schaalbaarheid. Er zijn (HP Super Dome) systemen waar tot 32 sockets/CPUs kan gaan, 8 TB memorty etc etc, dan is dat meer dan Xeon. Xeon kan nu tot 8 sockets. Daarnaast is HP-UX veel meer op enterprise zaken gericht (beheer, hot swap, partitionering van sub-systemen)

In server land zijn er eigenlijk maar 24* courante concurrenten, namelijk IBM met AIX/PowerPC en Oracle met Solaris/SPARC. Oracle heeft Solaris 12 gecancelled. Is eigenlijk IBM de enige serieuze tegenhanger. Voor HP is er al vele jaren geen nieuwe major versie van het OS (blijft op HP-UX 11.31 steken).

Door de jaren heen is Intel met zijn Xeons een stuk beter geworden (zeker prijs/prestatie), maar echt (symmetrisch) schalen tot heel veel CPUs kan niet met een Xeon. Maar kennelijk is de behoefte daartoe gedaald, en zet men meer in op parallelle computers, vaak per systeem niet meer dan 2 sockets (waar tegenwoordig tot een stuk of 20 of meer CPUs in zitten).

Maar noch Windows, noch Linux hebben de volwassenheid van HP-UX, Solaris of AIX. Je moet alleen wel een bak geld meenemen, om dit te willen. Grote bedrijven die een zeer betrouwbare infrastructuur willen (99,999% uptime), zoals overheidsinstanties, banken, gebruiken nog steeds non-Intel servers. Al zijn daar ook verschuivingen.

Itanium was, toen het kwam (2001) een revolutionair concept (tegen de toen bekende Intels) en bedoeld voor parallelle processing (EPIC). De rest kun je wel vinden via google.

Edit: * ik vergat AS/400 (IBM i) en zOS (IBM z). De laatste is een mainframe, de eerste deelt bijna 100% van de hardware met AIX (en eventueel Linux) op PowerPC.

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

[beerse]

Origineel was het grote voordeel van de itanium processors dat ze een schoon, 64-bits ontwerp zou zijn geweest. Itanium zou het goede van de HP (PA-RISC) en de Intel processor-kennis bij elkaar zijn. Het zou de opvolger van het x86 en PA-Risc platform moeten zijn, concurent van PowerPC en Sparc.

En toen kwam AMD met 64 bits uitbreiding op hun x86 compatible platform. msWindows was ooit beschikbaar voor beide platformen maar veel applicaties niet.

De nagel aan de doodskist van de grote unix processoren is vooral het opkomen van de cluster systemen. Daarmee kwam het besef dat het niet om de beschikbaarheid van een server gaat maar om de beschikbaarheid van een service.

[Peran]

[..] Daarmee kwam het besef dat het niet om de beschikbaarheid van een server gaat maar om de beschikbaarheid van een service.

Mooi gezegd

[kdekker]

En met een prijs die een stuk lager was. Maar goed, er zijn nog steeds redenen om voor een dik powerPC of een Solaris farm te gaan. Maar dan meer omdat het zover verder schaalt en in beheer prettiger is.

HP levert doorgaans 5 jaar support op hardware + 5 jaar obsolence support. Over 10 jaar is HPUX (i.c.m. Itanium) w.s. definitief weg. Het is dan wel een interessante vraag of HPUX met Xeons komt. En wat de concurrenten doen. Zo heel hard gaat het ook niet meer en Xeon land. Ik ben benieuwd.

[Wivern]

Banken zijn al lang aan het overschakelen naar goedkopere systemen. HPUX, AIX, Solaris... Allemaal legacy in ons bedrijf. De toekomst is Linux (Red Hat in ons geval) en Windows.
Bijna allemaal virtueel.

[Pathogen]

Waarschijnlijk speelt hier mee dat mankracht voor AS/400, HPUX, AIX, Solaris en zOS ook langzaam aan het uitsterven is.
Dan kan het platform nog zoveel beter zijn in wat het moet doen, als er niemand is om het op te vangen als die 0,00001% downtime begint, dan wordt dat percentage snel hoger

[Lordfox73]

Ach ja, en de 99,999% uptime van het systeem is leuk, maar als je (E)VPN met je businesspartner maar 99,95% is, dan is het ook overkill.

[tweaknico]

Nee dat is het niet noodzakelijkerwijs....

overigens bij 99.999% praat je over 8 uur acceptable downtime
bij 99.99% over al ruim 88 uur
bij 99,95% over 438 uur = > 2.5 week downtijd...???
terwijl >5 minuten onacceptabel kan zijn...
= 99.99999% uptime..., en dat zijn omgevingen waar IA64 van toepassing is.

5 minuten oponthoud voor recovery om bv. alle PIN automaten van NL weer te kunnen laten werker is van heel andere orde als een groot deel van NL 4 uur bij de kassa te laten wachten....(of blijf jij wel zo lang bij een kassa wachten tot je voorganger kan betalen...?)
Voor transactionele systemen kom je vrijwel altijd tot een enkel punt waar alles op tijd en goed moet gaan.... Een een (E)VPN .... moet dan maar in 2/3/4/ n-voud worden uitgevoerd met aanpalende maatregelen.

Edit:
Even alle berekeningen corrigeren...

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

[Keneo]

Je bent blijkbaar de eerste 2 negens van je 99,95% vergeten tellen?
365*24*.0005 = 4.38, dus net geen 5u downtime/jaar

99.999% uptime is net iets meer dan 30 sec downtime, niet 8u...

[beerse]

Veel mankracht voor de grote unix systemen is misschien wel via het gnu-platform naar linux gemigreerd. Uit mijn Solaris/HP-UX tijd (in de telecom) weet ik dat we veel met gnu-tooling deden zodat we de zelfde code konden gebruiken op de verschillende platformen. De Dec-Ultrix en Dec-VAX systemen iets minder maar dat was vooral omdat daar andere zaken op werden ontwikkeld.

Van AIX en andere grote unix implementaties met eigen hardware kan ik mij alleen maar voorstellen dat die ook een goede gnu-tool set hebben.

En wat de meesten 'linux' noemen heet formeel 'Gnu-Linux': De Gnu tooling en een Linux Kernel. Dus raad eens waar de kennis en vaardigheid zit?

[kdekker]

Banken zaten lang op AS/400. Naast zOS (beide van IBM) noemde ik die niet. Dat zijn systemen die ook nog wel in het rijtje AIX, Solaris, HPUX zitten. Als is zOS echt een mainframe, de rest niet.

[celshof]

Ik weet van de grote banken in Nederland dat een groot deel van de processing (betalingsverkeer en soms Clearing&Settlement) zeker niet op goedkopere systemen draaien. Daar draaien (soms net nieuwe) IBM mainframes op een heel specifiek pakket voor betalingsverkeer.

Belangrijke factor is uiteraard dat elke verstoring op deze systemen kan leiden tot voorpaginanieuws. Even herstarten en de klant moet maar even wachten is er dan ook niet bij.

Verre van legacy dus.

[marcovtjetje]

Zulke systemen zijn er ook Xeon /x86 based hoor.

Unisys heeft er een aardige business aan gehad, en ook HP had er. IBM was unisys reseller geloof ik (ik volg dat segment niet meer, allemaal van geheugen, maar google maar eens unisys en x86 of xeon)

Maar goed, begin 2000 was dat anders. Overigens is Itanium niet alleen RISC maar met name EPIC/VLIW, en dat is voor niet vectorprocessoren (GPU) toch wat minder praktisch gebleken.

Je wisselt in feite de ene decoder bottleneck (CISC complexe instructies) voor de andere uit (bundles met maar een instructie erin in relatief gebranchte code)

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

[kdekker]

Qua prijs is Unisys dan ook aardig te vergelijken met een stevig IA64 systeem :-).
Vroeger had je ook nog Tandem, Sequent, en wellicht vergeet ik er dan nog wel eentje.
HP heeft nog steeds dikke Xeon systemen (die ze verwarrend genoeg, nu ook Integrity noemen, een naam die voorheen voorbehouden was aan de Itanium lijn), maar of dat allemaal zo ver schaalt als AIX/Solaris/HPUX? Ik weet het niet.

In de 'wat nu gangbaar' is, is de Xeon MP serie de top. In een Xeon E7 familie is 8 sockets nu volgens mij max. (met 24 cores/48 threads). Ook gezellig spul, en navenant pittig geprijsd. Kun je een leuke auto voor kopen.

[celshof]

Tandem, nu HP NonStop, is er nog steeds. Het heeft een lange tijd ook op Itanium gedraaid, maar ik dacht gelezen te hebben dat ze ook overstappen naar x86

[Jexecute]

IA-64 komt van itanium processoren ze worden in principe gebruikt voor grote database servers die enkel op 64bit draaien.
Niet zoals onze klassieke x86-64 processoren.
In de overgang naar 64bit was dit zeer gewenst en revolutionair nu wordt er vooral voor xeon gekozen. (onder Intel)

Een mooie opsomming;
Summary:
1.The Itanium uses the IA-64 architecture while the Xeon uses x86 architecture.
2.The Xeon cores are only capable of executing an instruction per cycle while the Itanium is capable of executing six.
3.The Itanium and other related hardware often lag behind in adopting newer technologies compared to Xeon.
4.The Itanium has a lot of problems with older software applications while the Xeon only had minimal troubles.
5.The Xeon is produced in large volumes while only small amounts of the Itanium are being produced.

source: http://www.differencebetw...between-itanium-and-xeon/

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

[Armin]

The Itanium uses the IA-64 architecture while the Xeon uses x86 architecture.

Technisch gebruikt de Xeon de AMD64 instructie-set, al is het inderdaad ook in staat de IA-32/x86 uit te voeren.

The Xeon cores are only capable of executing an instruction per cycle while the Itanium is capable of executing six.

Dit is gelukkig al zo'n 10 jaar niet meer waar.

[needless to say]

Niet helemaal correct. AMD64 is de naam die AMD gaf aan zijn implementations van x86-64. Andere chipmakers gebruiken ook andere naamgevingen, zoals x64 of EM64T. In werkelijkheid is het gewoon een extensie op de x86 instructieset, en geen vervanger daarvan. Zie oa. ook https://en.m.wikipedia.org/wiki/X86-64.

IA-64 was wel een vervanger en van de grond uit efficiënter, onder andere doordat er veel meer CPU registers beschikbaar waren. Omdat het een nieuwe architectuur was (en geen extensie), moesten applicaties specifiek voor IA-64 geschreven worden. En dat is ook direct de reden waarom het nooit veel gebruikt is. Door de lagere adoptie, investeerde Intel minder in IA-64. Door de hogere investering in x86, werden de verschillen grotendeels gecompenseerd (meer registers en instructies, grotere kloksnelheden, ...) waardoor de business case voor itanium grotendeels verdween.

[tweaknico]

Het probleem was niet zozeer de applicaties voor IA64... maar de compilers.

Oude CPU's waren CISC (Complex Instruction Set CPU) architectuur.... Veel hardware was er nodig voor decodering van instructies in een veelheid van modes als of niet met pre/postfix operaties, indexering etc.etc. maar ook het oplossen van alignment issues...

De CPU bouwers waren intern allang over naar een veel eenvoudige CPU model, met basis instructies, die dan vanuit de CISC decoder werden aangestuurd....
Toen zijn de Hardware bouwers de CISC laag van de chips af gaan slopen en de inmiddels RISC gedoopte interne CPU;s directer beschikbaar gaan stellen....
Dit had als gevolg dat de eerste RISC (Reduces Instruction Set CPU) implementaties voor geen meter liepen totdat de Compiler bouwers allerlei optimalisaties zijn gaan inbouwen die vroeger door de Instructie Decoders gebruikt werden voor optimalisatie van hardware gebruik....

IA-64 is weer een stap verder, het zijn een x aantal RISC Cpu's die expliciet worden aangestuurd... (EPIC, Explicit Parallel Instruction CPU) Met inherent nog hogere eisen aan de compilers.
die moeten gaan proberen te voorspellen hoe de software zich gaat gedragen en daar de zaak voor gaan optimaliseren.....

bv. zoveel mogelijk van een if/then/else/ gelijktijdig verwerken en op het moment van beslissen de berekende then of else definitief maken.... (werkt niet als er subroutine calls gedaan worden...) Loop unrolling... bv. for i = 1 ... n ; do
door de iteraties i=1, i=2 en i= 3 gelijktijdig doorrekenen (elk in een eigen sub-cpu ).
Als n=2 dan wordt het resultaat van i=3 niet gebruikt....

Voor IA64 (en PA) is et met name op dat vlak misgegaan, de compilers waren niet snel genoeg op niveau die noodzakelijk was en met name de compiler bouwers hebben het opgegeven om de optimzers voor deze EPIC architectuur verder uit te werken.

Ik vermoed dat ze teveel hoofdpijn kregen voordat er een voldoende generieke efficiente optimizer gebouwd kon worden.

Aanvulling:
Tevens zijn steeds meer eenvoudige rekentaken over geprogrammeerd naar GPU's, waarvan er dan gelijk een 1000 tal CPU's beschikbaar komen ipv. een 10tal. Niet dat dit eenvoudiger was, maar de specifieke winst is groter.

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

[SG]

Ik zie het toch heel anders. Intel en co hebben met Itanium kwa R&D flink uitgepakt. En geinnoveerd. Het idee is de nadruk op performance te verleggen naar compiler. Epic architectuur.

Het probleem is dus dat je enorm moet investeren in compiler divisie.

Op zich geen probleem. Als je de middelen geeft dat daar aan gewerkt wordt.
Maar er gebeurde extern iets en andere grote speler heeft zich ook laten gelden.

Bij gebrek aan R&D middelen moest AMD iets verzinnen waarmee je alle markten kan bestijgen ook server. Houd in dat je met gemeen schappelijke architectuur. De consumenten producten vroeg opzadeld met 64bit en extentie op x86 AMD64.
Omdat het te vroeg was hoefde iNtel niet direct te reageren.
En Microsoft springt op de AMD64 wagon.

Het is Microsoft die iNtel eigen flavor incompatible met AMD64 x86-64 the intel brdenksel , niet wilt ondersteunen. Blijkbaar hield MS hun poot stijver dan INtel. Zonder OS support voor intel had blijkbaar met overheersen van windows geen zin. Uiteraard noemt iNtel hun AMD64 flavor niet AMD64 maar EM64T of gewoon X86-64.

Legacy gedoe is blijkbaar zeer sterk. AMD ging toch periodiek goed met Opteron. En itanium is te excotisch en league hoger , dus ging iNtel verder met Xeon.

Ik denk eerder dat het plan was dat itanium uiteindelijk tot de workstation en instap servers moest belanden. Dan puur heavy_tin
Maar dat AMD64 dat orginele plan omzeep geholpen heeft.

Het is niet altijd dat innovatie wint het is eerder legacy dat innovatie blokkeerd.
Zo ook Larabee de resources en R&D en innovatie. Het was het uitieme eindpunt van general purpouse maken van gpu shader cores. Tot het gelijk trekken met normale cores.
Full blown vs lightweight maar dezelfde instructieset en extensies. De eerste gen niet. Maar latere gen. Dat is Xeon Phi.
Krijg meer de indruk dat zware innovatie juist averechts werkt.

C++ gaat nog steeds hard en zal nog wel decades blijven C++17
De legacy afgestote D taal is nog geen hoog vlieger. Ja legacy werkt belemmerend.

[Armin]

In werkelijkheid is het gewoon een extensie op de x86 instructieset, en geen vervanger daarvan

In principe correct, maar het hangt er wel vanaf hoe je extentie definieert. Het is ontworpen in de sfeer van de oude x86 interface. Dus het is enerzijds een uitbreiding, maar anderszijds is er ook écht goed gewied en allerlei oude 8 en 16 bit legacy zooi uit het DOS/Windows 3.x tijdperk verwijdert.

Ook is de klassieke x87 80-bits stack-based floating point interface deprecated verklaard en gunst van de SSE1/2 64-bit register SIMD interface (al kan software die het perse wil gebruiken x87 nog steeds aanroepen omdat voor de legacy IA-32 interface het verplicht aanwezig moet zijn).

En zaken als interrupt management zijn onder handen genomen, waardoor 64bit Windows nu hardware interrupt priorities kan gebruiken als onderdeel van de instructieset ipv zoals in 32-bit Windows volledig in software te moeten doen.

AMD64 was dus echt een stap vooruit, waar niet enkel wat zaken toegevoegd zijn maar ook zaken verwijdert en op vrijwel alle vlakken ook deels opnieuw ontworpen.

Verder wel/ook eens met IA-64. Dat was te abrupt en te radicaal anders, en daarom niet geaccepteerd door de industrie. Merk op dat IA-64 ook x86/IA-32 kan uitvoeren. In eerste instantie in de hardware, later - met ironisch genoeg betere performance - in software.

[tweaknico]

Xeon Cores hebben nog steeds die beperking, maar je hebt meer Cores/Die....

Itanium heeft ook tot 8 Cores/Die (met hyper threading 16 ) die ieder bundels van 6 instructies per clock cycle uitvoeren.

[Armin]

Xeon Cores hebben nog steeds die beperking, maar je hebt meer Cores/Die....

Moderne Xeon cores kunnen 3 a 4 instructies tegelijk fetchen per kloktik en naar de executie-units sturen. Aldaar kan het een aantal kloktikken duren alvorens ze zogenaamd 'retired' worden ("klaar zijn"). Echter elke opvolgende kloktik wordt er weer een nieuwe 3 a 4 jieuwe set instructies de Xeon ingeduwd.

Een Xeon is dus bij normaal gebruik altijd op met een groot aantal instructies tegelijk bezig. Dat is bij Intel al sinds de Pentium Pro uit het jaar 1995 zo.

Wat ik denk dat de oorspronkelijke schrijver bedoeld is dat bij normale instructies bij x86 en AMD64 traditioneel één instructie één data-element bewerkt. Bij IA-64/Itanium kon elke instructie meer dan één data-element tegelijk bewerken. Bij x86/AMD64 kan dat 'enkel' met speciale media instrcuties zoals MMX/3DNow/SSE/AVX/etc

Maar elke moderne Intel en AMD CPU kan moeiteloos meer dan één instructie tegelijk verwerken.

[tweaknico]

IA-64 kan niet zozeer meer data per instructie verwerken... (Vector Processor = SIMD) het is een MIMD model, waarbij steeds 3 instructies per bundel en 1 of meerdere bundel gelijktijdig verwerkt worden. Je kan middels predicaten registers bepalen dat bv. bij nader inzien de 2e instructie in de bundle niet meegenomen hoeft te worden.. (Een beetje zoals bij ARM instructie conditioneel kunnen worden uitegevoerd).

[Apache]

Ik was een toeschouwer op 2 grote itanium migraties voor oracle databases. Met veel fanfare werd het aangekondigd aan de business dat er grote snelheidswinsten te boeken zouden zijn. Dure servers werden geinstalleerd, dure oracle consultants begonnen hun oracle rac installatie en configuratie. Data werd gemigreerd, solaris skills werden bovengehaald.

En dan de moment of thruth, gelijkaardige performance, soms bizar vreemde issues zoals random explain plans etc, het was helemaal niet zo fantastisch als ze hadden gedacht. 1 van de migraties is ondertussen al lang terug xeon gegaan, en van de andere weet ik het niet, maar het zou me verbazen mochten ze dat nog gebruiken.

Itanium was een leuk experiment, maar laten we het niet meer noemen dan dat

[tweaknico]

Kortom een matig / slech voorbereide migratie...
Live migreren zonder dat je eerst software test etc?

IA-64 lijkt niet (kan niet vergeleken worden) met X86..., zeker niet mbt. performance, en optimalisaties. Waar je met een CISC nog weg kan komen met een matig design, of halve debug implementatie, zul je uitgebreide tuning/optimalisatie door een compiler moeten laten doen op een EPIC en in iets mindere mate ook een RISC.

[tweaknico]

het was een om en om ontwikkeling .....
i1 = Pentium, i2= oude IA64, i3 = Core, i4 nieuwere IA64, i5 = Core2..., i6 IA64 laatste generatie, i7 XEON.

En niet Itanium had problemen met oudere software, maar veel software had problemen met de architectuur waarin parallel verwerking de norm is....
Heel veel software is lineair..., en die workload past minder op een parallel georienteerde machine.
ie. de ontwikkelaars zijn nog steeds mannen..., een ding tegelijk. CPU;s zijn blijkbaar door mannen ontworpen met dit in gedachten...

[necessaryevil]

Dat gaat om compatibiliteit, vervangingsonderdelen, etcetera.

De x86 architectuur is ontwikkeld in de tijd van de 'semantic gap', opslagcapaciteit en werkgeheugen was duur en langzaam in verhouding met de rekencapaciteit van processoren. Men implementeerde complexe instructies, zodat je er weinig van nodig hebt om een bepaalde taak te creeëren, het gevolg: kleinere programma's.

Na enige tijd was door sneller en goedkoper geheugen de manier van processors bouwen niet meer optimaal en had de servermarkt behoefte aan een 64 bit architectuur, wat op den duur ook nodig zou zijn voor de consumentenmarkt. Daarvoor een nieuwe cpu gemaakt moest worden, ook zou alle software opnieuw geschreven moeten worden. Een bijkomend probleem was dat de x86 ver door is ontwikkeld, en daardoor erg snel - ondanks zijn bagage uit het verleden, bovendien heeft AMD later aangetoond dat het ook mogelijk is om een x86 compatible 64 bit processor te maken.

Inmiddels stelt de erfenis uit het verleden niets meer voor. De x86 instructies worden vertaald door een decoder, een speciaal deel van de processor. Voor die vertaalde instructies, micro-ops kunnen snellere processoren gemaakt worden.

De decoder kost wel energie en ruimte op de die, maar het leuke is dat de overhead van de decoder steeds een kleinere rol is gaan spelen naarmate de processoren sneller en complexer zijn geworden. Een van de laatste markten waarop de x86 architectuur nog een beperking vormt was die voor de mobiele telefonie, maar inmiddels zijn daar ook al redelijk snelle processoren voor (de Atom series), alhoewel Intel mijn inziens die boot wel een beetje gemist heeft; de defacto standaard voor smartphones is toch wel de ARM processor.

Waar de x86 nog wel een bottleneck zou kunnen zijn is in de allersimpelste processors/microcontrollers. Je moet dan denken aan de chips die in je wasmachine of in de afstandsbediening van je tv zitten.

Bron? Heb ik niet. Dit is mijn visie op het verhaal, de feiten heb ik in de loop der jaren verzameld en zullen in grote lijnen kloppen. Ik daag jullie ook uit om mijn verhaal aan te vullen, altijd leuk want ik vind dit interessante materie.

[BeosBeing]

Een van de laatste markten waarop de x86 architectuur nog een beperking vormt was die voor de mobiele telefonie, maar inmiddels zijn daar ook al redelijk snelle processoren voor (de Atom series), alhoewel Intel mijn inziens die boot wel een beetje gemist heeft; de defacto standaard voor smartphones is toch wel de ARM processor.

En daar zien we dan ook weer het omgekeerde. Inmiddels is ARM met o.a. de Snapdragon 835 ook zover dat deze x86 kan draaien. Het zou best wel eens kunnen dat in de toekomst ARM aan de onderkant van de markt (netbook, convertible, ultrabook) langzaam de Intel (en AMD) gaat verdringen. Het omgekeerde kan natuurlijk ook, dat er langzaam toch meer tablets en telefoons (Asus had er al een) gaan komen met Intel Atom cpu's. Vooral nu Android daar ook op draait (er zijn genoeg van die Chinese dual-OS tablets met Android en Windows) maakt het straks niet meer uit of je nu een ARM of een x86-soc hebt. In een telefoon met die laatste kun je in principe Windows draaien, maar met de eerste nu dus ook.

[tweaknico]

Ik zou het stuk iets willen aanpassen...

Het maakt niet meer uit welke processor er in zit zolang er maar voldoende support voor de hardware kant bestaat en er voldoende software voor beschikbaar is.
En om nu alle op Windows te gooien is het paard achter de wagen zetten, (van mij uit gezien). BSD wordt al op de nodige platforms ondersteund en heeft nogal wat minder issues.

Een JAVA based platform (android) zou op een ARM (+ java primitive engine) best wel een beter kunnen lopen dan op een x86...
mbt. moderne software is de x86 architectuur best beperkt in het het aantal beschikbare registers.

[BeosBeing]

Ik zou graag op BSD overstappen. Helaas ben ik voor m'n werk gebonden aan een aantal Windows apps (Access, Excel, Word, Acrobat, Finereader Pro, Trados en andere branchespecifieke software)

[tweaknico]

Access, Excel, Word... LibreOffice?
Acrobat.. (Reader heeft alternatieven)

Verder als er een MAC versie bestaat dan is het gros voor porting naar een Unix al gedaan. (Behalve frontend).

[BeosBeing]

Thuis gebruik ik al Libreoffice en ja voor thuis voldoet het prima.

Op het werk is Word de standaard.

Excel macro's is echter een ander verhaal. Base is evenmin een goed alternatief voor Access, zeker niet als je hele VBA-bouwwerken nodig hebt om bepaalde zaken voor elkaar te krijgen. Ja er kan met Access heel veel wat met Base of andere dingen niet kan. (Al maakt de macrobeveiliging in Office het wel steeds lastiger).

Acrobat, ik had het niet over de Reader maar over de editor.

Trados ga je wijselijk niet op in, maar voor Mac heb je de keus uit Bootcamp, Parrallels, Fusion of andere virtual machine software, uiteraard in combinatie met een Windows-installatie. (en communiceert dan ook niet met Office voor Mac)

Ik zou op die BSD wel Wine gaan draaien.

[tweaknico]

ARM kan dat ook zonder SnapDragon... Er is QEMU beschikbaar die aardig wat CPU's kan emuleren ook op ARM chipsets. performance van een XEON heofje dan natuurlijk niet te verwachten op een 200Mhz oid ARM ... ;-)

[BeosBeing]

De Snapdragon 835 was ook maar een voorbeeld dat nu toevallig veel in het nieuws komt en dus bekend is. QEMU is natuurlijk een volledige emulator en dat gaat zeker in dit soort gevallen met performanceverlies gepaard. De Xeon is dan wel een mogelijke vervanger voor de Itanium maar een gewone ARM-chip zelden en doe je dat toch dan gooi je er waarschijnlijk meerdere cpu's of een cluster tegenaan.

[marcovtjetje]

Zie boven. De unieke feature van Itanium was niet RISC maar VLIW.

Daarnaast hoewel dat iedere boer weet te vertellen dat de x86 naar simpelere instructies onder de motorkap vertaalt, wordt nog al eens vergeten dat met macroop fusion de RISCs toch ook wel weer een beetje CISCy zijn geworden

Zie ook mij Itanium post tijdens de aankondiging van deze processoren: marcovtjetje in 'nieuws: Intel levert vijf jaar na vorige generatie weer nieu...

[Mr_gadget]

Nu niet veel meer. Maar het is een echte 64 bit processor met RISC(Reduced Instruction Set) wat ze snel maakte voor berekeningen. De Xeons en onze core I processoren zijn. CISC(Complex Instruction Set Computing).

[Armin]

Dat onderscheid is anno 2017 eigenlijk niet meer correct.

Xeons en vrienden zijn enkel CISC wanneer je naar de totale instructie-set kijkt zoals aan de CPU gevoerd kan worden. Als je kijkt naar het interne fucntioneren - ofwel hoe ze uitgevoerd woren - zijn ze net zo goed RISC aangezien elke instructie opgesplitst wordt in kleinere micro-ops. Ook als je kijkt wat compilers gebruiken van de totale AMD64 instructieset, is het doorgaans maar een zeer kleine sub-set, en meer zoals tranditioneel RISC werkt.

Tenslotte traditionele RISC CPU's zoals ARM, hebben zo ontzettend veel fucnties toegevoegd aan hun instructie-set dat die ook nauwelijks meer traditioneel RISC genoemd kan worden.

[Anoniem: 718429]

Dat onderscheid is anno 2017 eigenlijk niet meer correct.

1995 belde en wil z'n argument terug.

Xeons en vrienden zijn enkel CISC wanneer je naar de totale instructie-set kijkt zoals aan de CPU gevoerd kan worden. Als je kijkt naar het interne fucntioneren - ofwel hoe ze uitgevoerd woren - zijn ze net zo goed RISC aangezien elke instructie opgesplitst wordt in kleinere micro-ops.

Dit hoor je wel vaker maar het is ook complete onzin.

Om te beginnen gebruiken ook klassieke CISC-processoren microcode, en is dat ook wel aangevoerd als "defining feature" van CISC, dus om dat als "ja maar het is echt RISC hoor, want microcode" te willen beargumenteren is een beetje vreemd.

Maar waar het om gaat is precies dat wat de compiler "ziet" aan interface, en dat "oh ja maar het is RISC eronder hoor!" daar heb je als compiler relatief heel weinig aan. Je kan met heel erg veel logica, register renaming, en ander fancy footwork wel iets verbeteren, maar een betere instructieset is altijd een beter idee omdat je dan heel direct en met veel minder moeite de compiler efficientere programmas kan laten genereren.

Dat zag je aan de x86/AMD64 overgang, waar ook programmas van profiteren die niet profiteren van de extra adresseerruimte of zelfs de extra bitjes in de registers, terwijl ze er dus wel voor betalen met extra geheugen en dus ook extra druk op de cache. De grote winst zat 'm in de grotere registerfile, want dan heeft de compiler meer ruimte om variabelen aan registers toe te wijzen. Dat is geen eigenschap van "64bit", maar een ontwerpprobleem in x86, en eentje die eigenlijk altijd wel bekend was.

Dus zie je dat het ontwerp een nogal nauwe flessehals heeft, waar je aan beide kanten van de flessehals --heel veel "verborgen" registers en nog meer extra transistors voor de renaming en al dat andere aan de ene kant, en heel veel logica in de compiler om maar zo efficient mogelijk toe te wijzen rekening houdend met de quirks geintroduceerd door al dat gedoe "achter de schermen"!-- extra werk moet verrichten om dat een beetje op te lappen. Knip die flessehals eruit en het scheelt transistors en lijnen code en je programma wordt er nog sneller door ook.

Daarom, "het heet CISC maar is RISC onder de motorkap" is werkelijk complete onzin. Het is gewoon een stom ontwerp en dat willen verdoezelen met complexiteit en mooie praatjes is niets anders dan stug op de oude voet doorgaan en met mooipraterij van de negatieve kanten proberen af te leiden. Des te jammerder dat x86/AMD64 gewonnen heeft, want het was niet op technische merites.

Daarnaast, hoeveel extensies en extensies op extensies hebben de meest recente intel en AMD processoren wel niet? Daar is niets "Reduced" aan. Als dat een argument is tegen ARM (dat een expliciet coprocessormodel heeft, al zijn niet alle extensies ook zo geimplementeerd), dan is het nog meer een argument tegen x86 en AMD64.

Overigens is itanic niet zozeer "RISC" als wel "EPIC" en "VLIW". Toch net even andere inslag, en daarover lezen is wel iets om wat regenachtige zondagmiddagen mee zoet te zijn.

[Armin]

Om te beginnen gebruiken ook klassieke CISC-processoren microcode, en is dat ook wel aangevoerd als "defining feature" van CISC, dus om dat als "ja maar het is echt RISC hoor, want microcode" te willen beargumenteren is een beetje vreemd

De eerste generaties CISC processoren executeerden CISC wél als CISC.

Mijn punt was meer dat er een verschil is tussen een CISC instructieset en een CISC processor. De x86 instructieset is nog steeds CISC of op zijn minst sterk CISC georienteerd, doch intern is Intel/AMD dat al sinds de K5 generatie niet meer CISC.

Het verschil tussen CISC en RISC kun je verder niet alleen bespreken in context van de processor, maar ook in complexiteit van de compiler. Dat zjn namelijk twee kanten van hetzelfde muntstuk. Er is geen enkel compiler voor AMD64/x86 die nog code genegeerd die die complexe tranditionele CISC instructies gebruikt. Daarvoor in de plaats zie je dat bijvoorkeur - zoals bij RISC gebruikelijk - men operaties opbreekt in meer elementaire instructies. Denk aan worteltrekken, sinus berekenen, etc.
Andersom op ARM64 wat men traditioneel RISC noemt, talloze instructies toegevoegd die meer high-level "CISC"-achtig zijn juist omdat het daar performance winst oplevert. Het onderscheid vervaagt ...
Op ARM32 wat men traditioneel RISC noemt, is het aantal instrcuties zelfs zo groot dat de instructie-ruimte bijna vol is. Verre van tranditioneel 'reduced' waar de R in RISC voor staat.

Het verschil tussen CISC en RISIC is een historisch verschil dat tegenwoordig enkel nog een leerzame plaats heeft in de schoolboeken om concepten te begrijpen. Echter moderne chips (zowel Intel, ARM, MIPS, etc) zijn altijd een mengsel van beide filisofieen plus allerlei meer moderne concepten zoals VLIW/SIMD en vooral veel invloed van DSP's.

Dus complete onzin is wat ik schreef zeker niet

Meeste wat je schreef is bovendien waar maar niet in tegenspraak met wat ik beweer of zelfs maar probeerde te suggeren?

[Anoniem: 718429]

Om te beginnen gebruiken ook klassieke CISC-processoren microcode, en is dat ook wel aangevoerd als "defining feature" van CISC, dus om dat als "ja maar het is echt RISC hoor, want microcode" te willen beargumenteren is een beetje vreemd

De eerste generaties CISC processoren executeerden CISC wél als CISC.

Ja, maar ze hadden zelf ook microcode. Wat dat betekent? Ga maar eens kijken naar bijvoorbeeld de "magic-1" zelfgeknutselde CPU. Dat ding is opgebouwd uit "~200 74 series TTL chips", en heeft ook microcode.

De x86 instructieset is nog steeds CISC of op zijn minst sterk CISC georienteerd,

Dit is waar.

doch intern is Intel/AMD dat al sinds de K5 generatie niet meer CISC.

En dit is pure marketeering. Oneigenlijk want technisch gezien heb je er helemaal niets aan. Minder zelfs, want je weet zeker dat je minder prestaties per transistor terugziet, vergeleken met een architectuur zonder die flessehals.

Oh en ik denk dat je niet de amd k5 maar de intel pentium pro bedoelt, daar was die discussie over als ik het me goed herinner. Maargoed, 1993, 1995, dat is waar jouw "anno 2017"-argument vandaankomt. Het was toen oneigenlijk, en het is nu niet minder oneigenlijk.

Het verschil tussen CISC en RISC kun je verder niet alleen bespreken in context van de processor, maar ook in complexiteit van de compiler. Dat zjn namelijk twee kanten van hetzelfde muntstuk. Er is geen enkel compiler voor AMD64/x86 die nog code genegeerd die die complexe tranditionele CISC instructies gebruikt.

Lijkt me dat een compiler nog steeds gewoon de meest efficiente instructies pakt die met het minste gedoe gedaan krijgt wat'ie nodig heeft. Als dat een "CISCy" instructie is dan pakt'ie die. Scheelt om te beginnen registerdruk.

En hier zien we het grote verschil tussen x86 en AMD64: x86 heeft 8 registers, waarvan 4 algemeen inzetbaar (32bit mode EAX, ECX, EDX, EBX) en de andere vier dus niet, of iig minder (ESP en EBP stack en frame pointer, ESI en EDI, string index registers). AMD64 heeft die allemaal tot 64bit uitgebreid en er nog eens acht bijgedaan. Dat betekent dat je compiler dus (8+8-4=) 12 registers vrij te kiezen heeft, dat is dan dus drie keer zo veel. Verdubbeling registerfile, verdriedubbeling algemeen inzetbare registers. (Er was een prijs, natuurlijk, maar die details laat ik maar even als huiswerk.)

Dat betekent dat je compiler veel meer met registers kan doen en dus minder naar het (veel langzamere) geheugen moet grijpen. Dus zullen er minder instructies van de vorm "OP mem,reg" en meer van de vorm "OP reg,reg" te zien zijn... maar nog steeds worden die neergezet naargelang de noodzaak, niet omdat je ze uitelkaar hebt kunnen trekken in simpelere instructies. Integendeel, er komen alleen maar steeds meer nog ingewikkeldere instructies bij.

Daarvoor in de plaats zie je dat bijvoorkeur - zoals bij RISC gebruikelijk - men operaties opbreekt in meer elementaire instructies.

Een typische RISC architectuur kan of een geheugentoegang of een ALU- of andere operatie. x86/AMD64 kan dat combineren, en waarom instructies niet gebruiken als ze er wel zijn? Nouja, goed, als andere instructiecombinaties sneller zijn, dan pak je die. Zo gebruikt er niemand de x86 instructie "loop" omdat die wel lekker kort is maar twee andere instructies zijn samen wel langer maar ze doen hetzelfde en zijn gewoon sneller, dus pakken we die.

Als je intern gaat kijken, overigens, dan zijn allerlei separaat gecodeerde instructies (insn a, insn b, in die volgorde, voor zekere insn a en insn b) voor de x86/AMD64 machinerie achter de schermen eigenlijk stiekem toch één instructie want dan kunnen ze er wat performance extra uit persen. Dus volgens jouw redenering zijn moderne processors CISCer dan CISC.

Denk aan worteltrekken, sinus berekenen, etc.

Die schuif je zoveel mogelijk door naar de ondertussen al een tijdje ingebouwde coprocessor. Of een van die andere extensies.

Het verschil tussen CISC en RISIC is een historisch verschil dat tegenwoordig enkel nog een leerzame plaats heeft in de schoolboeken om concepten te begrijpen.

Dat denk ik niet. Dat "moderne" processoren er een zooitje van bakken mag zo zijn, maar het idee achter "RISC", mits goed uitgevoerd, is nog steeds krachtig. Maarja, dan moet je niet in marketeeringpraatjes geloven.

Dus complete onzin is wat ik schreef zeker niet

Je komt met een vreselijk gedateerd stukje marketeering wat een schadelijk gedachtenspinsel neerzet. Dat is niet alleen onzin, dat is gevaarlijke onzin.

Wil je beter schetsen wat je denkt, laat dan dat marketingpraatje varen en probeer het opnieuw.

[Armin]

Ja, maar ze hadden zelf ook microcode

Nee, misschien omdat ik al oud ben en daarom in andere tijdschalen denk, maar ik heb het over CPU architecturen van 10 a 20 jaar ouder dan de magic-1. Dat is CISC instructie-set én CISC-executie. Geen enkele moderne CPU die nu nog zo werkt bij mijn weten.

En dit is pure marketeering. Oneigenlijk want technisch gezien heb je er helemaal niets aan. Minder zelfs, want je weet zeker dat je minder prestaties per transistor terugziet, vergeleken met een architectuur zonder die flessehals.

Ik noem het niet pure marketing, aangezien het gewoon is hoe de processor feitelijk werkt. Als je bezwaar is dat de interne micro-ops geen RISC mogen heten, welnu dat ben ik met je eens, want dat is precies mijn punt: huidige CPU's zijn nooit puur CISC of RISC (anders dan wellicht heel simpele RTOS-chips).

Miro-ops RISC noemen is net zo goed een versimplificatie ("marketing") als dat de AMD64 instructie-set CISC zou zijn.

En dat er een overhead is om instructies te vertalen is waar. Dat is de prijs van compabiliteit. Dat doet echter niets af aan wat ik verder schreef. ARM64 heeft overigens inmiddels ook al een soortgelijke vertaal-laag, omdat ook daar het niet meer mogelijk is om elke generatie een nieuwe compiler-instructieset mee te geven.

Andersom is AMD64 code compacter, hetgeen voordelen heeft betreft instructie issue en I-cache gedrag, ook al maakt het de decoder stap complexer. Dat echter wordt weer deels ondervangen door gedecodeerde instructies te cachen ipv ongedecodeerde. Nu zul jij zeggen daty je die hele prut liever niet nodig zag, maar dan gooi je dus weer compabiliteit weg. Elk 'voordeel heb zo zijn nadeel' zeg maar

Nogmaals, vrijwel alles wat je stelt is niet in conflict met wat ik schrijf. Het lijkt erop dat je vooral valt over het woordje RISC vs CISC.
Welnu ...

Een typische RISC architectuur kan of een geheugentoegang of een ALU- of andere operatie. x86/AMD64 kan dat combineren

Als dat je definitie is om RISC en CISC te onderscheiden, is elke ARM64 ook reeds CISC. ARM64 kan inmiddels ook bepaalde ALU en load/stores in één instructie invoeren. Andersom geen enkel x86/AMD64 chip executeerd die twee operaties tegelijk ook al laat de instructie je inderdaad een memory adres als bron meegeven.

Ik noem dat geen marketingpraat, maar de realiteit accepteren dat RISC en CISC concpeten zijn uit de begingeschiedenis van de microchip-architectuur die niet meer zwart-wit gelden in moderne chips. Is dat nu echt zo'n controversieel punt dat ik maak?

[Anoniem: 718429]

Ik noem het niet pure marketing, aangezien het gewoon is hoe de processor feitelijk werkt.

Het punt is dat het gaat om een trade-off in de ISA, niet in de implementatie. Zo van "ja maar onder de motorkap hebben we ook een F1 motor, hoor!" is heel leuk maar als de rest van het vehikel stiekem een bulldozer is en geen raceauto ben je nog steeds appels met peren aan het vergelijken.

(Wat niet wil zeggen dat een goede motor in een bulldozer geen goed idee is. Caterpillar heeft hun eigen motor ontworpen en gebouwd en daar hebben ze hele goede redenen voor. Ik denk zelfs dat ik liever zo'n motor heb dan zo'n racepaardje, dus heb ik het voorbeeld verkeerdenom opgezet. Oeps.)

Miro-ops RISC noemen is net zo goed een versimplificatie ("marketing") als dat de AMD64 instructie-set CISC zou zijn.

De AMD64 set is een opgeleukte x86, niet fundamenteel anders.

Wel leuk om bv. wikipedia er even bij te pakken:
AMD64 still has fewer registers than many common RISC instruction sets (which typically have 32 registers[citation needed]) or VLIW-like machines such as the IA-64 (which has 128 registers). However, an AMD64 implementation may have far more internal registers than the number of architectural registers exposed by the instruction set (see register renaming).
Dat is hetzelfde "onder de motorkap" argument uit 1995.

En ik zeg, die redenering is grote onzin.

Andersom is AMD64 code compacter,

Een "CISCy" x86 feature, doordat er dingen impliciet worden aangenomen die je met ARM, MIPS, POWER, Alpha, e.d. expliciet moet opgeven.

hetgeen voordelen heeft betreft instructie issue en I-cache gedrag, ook al maakt het de decoder stap complexer.

Hoorde overigens dat in een zekere implementatie de ARM decoder zowaar meer real estate kostte dan een x86/ARM64 decoder. Geen idee welke ISA niveaux dat over ging overigens (zeggens hoeveel extensies in beide en of dat wel vergelijkbaar was).

Vraag me wel af in hoeverre de encoding nog voordelen heeft want met al die steeds exotischere extensies worden de instructies ook niet korter.

Dat echter wordt weer deels ondervangen door gedecodeerde instructies te cachen ipv ongedecodeerde. Nu zul jij zeggen daty je die hele prut liever niet nodig zag, maar dan gooi je dus weer compabiliteit weg. Elk 'voordeel heb zo zijn nadeel' zeg maar

Het eerdere punt was dat in het geval van de x86 registerfile flessehals je truukerij je dwingt een berg transistors in te zetten die vervolgens complexiteit toevoegen in de compiler die daar rekening mee moet houden. Technisch gezien ligt het dan voor de hand dat je beter een ISA kan pakken waar die flessehals niet bestaat. Dat aspect zie ik in deze opmerking niet terug.

Dat er in plaats daarvan met een "onder de motorkap"-argument gezwaaid werd was dan ook niet uit technische overwegingen. Het was marketeering, met een politiek tintje: Aanval op de concurrentie.

Het was rationalisatie om met intel (en windows) te blijven hangen en niet, bijvoorbeeld, een leuke sgi indigo2 met een loeisnelle (zeker voor de 195MHz) R10k MIPS cpu te pakken.

Ondertussen zijn de transistortellers ontploft en vertellen we onszelf nog steeds dat dezelfde brakke architectuur van toen een goede keus was om te verherimplementeren en met steeds meer bergen transistors maar te biereco herversnellen.

Hadden we dat allemaal niet gedaan maar de moeite gestoken in iets wat minder brak was dan hadden we nu best eens structureel snellere CPUs kunnen hebben. Het is precies dat "onder de motorkap"-argument dat we gebruiken om onszelf in slaap te sussen. "Oh nee we hoeven die flessehals niet weg te halen we hebben een hele grote motorkap waar heel veel onder past."

Ik noem dat geen marketingpraat, maar de realiteit accepteren dat RISC en CISC concpeten zijn uit de begingeschiedenis van de microchip-architectuur die niet meer zwart-wit gelden in moderne chips. Is dat nu echt zo'n controversieel punt dat ik maak?

Ik denk dat het onzinrationalisatie is, ja. Niet het gedeelte dat er ondertussen veel veranderd is. Wel het stukje hoe de redenering inelkaarzit en waar hij vandaankomt. Oude zombierationalisatie die al heel lang geleden begraven had moeten worden, samen met de hele x86/AMD64 ISA.

Edit: kapotte quote

[Reactie gewijzigd door Anoniem: 718429 op 23 juli 2024 23:00]

[fantafriday]

En toch wil het weleens voorlomen dat op IBM power je database x keer sneller gaat dan op x86/amd64.

[needless to say]

En in de praktijk zijn xeons intern ook risc processoren geworden, die via een vertaalslag complexe instructies kunnen verwerken.

[gast128]

Het is eigenlijk een EPIC processor.

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

[GingerLionXx]

Denk niet veel. Aangezien ze er mee stoppen. Waarschijnlijk zijn de xeons toch beter dan itanium.

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

[vavoem]

Dat vermoed ik wel. Maar de Itaniums worden volgens mij alleen gebruikt voor HPUX en dat is ook uitstervend vele HPUX omgevingen worden verruild voor een Linux variant.

[OruBLMsFrl]

Qua rekenkracht zijn de Xeons verder. HP-UX klopt ook helemaal. Qua architectuur heeft de Itanium heel mooie eigenschappen. Maar hoofdreden om nu een Itanium te kopen is gek genoeg zakelijk (maatwerk) software. Die kan erg kostbaar zijn om naar een x86 architectuur en linux om te zetten. HP-UX heeft ook andere OS libraries namelijk. Dus je moet echt flink aan de slag dan... een paar van dit soort servers tegenover tientallen zoniet honderden manmaanden zijn haast verwaarloosbaar qua kosten.

Stel je een business case voor waarbij je in de toekomst voordeliger over kunt stappen op een dan verder ontwikkelde cloud oplossing ter vervanging van de software die nu nog op de Itanium draait. Je kunt de oude software nu dan nog tot wel 10 jaar extra hardware ondersteuning bieden met deze laatste nieuwe Itanium generatie.

[Anoniem: 718429]

Qua rekenkracht zijn de Xeons verder. HP-UX klopt ook helemaal. Qua architectuur heeft de Itanium heel mooie eigenschappen.

itanic is vanaf het begin technisch nogal een flop geweest, leuk idee maar intel kreeg het niet performant. Het draaide dan ook vooral op wensdenken, zie dat beruchte grafiekje op wikipedia bijvoorbeeld. En er is nogal veel harder aan de x86/amd64 ontwikkeling getrokken, want daar zat het geld.

Dit is ergens wel jammer want als je snapt waar AMD64 het gros van de versnelling
tegenover x86 vandaanhaalt --het aantal registers, meer dan de registerbreedte-- dan snap je wellicht ook (één reden) dat x86 al heel lang dood had moeten zijn en vervangen door iets beters. Alpha bijvoorbeeld.

Bedenk dat intel sterke en zwakke punten heeft. "Proces" is een sterk punt, ze zijn meestal een node of twee de rest vooruit, wat betekent dat ze hoger kunnen klokken en daar minder voor hoeven te verstoken. (En dat in hele grote volumes. IBM doet snellere chips maar die maken er een stuk minder.) Nu de fut een beetje uit dat procesverbeteren lijkt, voorlopig althans, zitten ze in de knel.

Wat geen sterk punt is, ook niet was, is chipontwerp, en ze moeten een hele historie aan minder geweldige ontwerpideetjes meetorsen. Vanaf de 8086 met de segmenten en de "640kB" (nouja, 1MB, maar peeceeontwerp, al is dat IBM z'n schuld). Maargoed, intel heeft nogal last van NIH dus die pakte geen bestaand beter ontwerp, die verzonnen zelf iets nieuws. En dat flopte, en hard. En toen zette AMD intel keihard voor het blok met AMD64. Tsja.

Maar hoofdreden om nu een Itanium te kopen is gek genoeg zakelijk (maatwerk) software. Die kan erg kostbaar zijn om naar een x86 architectuur en linux om te zetten. HP-UX heeft ook andere OS libraries namelijk. Dus je moet echt flink aan de slag dan... een paar van dit soort servers tegenover tientallen zoniet honderden manmaanden zijn haast verwaarloosbaar qua kosten.

Als dat alles was, en als je de source hebt dan is porteren van de ene Unix naar de andere Unix(-achtige) niet heel moeilijk. Hier hebben we POSIX voor. Het is zelfs makkelijker om van bijvoorbeeld een *BSD naar linux te porteren dan andersom (want linux is raarrrr). De schoen wringt dus net even anders.

Bedenk dat hp zowel PARISC als Alpha AXP opgeofferd heeft en zeg maar een IBM-achtige "bet the company" op itanic geprobeerd heeft... alleen ging het niet helemaal goed. Iets wat commentatoren al vanaf het begin verwacht hebben en ook een reden waarom Carly Fiorina... niet erg geliefd is onder techneuten. Ze is ook hp uitgeflikkerd wegens wanprestatie.

Maargoed, hp had geen eigen chips meer en moest dus alles op itanic gaan doen. Dus VMS moest ook over, en dat is een stukje stabieler dan Unix(!) dus daar draaiden allerlei zeer kritieke software op. Daar hoor je bijna nooit wat van want als het eens goed misgaat blijkt het meestal een windowspeecee te zijn geweest die een spontane meltdown gehad heeft en toen bleek, ik noem een dwarsstraat, geen air traffic controller nog te kunnen zien welk vliegtuig waar rondvliegt.

Het gaat dus niet zozeer om de software, maar om allerlei garanties eromheen, van betrouwbaarheid, stabiliteit, en zo verder. Iets wat je met commodity hardware (opgeleukte desktopjes, dat blijft altijd Chinese rommel in vergelijking met Echte Servers) gewoon niet krijgt. Met de bijbehorende software ook niet, overigens. Wat dan weer "opgelost" wordt door gewoon heel veel meer servertjes neer te plempen en als er eentje het begeeft dan stel je dezelfde vraag maar aan een ander. Zo werkt "webscale", maar voor sommige toepassingen is dat gewoon geen optie.

Nu weet je ook waarom intel geen ruchtbaarheid geeft aan deze release. Ze moeten wel, maar ze willen het echt niet. Hele dure chips, jaren van R&D, en verkopen willen ze ze niet. Ze hadden eigenlijk al jaren geleden de hele geschiedenis willen vergeten, maar hp floot ze terug. Want afspraak.

Stel je een business case voor waarbij je in de toekomst voordeliger over kunt stappen op een dan verder ontwikkelde cloud oplossing ter vervanging van de software die nu nog op de Itanium draait. Je kunt de oude software nu dan nog tot wel 10 jaar extra hardware ondersteuning bieden met deze laatste nieuwe Itanium generatie.

Ik denk dat wat er (nu nog) op integrity draait niet heel erg snel naar "cloud" zal verhuizen. Dat is zeg maar Murphy op het spek binden.

[kdekker]

Dat zou ik ook verwachten, maar ik zie (waar ik werk) ook vaak genoeg Windows binnenrollen. Dat is wel een heel andere wereld. Raar maar waar. Linux lijkt me ook logischer, maar kennelijk is Windows eenvoudiger/beter aansluitend wat een organisatie toch al heeft (aan PCs) voor wat betreft het beheer.

Ik zie ook dat bij veel bedrijven de kennis niet zo heel veel verder reikt dan 'o is dat geen Intel dan?'. En waarom is het zo duur (minimaal factor 5 tot 100x)...

[vavoem]

Ja die wilde ik ook er bij noemen, maar ik weet wel dat HP-UX veel werd gebruikt voor SAP en Oracle omgevingen en dat deze veel al overgaan bij grote organisaties naar Linux als een Red Head ivm ondersteuning van ook SAP en kleinere zullen eerder naar Windows gaan omdat dat goedkoper te managen is een mixed omgeving is snel duurder omdat het vaak meer personeel vereist dan 1 platform. En overgaan van SAP op nieuw HP-UX of Linux of Windows kost qua werk niet veel meer of minder dus is het snel goedkoper om 1 van de 2 laaste te kiezen omdat voor beide de hardware krachtiger is en goedkopere hard en software. Een Itanium ontwikkelen kost lijkt me vergelijkbaar even veel als een Xeon tegen hangen maar de aantallen liggen lager dus de prijs hoger om de kosten te dekken.

[tweaknico]

Nee er zijn ook NON-STOP en OpenVMS voor IA64 beschikbaar.
OpenVMS komt naar x86 (nah alleen AMD64 modes)

[johnkeates]

Een Itanium is technisch 'beter', maar in de praktijk ingehaald door commodity hardware. Zelfde als de POWER architectuur dus eigenlijk.

[tweaknico]

Je vergeet dat de Power architectuur net als ARM heel veel in Micro controllers/ Netwerk apparatuur etc. wordt gebruikt. MIPS had daar vroeger ook een rol, maar die is door POWER overgenomen.
Beide komen veel voor in embedded oplossingen. Ik denk dat er bv. weinig auto's te vinden zijn zonder POWER. Zeker als je naar recente modellen kijkt (10 jaar en jonger) bijna geen.

POWER heeft een deel open Hardware architectuur waardoor diverse fabrikanten daar makkelijker mee kunnen integreren. Het Power ECO systeem lijkt enigszins op dat van ARM.

[johnkeates]

POWER wordt natuurlijk voornamelijk gebruikt om dat er miljarden geïnvesteerd is in hardened chips die bestand zijn tegen straling, hoge en lage temperaturen en fault-tolerant zijn. Dat was voornamelijk door het gebruik in de ruimte waar dat soort zaken vrij relevant zijn. Als bijkomstigheid kan je ze dan ook uitstekend gebruiken in auto's, maar ook vliegtuigen, tanks, boten enz. Dat komt allemaal voornamelijk voort uit legacy en niet zo zeer uit wat je nu beschikbaar hebt. Zo zou het zo kunnen zijn dat een embedded oplossing tegenwoordig net zo goed met ARM gedaan kan worden. MIPS is ook lang zo slecht nog niet, alleen laten ze het bij de marketing nogal afweten. Qua power/performance is MIPS prima in staat hetzelfde te bieden als ARM, maar alleen in het onderste segment door dat de 'beste' MIPS cores niet eens in de buurt komen van midrange ARM. Dat betekent echter niet dat low-end devices niet prima op MIPS kunnen draaien.

Uiteindelijk maakt dat allemaal niet zo veel uit in dit geval, want het ging over Itanum en daarmee voornamelijk de servermarkt en 64-bit CPU's. Daar hebben we slechts een paar spelers, Intel x86_64, POWER, en Itanium. Er waren natuurlijk ook nog wel andere opties zoals Alpha en misschien opkomende opties uit china, maar in de vergelijking valt voor commodity server hardware nagenoeg alles af. Stel dat we terug gaan naar 2006-2008, dan is Itanium en POWER allebei beter dan x86, maar dat is tien jaar geleden.

[NinjaTuna]

Upgraden als je huidige infrastructuur ook op Itanium gebaseerd is, lijkt me.

[Amazigh_N_Ariff]

Je kan er hele verhalen aan wijden, maar het komt er op neer dat het voor een Intel Monopoly moest zorgen.

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

[TheBorg]

Ik weet niet waarom dit weggemodereerd wordt maar het is zelfs niet onwaarschijnlijk dat het belangrijkste doel van de Itanium was de DEC Alpha, IBM Power, SUN Sparc en SGI MIPS, te slopen. Dit is aardig goed gelukt.

[tweaknico]

AXP processor was al eerder bij Intel te grave gedragen.
(Intel maakte die in opdracht van DEC en later HP).

[MSalters]

De DEC Alpha AXP? Productie werd na 1996 door Samsung gedaan (AXP 21164/21264) en IBM (21364). Intel heeft alleen Alpha patenten gekocht. Dat deed AMD overigens ook, AMD gebrukte dezelfde EV6 bus voor de Athlon als DEC voor de AXP.21164.

[tweaknico]

Als gevolg van de rechtzaak over patenten die Intel schond heeft Intel 1 Miljard USD betaald aan DEC (Boete voor patent schending) en heeft vervolgens ook de chips divisie van DEC overgenomen, (Dat was in de uitverkoop tijd van DEC toen de visie van de geldschieter was: verkoop alle delen die geld opbrengen en ruim de rest maar op, met als uitvoerder Palmer),.

Dus Intel heeft toen de gehele AXP portefueille overgenomen, alsmede de StrongARM (de ARM ontworpen door de Alpha designers).
StrongARM liep toen op 200/400 Mhz terwijl de ARM bleef steken op ergens tussen 60 en 100.... evenals Pentium op 66 tot Intel een trucje uit de AXP op de Pentiums ging gebruiken. [ alleen zonder de Patent rechten af te dragen ].
StrongARM is gecanceld omdat Intel liever de eigen architectuur verder wilde ontwikkelen.

[tweaknico]

Naast HP-UX is er ook OpenVMS en NON_Stop beschikbaar voor dit platform.
dat zijn beide zeer betrouwbare en bulletproof omgevingen voor serieuze 99.999 (of beter) beschikbaarheidssystemen.

[nelizmastr]

Ik wist oprecht niet dat Itanium nog bestond. Je komt het zo weinig tegen dat het logisch is dat hierna het einde oefening is. Zonder noemenswaardige software support is een non-commodity architectuur al snel verdoemd.

[tweaknico]

Het is niet zo logisch... Operating systemen als OpenVMS kom je niet dagelijks tegen...
Maar als alle OpenVMS systemen nu accuut zouden stoppen dan staan er heel wat Mission Critical zaken stil... Nog altijd goed voor een paar miljard aan suport en service omzet voor HP).
Juist het feit dat die in de pers niet benoemd worden zegt daar wel wat over.

Vergelijkbaar zijn de NON-Stop systemen.... Heel Nederland is enigszins afhankelijk van een stel van die systemen, ze zitten oa. achter de PIN betalingen, Oh en niet alleen in Nederland..., de bank wereld transactie systemen zijn veelal op deze platforms gebouwd.

Core systemen van Beurzen, zeer grote gezondheids zorg databases. Denk aan de paniek als dat soort systemen het een paar dagen niet zouden doen.. Voor de meeste mensen geldt dan dat er geen geld meer is.
Systemen waarvan je verwacht dat ze Altijd werken, en geen datalekken opleveren.
Het gaat erop lijken dat voor de grote omgevingen alleen IBM nog overblijft.

Aanvulling m.b.t. support....
Al deze systemen maken gebruik van PCI bussen [ die zijn voor dit soort systemen ontwikkeld ] en de opvolgers ervan. En zijn bedoeld voor serieus grote hoeveelheden geheugen.

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

[kdekker]

Dit komt toch nog voor mij als een verrassing. De vorige ronde (9500/Poulson) is heel veel keer uitgesteld, en is meerdere jaren na de oorspronkelijke aankondiging pas gekomen.
HP verkoopt nog zelfs de 9300 serie. Dat is 7 jaar oud, en heel erg lang geleden voor processor begrippen. Zie: https://www.hpe.com/us/en...rity-servers.hits-12.html.

Een beetje Itanium systeem kost je toch wel zo'n 15-25K. Minimaal.

[GingerLionXx]

Het is ook een server processor.

[SilentDecode]

Grapjas? Dit is een server processor en wordt enkel ondersteund onder speciale edities van Windows en van Linux. Dit draait absoluut niet op consumenten hardware of überhaupt iets wat in de buurt komt daarvan..

[MSalters]

Nee, deze processor wordt noch op Windows ondersteund, noch op Linux. VMS en HP-UX zijn de ondersteunde OS'en.

[SilentDecode]

Oh, dan is mijn informatie alweer outdated. Ik dacht dat er van Windows Server 2012R2 een speciale 'IA64' versie beschikbaar was.

[Origin64]

ik had het over meneer sjef met zn veel te duur opmerking?

[SilentDecode]

Dan had je op de reactie moeten reageren van Sjef zelf, en niet die van GingerLionXx...

Dat is waarschijnlijk ook de reden dat je 46x een 'ongewenst' hebt onvangen en nu op '-1' staat. Duidelijkheid is belangrijk.

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

[Origin64]

maar dan ziet "gingerlionxx" niet dat ik het met hem eens ben, en krijgt sjef het gevoel dat hij wordt uitgelachen. je zou ook zelf je hersenen even aan kunnen zetten en bedenken dat ik met grapjas de gast bedoel die iets doms zei

je hoeft mij geen forum manieren uit te leggen hoor. en hoe vaak ik -1 krijg boeit ook niet, het blijft -1

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

[runelaenen]

Dit is uiteraard niet gericht op de gemiddelde consument.

[GingerLionXx]

Voortaan even eerst het hele artikel lezen voordat je conclusies trekt,

[MedionAkoya]

Het kan toch x86 emuleren dus GTA SA moet toch wel lukken?