Microsoft beëindigt support voor Itanium
Microsoft beëindigt de ondersteuning voor Itanium-processors in zijn serversoftware. Dit betekent dat Windows Server 2008 R2, SQL Server 2008 R2 en Visual Studio 2010 de laatste versies met Itanium-ondersteuning zullen zijn.
De aankondiging om Itanium-ondersteuning te schrappen werd gedaan door Dan Reger, technisch productmanager bij de Windows Server-divisie van Microsoft. Na Windows Server 2008 R2, SQL Server 2008 R2 en Visual Studio 2010 zullen geen nieuwe versies van deze software verschijnen met ondersteuning voor de Itanium. Volgens de support lifecycle policy van de softwarereus uit Redmond zal algemene ondersteuning voor Windows Server 2008 op Itanium-systemen eindigen op 9 juli 2013. Vanaf die datum kunnen zakelijke gebruikers nog vijf jaar extended support krijgen, waardoor ze tot 10 juli 2018 veiligheidsupdates en ondersteuning tegen betaling ontvangen.
Het nieuws betekent een tegenslag voor Intel. Begin februari introduceerde de processorfabrikant nog een nieuwe serie Itanium-processors. Eind maart verscheen echter de 7500-serie Xeon-processors, die voorzien zijn van features die voorheen alleen op Itanium-cpu’s te vinden waren. Dan Reger noemt deze evolutie van x64-processoren ook als reden om Microsofts ondersteuning te staken voor de IA-64-instructieset van de Itanium. Eerder kondigde Red Hat al aan dat diens Enterprise Linux 5 de laatste versie zal zijn met Itanium-ondersteuning.
Reacties (63)
De titel suggereert dat de ondersteuning onmiddelijk stopt, terwijl dit niet zo is. 
Het is natuurlijk hoe je het maar leest, maar de titel was veel beter geweest:
"Microsoft beëindigt support voor itanium in 2013"
Het is natuurlijk hoe je het maar leest, maar de titel was veel beter geweest:
"Microsoft beëindigt support voor itanium in 2013"
[Reactie gewijzigd door Relief2009 op 5 april 2010 13:38]
Of tot 2018 in het geval van extended support.
Het is idd maar hoe je het bekijkt, maar ik denk dat de titel wel ok is. Het besluit om support te beindigen gaat namelijk NU in. Dat betekent dat alle software die vanaf NU bij MS ontwikkeld word, niet meer op een Itanium getest zal worden, geen binaries voor gebakken worden en er dus al helemaal niet meer Itanium specifieke dingen (denk aan de HAL en Windows Kernel) ontwikkeld worden.Het is natuurlijk hoe je het maar leest, maar de titel was veel beter geweest:
Het besluit gaat niet nu in, het besluit is nu genomen.
Het gaat ook wel nu in voor producten die nog in ontwikkeling zijn. Er wordt alleen nog support voor al gereleaste producten gegeven tot 2013 (en als je betaald tot 2018).
Wat dacht je van:
"Microsoft kondigt einde aan van support voor Itanium"
Is natuurlijk wel langer maar accurater
"Microsoft kondigt einde aan van support voor Itanium"
Is natuurlijk wel langer maar accurater
Itanium is helaas jammerlijk mislukt. Daarom zullen we voor PC en de meeste servers nog een tijd aan X86 vast zitten met alle uitbreidingen die daarop verzonnen zijn.
Op het moment dat je Xeon ook perfect kunnen schalen, wat had je ook nog aan de Itanium processor? Hij was bedoeld voor enterprise systemen, maar volgens mij heeft er nooit een goede doelstelling bij Intel bestaan voor het uitbrengen van Itanium-processoren.
Deze markt was al ruimbezet door Xeon-processoren en de meeste marktaandeel die Itanium zou winnen, zou afgepakt worden van de Xeon-processor (kannibalisme).
De performance is ook nooit indrukwekkend geweest, waardoor Itanium een grote reputatie heeft kunnen opbouwen. Ze waren wel de eerste Intel-processoren met 64-bits ondersteuning (in 2001).
Deze markt was al ruimbezet door Xeon-processoren en de meeste marktaandeel die Itanium zou winnen, zou afgepakt worden van de Xeon-processor (kannibalisme).
De performance is ook nooit indrukwekkend geweest, waardoor Itanium een grote reputatie heeft kunnen opbouwen. Ze waren wel de eerste Intel-processoren met 64-bits ondersteuning (in 2001).
Zie ook het comment van Only.Holoris. De Itanium was een totaal legacy vrij platform. X86 zit nog vol met legacy uit de jaren 90 en 80. De performance is nooit indrukwekkend geweest omdat er lang niet zoveel geld is in geïnvesteerd als in x86.
Ik betwijfel of we nog lang aan x86 vast blijven zitten. 64 bit krijgt steeds wijdere support, en ondersteunt uiteraard ook nog meer dan 4096MB aan RAM, iets waar servers met meerdere virtuele systemen natuurlijk van smullen, en waar consumenten PC fabrikanten (Dell, Medion, Acer) natuurlijk ook het voordeel van inzien. (Meer RAM = extra selling point, meer aantrekkingskracht gebruikers) Het duurt nog wel enkele jaren, maar ik verwacht dat we binnen aanzienlijke tijd overgestapt zijn of x64.
x64 zoals we het nu kennen is gewoon x86 met 64 bits extensies.. Voorzover ik weet heeft zelfs de nieuwste '64' bits processor nog de mogelijkheid om 16 bits code uit te voeren. Real mode uit de 80286....
Zoals je in het laatste puntje van http://en.wikipedia.org/wiki/X86-64#Architectural_features kunt zien, zijn enkele features (waaronder de door jou genoemde real mode) verwijdert uit long-mode. Nu kan de processor ook in legacy-mode draaien, waarbij dit wel mogelijk is (oa voor 32-bit besturings systemen). Op de lange termijn kan deze legacy mode verdwijnen, waarna deze features dus echt niet meer mogelijk zijn.
Zolang de BIOS'en nog in assembler geschreven worden en directe afstammelingen blijven van de eerste IBM PC BIOS-clones gaat de 16-bit mode niet verdwijnen. Zelfs de Phoenix BIOS'en zijn nog 16 en 32 bit code door elkaar. Oude stuff is 16bit, nieuwe stuff als ACPI en USB support zijn 32bit. Ook x86-64 CPU's zullen dus een 16bit mode moeten hebben en houden.
De enige BIOS die bijna volledig 32bit is is overigens Coreboot, een open source project. Vrijwel aan het begin gaat de CPU in 32bit mode en komt er niet meer uit.
De enige BIOS die bijna volledig 32bit is is overigens Coreboot, een open source project. Vrijwel aan het begin gaat de CPU in 32bit mode en komt er niet meer uit.
BIOS is al ff voorbijgestreefd door EFI, maar daarvoor moet gewoon nog meer support komen. apple was de pionier en Dell heeft het als een van de eerste grote fabrikanten al een paar jaar op haar toestellen staan
Hoe EFI geïmplementeerd is staat los van de specificatie. EFI kun je heel goed als een soort "applicatie" vastplakken aan je bestaande hardware initialisatie programma (BIOS). EFI is op die manier dus niet echt iets "nieuws", meer een uitbreiding. Het vervangt zo doende bijvoorbeeld het oude boot proces en USB support, de oude hardware initialisatie blijft gewoon bestaan.
De uitvinding van EFI betekend dus niet perse dat we van die vervelende 16bit legacy af zijn.
De uitvinding van EFI betekend dus niet perse dat we van die vervelende 16bit legacy af zijn.
niet per se, maar het bied wel de interface om dit TOCH voor elkaar te krijgen.
efi heeft zo z'n voordelen - de modulaire opzet ervan is EEN van de voordelen die in dit verhaal dan duidelijk naar voren komt..
efi heeft zo z'n voordelen - de modulaire opzet ervan is EEN van de voordelen die in dit verhaal dan duidelijk naar voren komt..
Ik geloof dat EFI juist van Intel stamt. Toevallig juist omwille van Itanium: Intel wilde de servermarkt betreden, die gedomineerd werd (en nog steeds wordt) door IBM met zijn Power-processors. BIOS gebruiken op dergelijke systemen zou daardoor heel dom zijn, gezien IBM daar nog altijd patenten op heeft.
Dit maakt dat Itanium-systemen (IA-64) altijd EFI gebruiken. Inderdaad is Apple wel bekender als EFI-gebruiker, gezien je Macs nu eenmaal meer tegenkomt, maar dus niet echt *de* pionier. (Wel gebruikt iedereen zijn eigen versie van EFI, er is wel een "Unified EFI", maar die is nog niet zo veel te vinden, hoewel 64-bits windows hem al wel ondersteund.)
Dit maakt dat Itanium-systemen (IA-64) altijd EFI gebruiken. Inderdaad is Apple wel bekender als EFI-gebruiker, gezien je Macs nu eenmaal meer tegenkomt, maar dus niet echt *de* pionier. (Wel gebruikt iedereen zijn eigen versie van EFI, er is wel een "Unified EFI", maar die is nog niet zo veel te vinden, hoewel 64-bits windows hem al wel ondersteund.)
[Reactie gewijzigd door Typhoner op 5 april 2010 19:04]
Ik denk dat het aantal bits of de hoeveelheid adresseerbaar geheugen nog de minste reden is waarom x86 langzaam maar zeker minder bepalend zal gaan worden. De belangrijkste reden dat x86 nog steeds erg populair is, is volgens mij de consumenten-desktop: omdat Windows als dominante OS voor desktops en workstations eigenlijk altijd x86 (of iets compatibels zoals x86-64) is geweest, is er ook altijd een grote behoefte geweest aan systemen die alle oudere software standaard draaien. Dit is langzaam aan het veranderen nu er steeds meer devices verschijnen die naast de PC gebruikt worden, en een eigen OS een architectuur gebruiken (telefoons, MID's, tablets, cloud applicaties). Het aantal kritische toepassingen dat alleen op x86 draait zal langzaam maar zeker teruglopen, totdat er een ondergrens bereikt wordt waarop het voor veel mensen niet zo boeiend meer is of ze hun oude programma's nog kunnen gebruiken. Je ziet het eigenlijk in heel veel toepassingen terug die voorheen echte PC toepassingen waren maar nu steeds meer naar devices met 'alternatieve' platformen verplaatsen: consoles voor games, MID's voor internet toepassingen, handhelds voor games, tablets voor media consumptie, enzovoorts.Ik betwijfel of we nog lang aan x86 vast blijven zitten. 64 bit krijgt steeds wijdere support, en ondersteunt uiteraard ook nog meer dan 4096MB aan RAM [...]
Natuurlijk is het voor bedrijven een stuk minder makkelijk om legacy systemen te vervangen door iets anders, maar het is nu toch al zo dat de meest kritische bedrijfsprocessen van de meeste bedrijven toch al niet op x86 of windows draaien (of: hoeven te draaien). Architecturen als PowerPC, Itanium, Sparc, etc, en OS-en als AIX, Linux, Solaris, het wordt allemaal op veel grotere schaal gebruikt in het bedrijfsleven dan door consumenten, wat al aangeeft dat voor die toepassingen de ondersteuning van x86 eigenlijk niet zo heel interessant is. De typische MS Office farms die nu nog zo'n groot gedeelte van de markt voor kantoorapplicaties bepalen zullen ook niet altijd in deze vorm blijven bestaan, nu de trend toch lijkt te zijn om dat soort dingen gecentraliseerd te doen (cloud computing en thin clients).
64 bit is nog steeds x86...
Maar ik zou graag wat meer ARM zien in de grote wereld, voorzover ik weet draait daar echter alleen ubuntu op (en de os'en van de mobieltjes e.d.).
Maar ik zou graag wat meer ARM zien in de grote wereld, voorzover ik weet draait daar echter alleen ubuntu op (en de os'en van de mobieltjes e.d.).
Klopt!
Kan je zien aan de registernamen.
je kan een 64 bits cpu gewoon nog als een 8088 programeren.
Dan is ie wel heel snel
8bits: mov ah,0x10 of het lage gedeelte: mov al,0x10
16 bits: mov ax,0xffff
32 bits: mov eax,0xf000000f
64bits: mov rax,0x0
http://www.nasm.us/doc/nasmdo11.html
Kan je zien aan de registernamen.
je kan een 64 bits cpu gewoon nog als een 8088 programeren.
Dan is ie wel heel snel
8bits: mov ah,0x10 of het lage gedeelte: mov al,0x10
16 bits: mov ax,0xffff
32 bits: mov eax,0xf000000f
64bits: mov rax,0x0
http://www.nasm.us/doc/nasmdo11.html
Zou het in de OpCodes van de machinetaal zelf ook nog terug te herkennen zijn? Of is dat totaal omgegooid in x64 ?
[Reactie gewijzigd door hvdrhee op 6 april 2010 10:34]
Sinds wanneer is Ubuntu synoniem voor non-windows?
Op ARM CPUs draait elke willekeurige linux distributie met ARM support, Ubuntu en Debian zijn daar slechts 2 voorbeelden van. Verder heb je nog de diverse BSDs. FreeBSD, NetBSD en OpenBSD hebben alle 3 een ARM port.
Ik heb hier thuis een 1.2GHz ARM computer met Debian draaien als router. Zou voor geen goud dat ding willen inruilen voor een Atom.
Op ARM CPUs draait elke willekeurige linux distributie met ARM support, Ubuntu en Debian zijn daar slechts 2 voorbeelden van. Verder heb je nog de diverse BSDs. FreeBSD, NetBSD en OpenBSD hebben alle 3 een ARM port.
Ik heb hier thuis een 1.2GHz ARM computer met Debian draaien als router. Zou voor geen goud dat ding willen inruilen voor een Atom.
Debian, daar is Ubuntu op gebaseerd.
Waarschuwing / disclaimer: dit kan misschien nogal als een rant overkomen. Ik ben inderdaad geen grote fan van x86 en vooral niet van de enorme legacy die het met zich meesleept.
De Itanium is indertijd zo ongeveer vanaf nul opnieuw ontworpen. Weliswaar nog met een paar kleine aanpassingen om x86 niet-al-te-inefficiënt te kunnen emuleren, maar veel ontwerpkeuzes (waaronder, als ik het goed begrepen heb, (nagenoeg?) alle belangrijke) konden opnieuw gemaakt worden: zónder de molensteen van ongelukkige (of ronduit slechte) keuzes uit het verleden, maar mét twintig jaar meer onderzoek en ervaring. Dat betekende inderdaad wel dat, onder andere, compilers een grondige rewrite nodig hadden, inclusief een boel nieuwe research, om optimaal gebruik te kunnen maken van Itanium.
De enige "uitweg" die ik zie is als Intel en AMD samen de instructieset voor de eerste 128 bit processoren ontwikkelingen. Niet heel erg realistisch (en ik heb geen idee of er niet ergens een wetje rondzwerft dat het zou verbieden), maar wat we nodig hebben is
Het mooiste zou natuurlijk zijn als je bij het ontwerpen van je 128 bit instructieset totaal geen rekening hoeft te houden met legacy support; bijvoorbeeld door een "legacy co-processor" toe te voegen (on-die, on-board of desnoods op een pci-e kaartje met dedicated geheugen e.d.).
Maar linksom of rechtsom, we moeten echt een keer af van x86. Als je me niet gelooft, bekijk dan maar eens hoe een i7 / Phenom intern werkt.
Het eerste wat ie doet is twee of drie (sorry, weet het precieze getal niet uit mijn hoofd) clock cycles besteden aan het decoderen van de instructies. De eerste stap heet zelfs predecode, die weinig anders doet dan vaststellen hoe lang instructies zijn / waar de volgende instructie begint. Een RISC architectuur kan dat in één cycle. Niet zo verwonderlijk, want een RISC hoeft minder vertaalwerk te doen (de vertaling is, in beide gevallen, naar een RISC-achtige interne instructieset) en de instructielengtes zijn constant (of in elk geval zijn er veel minder mogelijkheden).
En vergelijk de hoeveelheid die-oppervlak die de out-of-order machinerie nodig heeft met de oppervlakte van de ALUs en FPUs en dergelijke. Die laatste zijn erg klein, het hele ooo-gebeuren neemt veel ruimte in maar voert netto geen berekeningen uit; het houdt alleen de execution units zo goed mogelijk bezig. Want tja, in de eerste versie van x86 werd gewoon nog één instructie per keer verwerkt en die code moet i7 / Phenom ook kunnen verwerken. De Itanium instructieset breekt compatibiliteit met x86 (al kunnen Itanium processoren, via wat ingebakken truken, wel x86 draaien) en heeft dus geen legacy code. Als toch alles opnieuw gecompiled moet worden, dan kun je dus ook extra eisen stellen. Bijvoorbeeld de compiler laten uitvogelen welke instructies tegelijk verwerkt kunnen worden en welke van elkaar afhankelijk zijn. De compiler hoeft het maar één keer te doen en heeft geen realtime beperkingen. Als je het de CPU laat doen moet het elke keer gebeuren dat de code wordt utigevoerd. Als je loop te groot is voor de caches, dan moet dus elke iteratie opnieuw worden uitgevogeld welke instructies dependencies op elkaar hebben. Hoezo dubbel werk?
Iets langere post dan ik oorpronkelijk in gedacht had....
Ik zou willen dat ik je enthousiasme kon delen... In werkelijkheid was het nou juist Itanium die ons van x86 (en 30(!!) jaar legacy) had moeten gaan verlossen. Ergens ben ik blij dat AMD's aanpak (x86 -> x86-64) geslaagd is; als Itanium echt was doorgebroken dan hadden we nu waarschijnlijk met een 100% monopolie van Intel op de "CPU voor desktops en servers"-markt gezeten. Van de andere kant, nu zitten we nog steeds opgescheept met een bouwval-instructieset. Tja, dat krijg je als je geen geweldige fundamenten legt en er elke keer weer een uitbouwtje aan vast maakt of verdiepinkje oplegt.Ik betwijfel of we nog lang aan x86 vast blijven zitten.
De Itanium is indertijd zo ongeveer vanaf nul opnieuw ontworpen. Weliswaar nog met een paar kleine aanpassingen om x86 niet-al-te-inefficiënt te kunnen emuleren, maar veel ontwerpkeuzes (waaronder, als ik het goed begrepen heb, (nagenoeg?) alle belangrijke) konden opnieuw gemaakt worden: zónder de molensteen van ongelukkige (of ronduit slechte) keuzes uit het verleden, maar mét twintig jaar meer onderzoek en ervaring. Dat betekende inderdaad wel dat, onder andere, compilers een grondige rewrite nodig hadden, inclusief een boel nieuwe research, om optimaal gebruik te kunnen maken van Itanium.
De enige "uitweg" die ik zie is als Intel en AMD samen de instructieset voor de eerste 128 bit processoren ontwikkelingen. Niet heel erg realistisch (en ik heb geen idee of er niet ergens een wetje rondzwerft dat het zou verbieden), maar wat we nodig hebben is
- géén "x86-128", die mag niet bestaan, anders kiest iedereen toch daarvoor
- één instructieset die door alle grote fabrikanten (op dit moment zouden dat dus Intel en AMD zijn) ondersteund worden
- géén patenten die bij een fabrikant liggen
- een manier om legacy, x86 en x86-64, te ondersteunen
Het mooiste zou natuurlijk zijn als je bij het ontwerpen van je 128 bit instructieset totaal geen rekening hoeft te houden met legacy support; bijvoorbeeld door een "legacy co-processor" toe te voegen (on-die, on-board of desnoods op een pci-e kaartje met dedicated geheugen e.d.).
Maar linksom of rechtsom, we moeten echt een keer af van x86. Als je me niet gelooft, bekijk dan maar eens hoe een i7 / Phenom intern werkt.
Het eerste wat ie doet is twee of drie (sorry, weet het precieze getal niet uit mijn hoofd) clock cycles besteden aan het decoderen van de instructies. De eerste stap heet zelfs predecode, die weinig anders doet dan vaststellen hoe lang instructies zijn / waar de volgende instructie begint. Een RISC architectuur kan dat in één cycle. Niet zo verwonderlijk, want een RISC hoeft minder vertaalwerk te doen (de vertaling is, in beide gevallen, naar een RISC-achtige interne instructieset) en de instructielengtes zijn constant (of in elk geval zijn er veel minder mogelijkheden).
En vergelijk de hoeveelheid die-oppervlak die de out-of-order machinerie nodig heeft met de oppervlakte van de ALUs en FPUs en dergelijke. Die laatste zijn erg klein, het hele ooo-gebeuren neemt veel ruimte in maar voert netto geen berekeningen uit; het houdt alleen de execution units zo goed mogelijk bezig. Want tja, in de eerste versie van x86 werd gewoon nog één instructie per keer verwerkt en die code moet i7 / Phenom ook kunnen verwerken. De Itanium instructieset breekt compatibiliteit met x86 (al kunnen Itanium processoren, via wat ingebakken truken, wel x86 draaien) en heeft dus geen legacy code. Als toch alles opnieuw gecompiled moet worden, dan kun je dus ook extra eisen stellen. Bijvoorbeeld de compiler laten uitvogelen welke instructies tegelijk verwerkt kunnen worden en welke van elkaar afhankelijk zijn. De compiler hoeft het maar één keer te doen en heeft geen realtime beperkingen. Als je het de CPU laat doen moet het elke keer gebeuren dat de code wordt utigevoerd. Als je loop te groot is voor de caches, dan moet dus elke iteratie opnieuw worden uitgevogeld welke instructies dependencies op elkaar hebben. Hoezo dubbel werk?
Iets langere post dan ik oorpronkelijk in gedacht had....
Rant inderdaad, want niet relevant. Laat ik je punten 1 voor 1 aanpakken:
"128 bits systemen" gaan er vrijwel zeker niet komen. Computers gaan simpelweg niet meer dan 2^64 bytes aan geheugen krijgen; de hoeveelheid atomen die daarvoor nodig zijn is onvoorstelbaar. Gok eens hoeveel kilo dat zou wegen? Een DVD filmpje van een uur is zo'n 4 GB => 32 bits, maar hoeveel bytes denk je dat je ogen uberhaupt in 1 leven kunnen zien?
Een 128 bits CPU ISA die niet op patenten gebaseerd is? Dat is zelfs de x86 ISA niet (de Intel en AMD implementaties van x86 zijn dat wel, maar de Bochs emulator weer niet).
Je idee van een "legacy co-procesor" is onzinnig. Waarom zou een aparte chip goed zijn, terwijl een "legacy mode" van een CPU dat juist niet is? Die legacy co-processor is een separate component en daarmee behoorlijk duur, terwijl de kosten van een legacy mode in centen worden uitgedrukt. Kortom, als AMD die legacy co-processor op jouw hypothetische CPU die integreert, dan hebben ze een economisch voordeel en zal Dell daarvoor kiezen.
De i7 besteedt 0 klokcycles aan de predecode. Dat zit namelijk in de pipeline. Die predecode gebeurt dus tegelijkertijd met de uitvoering van een instructie en de decode van een andere instructie.
Een RISC heeft inderdaad een vaste lengte van instructies. Het gevolg daarvan zie je goed bij ARM, een klassiek RISC ontwerp: dan eindig je met hacks als Thumb mode en Thumb2 mode. Dat is net zo erg als de verschillende x86 modes, en dan heb je bij ARM nog steeds geen 64 bits mode. Bovendien is de instruction density in de cache op RISC daardoor slechter.
OoO execution staat los van de x86 ISA: snelle processoren zoals de IBM Power en de Core i7s hebben het, maar de Atom heeft het niet. En ja, het is niet geweldig handig om de instructie dependencies elke keer opnieuw te laten bepalen, maar het is wel handig dat de CPU ze zelf kent. Zou de compiler dat gedaan hebben, dan zou je Core i7 code niet compatible zijn met de Phenom - Die hebben namelijk verschillende instruction dependencies. Instruction dependencies zijn namelijk expliciet geen onderdeel van de x86 ISA, maar wel van de Itanium ISA.
"128 bits systemen" gaan er vrijwel zeker niet komen. Computers gaan simpelweg niet meer dan 2^64 bytes aan geheugen krijgen; de hoeveelheid atomen die daarvoor nodig zijn is onvoorstelbaar. Gok eens hoeveel kilo dat zou wegen? Een DVD filmpje van een uur is zo'n 4 GB => 32 bits, maar hoeveel bytes denk je dat je ogen uberhaupt in 1 leven kunnen zien?
Een 128 bits CPU ISA die niet op patenten gebaseerd is? Dat is zelfs de x86 ISA niet (de Intel en AMD implementaties van x86 zijn dat wel, maar de Bochs emulator weer niet).
Je idee van een "legacy co-procesor" is onzinnig. Waarom zou een aparte chip goed zijn, terwijl een "legacy mode" van een CPU dat juist niet is? Die legacy co-processor is een separate component en daarmee behoorlijk duur, terwijl de kosten van een legacy mode in centen worden uitgedrukt. Kortom, als AMD die legacy co-processor op jouw hypothetische CPU die integreert, dan hebben ze een economisch voordeel en zal Dell daarvoor kiezen.
De i7 besteedt 0 klokcycles aan de predecode. Dat zit namelijk in de pipeline. Die predecode gebeurt dus tegelijkertijd met de uitvoering van een instructie en de decode van een andere instructie.
Een RISC heeft inderdaad een vaste lengte van instructies. Het gevolg daarvan zie je goed bij ARM, een klassiek RISC ontwerp: dan eindig je met hacks als Thumb mode en Thumb2 mode. Dat is net zo erg als de verschillende x86 modes, en dan heb je bij ARM nog steeds geen 64 bits mode. Bovendien is de instruction density in de cache op RISC daardoor slechter.
OoO execution staat los van de x86 ISA: snelle processoren zoals de IBM Power en de Core i7s hebben het, maar de Atom heeft het niet. En ja, het is niet geweldig handig om de instructie dependencies elke keer opnieuw te laten bepalen, maar het is wel handig dat de CPU ze zelf kent. Zou de compiler dat gedaan hebben, dan zou je Core i7 code niet compatible zijn met de Phenom - Die hebben namelijk verschillende instruction dependencies. Instruction dependencies zijn namelijk expliciet geen onderdeel van de x86 ISA, maar wel van de Itanium ISA.
Goed idee, hier een punt-voor-punt reactie:
Maar als je mij niet gelooft, misschien heb je dan wel vertrouwen in de toekomstvoorspellingen van Microsoft: 'Windows 8 krijgt 128bit-kernel'.
Lees hier even wat er staat bij 1982 en 1994.
Wat betreft je uitspraak dat de i7 deze niet heeft, Intel zelf beweert (op pagina 50 van haar Intel® 64 and IA-32 Architectures Optimization Reference Manual van wel, dus dat geloof ik dan gewoon.
Of de ARM een 64 bits mode heeft is toch totaal niet relevant.
Volgens mij hebben we het over iets anders; ik bedoel de dependencies van de instructies. Bijvoorbeeld mov eax, "waarde" \\ add ebx, eax kun je beter niet parallel uitvoeren. Maakt geen bal uit hoe je processor intern werkt, dat gaat fout. Wat jij bedoelt is, denk ik, de dependencies van de functional units. Dat is inderdaad, met het oog op zowel forward als backward compatibilty handiger om aan de processor zelf over te laten. Bijvoorbeeld, add eax, ebx \\ add ecx, adx kun je prima tegelijk utivoeren, mits je twee adders hebt. Lees anders even dit artikel, met name hoe Itanium omgaat met een "instruction group" (niet bundles, groups). Dat is wat je niet, at runtime, wilt laten uitvogelen door de processor, dat is een taak die prima geschikt is voor de compiler.
Meer dan 2^64 bits kunnen adresseren is niet de enige reden om van 64 naar 128 bits processoren over te willen stappen. Je SIMD instructies worden (in het ideale geval) twee keer zo efficiënt als je registers twee keer zo groot worden."128 bits systemen" gaan er vrijwel zeker niet komen. Computers gaan simpelweg niet meer dan 2^64 bytes aan geheugen krijgen (..)
Maar als je mij niet gelooft, misschien heb je dan wel vertrouwen in de toekomstvoorspellingen van Microsoft: 'Windows 8 krijgt 128bit-kernel'.
Toegegeven, ik heb geen idee hoe de juristen het precies geregeld hebben. Het enige wat ik wel weet is dat ik (zelfs al had ik een paar miljard euro over om mee te spelen) niet hoef te proberen een derde CPU-fabrikant op poten te zetten; die zou namelijk (in elk geval niet zonder Crusoe-kunstgrepen, met die truken weet ik niet hoe het zit) een x86 / x86-64 CPU mogen maken.Een 128 bits CPU ISA die niet op patenten gebaseerd is? Dat is zelfs de x86 ISA niet (de Intel en AMD implementaties van x86 zijn dat wel, maar de Bochs emulator weer niet).
Lees hier even wat er staat bij 1982 en 1994.
Omdat je een discreet element later (als de processoren krachtig genoeg zijn om emulatie in software te doen) makkelijk weg kunt laten. Overigens hoeft het van mij niet persé een aparte chip te zijn (wat vroeger begon als FPU (floating point co-processor) is ook al tijden geïntegreerd in de CPU zelf, iets soortgelijks is nu aan de gang met de GPU), ik noemde alleen verschillende mogelijkheden. Ik heb niet genoeg verstand van zaken en ervaring om daaruit de beste te kiezen.Je idee van een "legacy co-procesor" is onzinnig. Waarom zou een aparte chip goed zijn, terwijl een "legacy mode" van een CPU dat juist niet is?
Tuurlijk zit het in de pipeline, waar zou het anders moeten zitten? Het is een extra cycle die wordt weggegooid elke keer dat de pipeline gereset moet worden (in elk geval bij elke mispredicted branch en mogelijk (weet de details niet uit mijn hoofd) bij serializing instructions).De i7 besteedt 0 klokcycles aan de predecode. Dat zit namelijk in de pipeline.
Wat betreft je uitspraak dat de i7 deze niet heeft, Intel zelf beweert (op pagina 50 van haar Intel® 64 and IA-32 Architectures Optimization Reference Manual van wel, dus dat geloof ik dan gewoon.
Want x86 CPUs zitten niet vol hacks...Een RISC heeft inderdaad een vaste lengte van instructies. Het gevolg daarvan zie je goed bij ARM, een klassiek RISC ontwerp: dan eindig je met hacks als Thumb mode en Thumb2 mode. Dat is net zo erg als de verschillende x86 modes, en dan heb je bij ARM nog steeds geen 64 bits mode. Bovendien is de instruction density in de cache op RISC daardoor slechter.
Of de ARM een 64 bits mode heeft is toch totaal niet relevant.
Ja, je kunt zowel out-of-order als in-order implementaties maken van dezelfde ISA. Maar het lijkt mij dat elke nieuwe generatie dit zal blijven ondersteunen in de high-end modellen.OoO execution staat los van de x86 ISA: snelle processoren zoals de IBM Power en de Core i7s hebben het, maar de Atom heeft het niet. En ja, het is niet geweldig handig om de instructie dependencies elke keer opnieuw te laten bepalen, maar het is wel handig dat de CPU ze zelf kent. Zou de compiler dat gedaan hebben, dan zou je Core i7 code niet compatible zijn met de Phenom - Die hebben namelijk verschillende instruction dependencies.
Volgens mij hebben we het over iets anders; ik bedoel de dependencies van de instructies. Bijvoorbeeld mov eax, "waarde" \\ add ebx, eax kun je beter niet parallel uitvoeren. Maakt geen bal uit hoe je processor intern werkt, dat gaat fout. Wat jij bedoelt is, denk ik, de dependencies van de functional units. Dat is inderdaad, met het oog op zowel forward als backward compatibilty handiger om aan de processor zelf over te laten. Bijvoorbeeld, add eax, ebx \\ add ecx, adx kun je prima tegelijk utivoeren, mits je twee adders hebt. Lees anders even dit artikel, met name hoe Itanium omgaat met een "instruction group" (niet bundles, groups). Dat is wat je niet, at runtime, wilt laten uitvogelen door de processor, dat is een taak die prima geschikt is voor de compiler.
Ik zeg ook niet dat ze onderdeel van de x86 ISA zijn, ik zeg (of in elk geval, dat probeerde ik, sorry als het onduidelijk was) dat het onderdeel van een moderne, toekomst-bestendige ISA (zoals mijn hypothetische 128 bit ISA) hoort te zijn.Instruction dependencies zijn namelijk expliciet geen onderdeel van de x86 ISA, maar wel van de Itanium ISA.
Ook op een x86 kun je meer dan 4GB aan RAM gebruiken. Alleen kan 1 applicatie hooguit 3,5GB in 1 keer gebruiken.
"Jammerlijk mislukt" vind ik wel erg kort door de bocht.
De Itanium is neergezet als een niche-processor voor bepaalde hele specifieke toepassingen, niet voor mainstream server-gebruik. De productie- en verkoop-aantallen van de Itaniums worden uitgedrukt in tienduizenden of honderdduizenden, tegenover miljoenen voor Xeon's.
De Itanium is voor high-performance computing in rekencentra, dat is een markt waar Windows sowieso weinig te zoeken heeft.
edit: @wildhagen: ik weet dat er speciale hpc-versies van Windows Server zijn, maar ik had nou niet echt de indruk dat MS daarmee nou echt veel terrein heeft gewonnen.
De Itanium is neergezet als een niche-processor voor bepaalde hele specifieke toepassingen, niet voor mainstream server-gebruik. De productie- en verkoop-aantallen van de Itaniums worden uitgedrukt in tienduizenden of honderdduizenden, tegenover miljoenen voor Xeon's.
De Itanium is voor high-performance computing in rekencentra, dat is een markt waar Windows sowieso weinig te zoeken heeft.
edit: @wildhagen: ik weet dat er speciale hpc-versies van Windows Server zijn, maar ik had nou niet echt de indruk dat MS daarmee nou echt veel terrein heeft gewonnen.
[Reactie gewijzigd door RefriedNoodle op 5 april 2010 14:10]
Onjuist, Van Windows Server 2008 is ook een supercomputer-versie uitgekomen, namelijk Wndows HPC Server 2008.De Itanium is voor high-performance computing in rekencentra, dat is een markt waar Windows sowieso weinig te zoeken heeft.
Maar verder ben ik het wel met je eens, de Itanium is altijd voor een niche markt bedoeld geweest, en had daar afaik ook een redelijk aandeel in. Een mislukking zou ik de Itanium dan ook niet willen noemen.
Hoezo is dat nou weer onjuist? Het feit dat Microsoft een HPC versie uitbrengt wil nog niet zeggen dat deze versie dermate goed is dat het tegen de gevestigde orde op kan boksen. Dat kan het dan ook niet juist vanwege die gevestigde orde. Dat hele wereldje is zo ontzettend UNIX gericht dat je hemel en aarde moet gaan bewegen om het naar Windows te porten. Dat maakt iets als Windows nou niet bepaald populair en veel gebruikt. Vanuit die optiek heeft Windows inderdaad weinig te zoeken in dat wereldje. Het heeft dus niets te maken met het kunnen van Windows HPC (het wordt zeker wel gebruikt) of het feit dat er geen HPC versie zou zijn (eigenlijk had men al zoiets sinds Windows 2000 Datacentre Server).
Als je verder bekijkt wat Itanium had moeten worden dan is het inderdaad jammerlijk mislukt. Dat x86 heeft flink de overhand genomen net als diverse andere architecturen als PowerPC. Zo revolutionair als dat de voorloper (de Alpha) was, is het niet geworden. Ik weet nog wel dat veel mensen het niet bepaald tof vonden dat HP heel dat Alpha verhaal liet vallen en toen met de Itanium is begonnen. Destijds waren er al geluiden dat het op een mislukking uit zou komen. Die mensen zullen nu ongetwijfeld gaan roepen "zie je nou wel?!". Die niche-markt is iets waar men zich later op is gaan richten toen het allemaal niet zo liep als men dacht. De plannen waren grootser dan de realiteit ze toe liet.
Als je verder bekijkt wat Itanium had moeten worden dan is het inderdaad jammerlijk mislukt. Dat x86 heeft flink de overhand genomen net als diverse andere architecturen als PowerPC. Zo revolutionair als dat de voorloper (de Alpha) was, is het niet geworden. Ik weet nog wel dat veel mensen het niet bepaald tof vonden dat HP heel dat Alpha verhaal liet vallen en toen met de Itanium is begonnen. Destijds waren er al geluiden dat het op een mislukking uit zou komen. Die mensen zullen nu ongetwijfeld gaan roepen "zie je nou wel?!". Die niche-markt is iets waar men zich later op is gaan richten toen het allemaal niet zo liep als men dacht. De plannen waren grootser dan de realiteit ze toe liet.
En die website verklapt ook direct waarom Windows HPC Server nooit gaat aanslaan: Recommended retail pricing for Windows HPC Server 2008 on Open License program is $475 USD per node. En voor een scheduler etc. erbij te krijgen moet je nog eens neertellen (Microsoft HPC Pack - retail $135).
Voor die prijs krijg je tegenwoordig een halve/volledige node erbij in de meeste HPC clusters. Dus voor de kost van licenties kan ik 50-100% meer CPU krijgen. Zelfs al zou een Linux-variant 25% minder performeren (terwijl het eigenlijk stukken beter doet) of 25% meer kosten om te implementeren dan nog komen de kosten eruit.
Voor die prijs krijg je tegenwoordig een halve/volledige node erbij in de meeste HPC clusters. Dus voor de kost van licenties kan ik 50-100% meer CPU krijgen. Zelfs al zou een Linux-variant 25% minder performeren (terwijl het eigenlijk stukken beter doet) of 25% meer kosten om te implementeren dan nog komen de kosten eruit.
Intel wilde wel degelijk op termijn de grote markt veroveren met de Itanium als hun 64 bits variant. Dat is nu niet meer zo en ze hebben nu inderdaad een niche rol voor de Itanium op dit moment.
Windows icm Microsoft SQL server heeft wel degelijk iets te zoeken in high-performance computing. Er zijn Nederlandse telco's die op dergelijke platformen billing afhandelen, goedkoper dan ze dat voorheen met Oracle deden...
Windows icm Microsoft SQL server heeft wel degelijk iets te zoeken in high-performance computing. Er zijn Nederlandse telco's die op dergelijke platformen billing afhandelen, goedkoper dan ze dat voorheen met Oracle deden...
Ooit, lang geleden, toen Intel net Itanium introduceerde werd er serieus rekening gehouden met de optie dat Itanium via de markt van Servers en Workstations mainstream zou worden. Itanium bedient nu een niche markt, maar had het potentieel om x86 te vervangen. Rond de tijd dat Intel de Itanium profileerde als mogelijke desktop processor in de toekomst kwam AMD met de x64 instructieset. Het succes daarvan was een belangrijke reden voor het mislukken van Itanium.De Itanium is neergezet als een niche-processor voor bepaalde hele specifieke toepassingen
Om een idee te krijgen van wat zowel Intel als Microsoft van de Itanium verwachtten moet je bedenken dat er een Windows XP Pro versie was voor Itanium. Dat is zeker geen besturingssysteem dat past bij een niche markt.
Voor mij is Itanium dus inderdaad jammerlijk mislukt.
Zie bijvoorbeeld: reviews: Intel Itanium sneak preview
Dit kan ik me inderdaad nog heel goed herinneren. Het is beangstigend hoe slecht het geheugen van de meerderheid van de Tweakers is. Bij nagenoeg elk news item over Itanium komt het fabeltje dat de Itanium puur als een niche product is ontworpen weer om de hoek kijken, maar het is gewoon niet waar.Ooit, lang geleden, toen Intel net Itanium introduceerde werd er serieus rekening gehouden met de optie dat Itanium via de markt van Servers en Workstations mainstream zou worden.
Itanium zou op termijn voor de hele range aan processor markten mainstream moeten gaan worden, waarbij de 'gewone' servers en absoluut de desktops op het programma stonden.
In theorie zou het ook beter moeten werken om helemaal schoon met een nieuw ontwerp te beginnen, maar in de praktijk pakt dit zeker niet altijd goed uit. Zoals blijkt kan het wel degelijk beter werken om een bestaand product stap voor stap te verbeteren. De huidige x86 processors zijn dan ook zo sterk verbeterd dat intern de hele legacy een veel minder grote rol speelt dan misschien wordt gedacht. De x86 instructie set is bijna alleen aan soort API (ABI) bovenop de eigenlijke core van de CPU.
Het is zeker niet zo dat de Itanium voornamelijk heeft verloren vanwege externe issues zoals dat de meeste Windows software binary x86 is. Wij draaien volledig op Java onder Linux en zijn altijd op zoek naar de hoogst mogelijk performance voor onze servers. Windows software speelt dus 0.0% een rol en het budget is toerijkend voor Itanium servers. Maar keer op keer bleek dat voor onze workload x86 servers betere performance bieden! Dan gaan we natuurlijk geen Itaniums kopen...
Pixar Render Farm gebruik een HPC Cluster van MS?
Ze zijn 23ste geranked van de top 500 super computers....
Lijkt mij dat ze dan redelijk scoren
Ze zijn 23ste geranked van de top 500 super computers....
Lijkt mij dat ze dan redelijk scoren
Helaas heeft HP na de overname van Compaq de Alpha de nek omgedraaid, vanwege de Itanium. Maar de Alpha was heer en meester in die dagen qua performance.
Tja dat had Intel kunnen weten op het moment dat itanium geen extra features meer heeft tov x86 dan wordt ontwikkelen ervoor minder de moeite..
Maar de meeste itanium servers draaien toch een enterprise unix ofzo?
op het moment dat itanium geen extra features meer heeft tov x86 dan wordt ontwikkelen ervoor minder de moeite..Maar de meeste itanium servers draaien toch een enterprise unix ofzo?
Onder andere. Ik ben systeembeheerder bij een gemeente waar wij onder andere het OS HPUX draaien op een Itanium blade, welke Oracle databases draait. Geloof maar dat dit een enorme performance winst geeft tegenover zijn voorganger (PA-RISC).
In windows server omgevingen zie ik het nut tov Xeons ook niet zo.
In windows server omgevingen zie ik het nut tov Xeons ook niet zo.
je vergelijkt ook appelen met peren.
Pa-risc wordt al lang niet meer gemaakt.
die je vergelijkt een 386 met een pentium.
Pa-risc wordt al lang niet meer gemaakt.
die je vergelijkt een 386 met een pentium.
Dat geloof ik best. Ik heb ook ergens gezien waar Itanium gebasseerde systemen oude Sun hardware vervingen die nog op de 68030 draaide. De performance winst was werkelijk enorm.Geloof maar dat dit een enorme performance winst geeft tegenover zijn voorganger (PA-RISC).
Hoe dit precies ervoor pleit dat de huidige Itaniums een performance voordeel hebben t.o.v. de huidige x86 processors (De oct core Nehalems bijvoorbeeld die laatst in het nieuws waren), weet ik ook niet eigenlijk.
Misschien wat offtopic, maar waar heeft een gemeente in godsnaam een (peperduur) Itanium systeem voor nodig?
Heel jammer! De IA-64 was een mooi platform. Helemaal vanaf de grond af aan 64 bits opgebouwd en geen legacy x86. HP staat trouwens aan de kinderschoenen van de itanium, later pas is Intel ingestapt en werd het een samenwerkingsverband tussen deze twee. Helaas kon het platform qua performance niet goed op tegen de x86. Maar het ontwerp was zeker mooi.
Eigenlijk lijkt de itanium debakel wel een beetje op de Nvidea Fermi: een fantastisch ontwerp, maar te laat, te duur, en uiteindelijk toch tegenvallende resultaten.
Het einde van Microsoft support betekent echter nog niet het einde van itanium zelf: voor 2012 staat een nieuw model op stapel (de Poulson).
Eigenlijk lijkt de itanium debakel wel een beetje op de Nvidea Fermi: een fantastisch ontwerp, maar te laat, te duur, en uiteindelijk toch tegenvallende resultaten.
Het einde van Microsoft support betekent echter nog niet het einde van itanium zelf: voor 2012 staat een nieuw model op stapel (de Poulson).
[Reactie gewijzigd door bobwarley op 5 april 2010 13:51]
Mee eens.
De IA-64 (Itanium) is nog steeds een heel mooi platform en blijft dat ook. Er komen immers nog meer nieuwe generaties Itanium uit.
Microsoft denkt alleen maar in zijn eigen straatje en denkt dat Windows het enige software Operating System is wat er bestaat.
Dat is natuurlijk niet zo.
Daar komt nog bij dat de architectuur van de Itanium wezenlijk anders is dan van de X86. Foutcorrectie en toleraties zijn heel anders. De Itanium is gewoonweg veel betrouwbaarder dan de X86.
Intel laat dit in zijn datasheets ook duidelijk zien. De doelgroep is ook anders. Je kunt een gewone PC niet vergelijken met een professionele high-end computer.
Microsoft (Windows) blijft toch een beetje op de consumenten markt hangen. De server software is voor entry level servers maar meer dan ook niet.
De Itanium zit een level hoger.
De IA-64 (Itanium) is nog steeds een heel mooi platform en blijft dat ook. Er komen immers nog meer nieuwe generaties Itanium uit.
Microsoft denkt alleen maar in zijn eigen straatje en denkt dat Windows het enige software Operating System is wat er bestaat.
Dat is natuurlijk niet zo.
Daar komt nog bij dat de architectuur van de Itanium wezenlijk anders is dan van de X86. Foutcorrectie en toleraties zijn heel anders. De Itanium is gewoonweg veel betrouwbaarder dan de X86.
Intel laat dit in zijn datasheets ook duidelijk zien. De doelgroep is ook anders. Je kunt een gewone PC niet vergelijken met een professionele high-end computer.
Microsoft (Windows) blijft toch een beetje op de consumenten markt hangen. De server software is voor entry level servers maar meer dan ook niet.
De Itanium zit een level hoger.
naja, waarom zou je een procesor indersteunen als je er toch geen fatsoenlijke toepassingen voor hebt
De echte concurrent voor itanium moet je meer zoeken in de hoek van de power processoren van IBM (ibm pseries servers). Itanium zit tegenwoordig ook in de hp non-stop servers (tandem). Dat is echt een hele andere markt als x86 of de 64 bits variant daarop alhoewel die laatste daar wel naar toe kruipt.
[Reactie gewijzigd door joop99 op 5 april 2010 14:05]
Jammer dat voor de komst van Itanium destijds DEC Alpha (ooit opgekocht door Compaq wat weer werd opgekocht door HP dat vriendjes was met MS) de nek is omgedraaid, want dat platform was in de server en workstation markt aardig succesvol (met o.a. beschikbaarheid op vele Linuxen, Windows NT 4.0 (er is zelfs nog een beta van 2K geweest).
Ok... ben bevoordeelt, had zelf een Alpha
Ok... ben bevoordeelt, had zelf een Alpha
Alpha wordt veelal gezien als de meest elegante architectuur tot nu toe. Op de voet gevolgd door PowerPC en wellicht ARM. Je bent niet de enige 
x86 is de meest rommelige van allemaal, die door wat samenvallende gebeurtenissen het grootste aandeel vergaard heeft. En met miljarden aan investeringen is een kinderlijk ontwerp toch een lijn van super CPU's geworden. Eigenlijk een schande, bijna.
x86 is de meest rommelige van allemaal, die door wat samenvallende gebeurtenissen het grootste aandeel vergaard heeft. En met miljarden aan investeringen is een kinderlijk ontwerp toch een lijn van super CPU's geworden. Eigenlijk een schande, bijna.
Inderdaad, eigenlijk een schande. De x86 was in haar tijd telkens de allerslechtste CPU. Ten tijde van de 8080, 80286 etc kwam de concurentie van Motorola in de vorm van d 68000, 68020, etc. Deze chip werd nagenoeg overal gebruikt, vele andere computer platformen zoals Sun servers, de Apple Mac, de Amiga, de Atari, en spel computers zoals de Genesis, de Neo Geo, de CPS2 en vele arcade hardware, gebruikte allemaal die chips.Eigenlijk een schande, bijna.
Er was geen enkele reden om de x86 te kiezen, alleen de PC koos die omdat dat toen nu eenmaal de slechtste computer was en daar dus logisch gezien ook de slechtste CPU bij hoorde.
Maar stapje voor stapje werd die gare x86 beter en stapje voor stapje hadden de concurrenten het nakijken. Technisch gezien idd een schande.
Op software gebied zie ik dit trouwens ook wel. Een paar jaar terug werkte ik ergens waar ze een legacy code base hadden, die van een excel sheet van het neefje van de baas, via visual basic op de een of andere reden een C++ app was geworden, met overal WTF's van het kaliber dat ze er op thedailywtf nog verbaast van zouden zijn. Alle programmeurs wilde van scratch beginnen, en dat gebeurde toen ook. Maar alleen de basis weer up 'n running krijgen ging zo veel tijd in zitten, en zo veel fouten werden gewoon weer overnieuw gemaakt, dat de rewrite op het laatst is afgeblazen. De bruikbare nieuwe stukken zijn toen overgeport, en stap voor stap is het legacy systeem toen verbeterd, wat uiteindelijk iets heeft opgeleverd wat het eind doel was van de rewrite.
Schande misschien voor IT-esthetici die elegantie belangrijker vinden dan real world prestaties. De succesvolste produkten (en als je in de natuur kijkt, dier en plantsoorten) zijn vrijwel altijd robuust, flexibel en veelzijdig, en zelden elegant en specialistisch.Voorbeelden te over, om er in de techniek nog maar eentje te noemen: er zijn de afgelopen zeventig jaar al vele mooie ontwerpen van gerenommeerde tekentafels gerold die in theorie veel beter waren, maar de bestverkochte sportwagen ter wereld is nog altijd een inmiddels onherkenbaar doorontwikkelde Type 12. En wie had gedacht dat anno 2010 de meeste servers nog steeds op in de jaren 70 ontworpen OSsen zouden werken.
x86 is bijzonder schaalbaar en uitbreidbaar (van protected mode naar MMX naar de huidige hardware virtualisatie extensies) gebleken, meer dan welke architectuur ook. Revolutie heeft de meeste verbeeldingskracht, maar Evolutie wint bijna altijd.
x86 is bijzonder schaalbaar en uitbreidbaar (van protected mode naar MMX naar de huidige hardware virtualisatie extensies) gebleken, meer dan welke architectuur ook. Revolutie heeft de meeste verbeeldingskracht, maar Evolutie wint bijna altijd.
[Reactie gewijzigd door Dreamvoid op 5 april 2010 23:32]
Wellicht, en eigenlijk bedoel ik dat ook, maar de 680x0 had net zo goed kunnen evolueren, maar die liep dood. PPC had ook kunnen evolueren maar ook die liep dood (nja, zo goed als, het bestaat nog in de marge).maar Evolutie wint bijna altijd.
Juist de allerzwakte CPU van toen is geevolueerd in bijna de aller sterkste, en in haar segment zelfs de aller sterktste.
Windows 9x heeft het trouwens niet gered qua evolutie...
ARM elegant? Hmm... Da's vier dagen te laat.
Het valt me trouwens op dat je MIPS niet noemt. Ook al is het een beetje een academische architectuur die in relatief weinig "echte" toepassingen gebruikt wordt zit er wel een goede gedachte achter. Zo wordt een voorgestelde nieuwe instructie bijvoorbeeld pas daadwerkelijk toegevoegd als aangetoond kan worden dat deze een performanceverbetering oplevert van minstens 1% in een gemiddeld programma.
Het valt me trouwens op dat je MIPS niet noemt. Ook al is het een beetje een academische architectuur die in relatief weinig "echte" toepassingen gebruikt wordt zit er wel een goede gedachte achter. Zo wordt een voorgestelde nieuwe instructie bijvoorbeeld pas daadwerkelijk toegevoegd als aangetoond kan worden dat deze een performanceverbetering oplevert van minstens 1% in een gemiddeld programma.
Hoe bedoel je? MIPS is bijna anderhalf decennia-lang een marktleider geweest in HPC, in SGI, Tandem en enkele Cray-systemen. Ik heb zelf bijvoorbeeld nog een R16000 (MIPS IV) Tezro systeem, werkt geweldig. Gaat nog heel goed mee.
Wat betreft PowerPC, wat dacht je van POWER? POWER4, POWER5, POWER6 en de meest recente POWER7 zijn ook niet niks moet ik zeggen! Ik heb zelf hier ook een 2-way POWER4 systeem en het is echt een geweldig systeem moet ik zeggen. (Extra leuk, omdat het één van de laatste 'workstation' modellen was van IBM).
Wat ARM betreft, die beginnen flink ook de 'netbook' e.d. markten in te slaan, helemaal ook sinds de iPad en al. (Hoewel ik zelf niet zo'n Apple-adept ben).
Wat betreft PowerPC, wat dacht je van POWER? POWER4, POWER5, POWER6 en de meest recente POWER7 zijn ook niet niks moet ik zeggen! Ik heb zelf hier ook een 2-way POWER4 systeem en het is echt een geweldig systeem moet ik zeggen. (Extra leuk, omdat het één van de laatste 'workstation' modellen was van IBM).
Wat ARM betreft, die beginnen flink ook de 'netbook' e.d. markten in te slaan, helemaal ook sinds de iPad en al. (Hoewel ik zelf niet zo'n Apple-adept ben).
Niet alleen een beta hoor, een RC2 zelfs
Was inderdaad wel een mooi platform
Was inderdaad wel een mooi platform
Het probleem met Alpha was dat de productie fundamenteel duur was. Nou zie je dat niet zo gauw met een serverprocessor: die kost bijvoorbeeld 1000 dollar, waarvan 600 dollar productie en 400 aan R&D. Als je de productie opvoert, en je de R&D dan over 10 keer zoveel processoren kunt uitsmeren, dan komt de prijs op 640 dollar. Een andere serverchip met 500 dollar productie en 600 dollar R&D lijkt in eerste instantie duurder, maar bij vertienvoudiging van de productie zakt de prijs naar 560 dollar.
Bij de Alpha zag je dat bijvoorbeeld terug in het aantal lagen metaal wat nodig was om alle transistoren te verbinden. Dat was hoger dan bij Intel chips uit die tijd, en niet goedkoop om te maken. Een slimmer design met minder metaallagen has meer R&D gekost, maar was goedkoper geweest om te produceren.
Bij de Alpha zag je dat bijvoorbeeld terug in het aantal lagen metaal wat nodig was om alle transistoren te verbinden. Dat was hoger dan bij Intel chips uit die tijd, en niet goedkoop om te maken. Een slimmer design met minder metaallagen has meer R&D gekost, maar was goedkoper geweest om te produceren.
Oorspronkelijk was de verwachting dat de Itanium in een razend tempo de wereld zou overnemen. Zie de bekende grafiek in het artikel op Wikipedia over Itanium (http://en.wikipedia.org/wiki/Itanium).
Ik dacht dat naast de problemen met vertraagde releases, en de komst van AMD's 64-bits processors, er nog een specifiek probleem was: Itanium maakte gebruik van een nieuw concept voor paralleliseren van opdrachten (EPIC: Explicitly Parallel Instruction Computing). Toen puntje bij paaltje kwam, bleek het ondoenlijk te zijn om compilers te schrijven die dat goed konden benutten. Donald Knuth schreef daarover, maar ik kan zo snel geen link boven water toveren.
Ik dacht dat naast de problemen met vertraagde releases, en de komst van AMD's 64-bits processors, er nog een specifiek probleem was: Itanium maakte gebruik van een nieuw concept voor paralleliseren van opdrachten (EPIC: Explicitly Parallel Instruction Computing). Toen puntje bij paaltje kwam, bleek het ondoenlijk te zijn om compilers te schrijven die dat goed konden benutten. Donald Knuth schreef daarover, maar ik kan zo snel geen link boven water toveren.
HPUX op itanium komt al jaren met prima C/C++ compilers (www.hp.com/go/cpp). De binaries die er uitrollen zijn wel groter dan andere OSs. Dat zit o.a. inderdaad in het EPIC verhaal. Het presteert allemaal wel lekker.
Het is wel erg jammer dat Intel er zo lang over doet om Itanium de techniek te geven die het al lang in de lagere regionen heeft gegeven. Wellicht spelen politieke motieven (t.o.v. HP) een rol??
In ieder geval pas de Itanium niet in het rijtje Pentium, x86, AMD, maar wel in het rijtje SPARC, PowerPC. Alhoewel je wel af gaat vragen waarom je voor 10K euro een prachtige snelle Xeon(MP) hebt staan, maar voor dat bedrag nauwelijks het allersimpelste Sun/IBM/HP integrity systeem hebt staan.
En ja, zo'n Xeon(MP) bak schaalt dan in sommige opzichten minder, maar gezien de prijs, zal SUN, IBM, HP de hete adem van dat soort systemen wel voelen. De prijzen voor Unix-achtige systemen is de afgelopen jaren (mede daarom?) fors gezakt. Je kunt echter nog steeds 100k+ (of veel meer ++) kopen.
De recente Xeon MP heeft wel een erg hoge nieuwe max. geheugenlimiet. Een nieuwe aanslag op Intel's eigen Itanium en de powerPC/Sparc?
Zo'n relaxte positie zit Sun niet met z'n SPARCs. Zo hard lopen de ontwikkelingen daar de afgelopen jaren ook niet. En een SUN Txxx (niagara) is weer erg anders dan een monoliet/single-threaded SPARC64V. Ben benieuwd hoe Oracle met deze Itanium concurrent verder gaat.
Het is wel erg jammer dat Intel er zo lang over doet om Itanium de techniek te geven die het al lang in de lagere regionen heeft gegeven. Wellicht spelen politieke motieven (t.o.v. HP) een rol??
In ieder geval pas de Itanium niet in het rijtje Pentium, x86, AMD, maar wel in het rijtje SPARC, PowerPC. Alhoewel je wel af gaat vragen waarom je voor 10K euro een prachtige snelle Xeon(MP) hebt staan, maar voor dat bedrag nauwelijks het allersimpelste Sun/IBM/HP integrity systeem hebt staan.
En ja, zo'n Xeon(MP) bak schaalt dan in sommige opzichten minder, maar gezien de prijs, zal SUN, IBM, HP de hete adem van dat soort systemen wel voelen. De prijzen voor Unix-achtige systemen is de afgelopen jaren (mede daarom?) fors gezakt. Je kunt echter nog steeds 100k+ (of veel meer ++) kopen.
De recente Xeon MP heeft wel een erg hoge nieuwe max. geheugenlimiet. Een nieuwe aanslag op Intel's eigen Itanium en de powerPC/Sparc?
Zo'n relaxte positie zit Sun niet met z'n SPARCs. Zo hard lopen de ontwikkelingen daar de afgelopen jaren ook niet. En een SUN Txxx (niagara) is weer erg anders dan een monoliet/single-threaded SPARC64V. Ben benieuwd hoe Oracle met deze Itanium concurrent verder gaat.
[Reactie gewijzigd door kdekker op 6 april 2010 15:21]
Het idee van de Itanium was volgens mij dat een processor in principe uit enkel execution units moet bestaan, de rest is alleen overhead. Instruction level parallelism vinden, reorderen, registers renamen, alles moest door de compiler gedaan worden.
Eerst Dec Alpha dood, nu de nagel aan de doodskist voor Intel Itanium, Apple had PowerPC al in de ban gedaan, welke 64-bit processor volgt?
SPARC natuurlijk. Kijk naar Sun, die heeft Solaris op x86-64 niet voor niets opnieuw leven ingeblazen.
OpenVMS draaien dan maar ;-)
Die gebruikers komen van Alpha af en stappen over naar Itanium. Lekker snel en stabiel.
Die gebruikers komen van Alpha af en stappen over naar Itanium. Lekker snel en stabiel.
Ik heb OpenVMS nog niet kunnen uitproberen draaiend op de Itanium [2], maar het lijkt me inderdaad heel interessant. Ik hoorde ooit van iemand dat Mac OS X aanvankelijk gepland was voor Itanium en dat de eerste versies enorm snel waren, zelfs ‘te snel’ (als daar überhaupt ooit sprake van kan zijn). Het werd uiteindelijk dus afgeblazen.
Hoe dan ook, of Windows voor Itanium beschikbaar zal zijn of niet maakt niks uit, voor OpenVMS alleen zal het blijven bestaan! Er zijn een hoop bedrijven die zelfs zeer gedateerde Alpha-systemen nog hebben draaien (zie eBay voor de belachelijk dure prijzen voor sommige van die ‘pre-historische’ systemen en onderdelen), alleen dus om VMS draaiend te houden...
Hoe dan ook, of Windows voor Itanium beschikbaar zal zijn of niet maakt niks uit, voor OpenVMS alleen zal het blijven bestaan! Er zijn een hoop bedrijven die zelfs zeer gedateerde Alpha-systemen nog hebben draaien (zie eBay voor de belachelijk dure prijzen voor sommige van die ‘pre-historische’ systemen en onderdelen), alleen dus om VMS draaiend te houden...
Op dit item kan niet meer gereageerd worden.
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
