Intel har sålt sina sista Itanium-processorer

Permalänk
Melding Plague

Intel har sålt sina sista Itanium-processorer

Intels alternativ till x86 tar sitt sista andetag efter en 20 år lång karriär. Plattformen såg begränsade framgångar men fann stöd hos partnern HP.

Läs hela artikeln här

Permalänk
Hedersmedlem

Vila i fred Itanic :/

Intel var lite för självsäkra på att allt de gjorde var rätt då runt millenieskiftet. Rdram, Netburst/P4, inte hoppa på ddr-tåget och sen Itanium...

Cool teknik dock, men väldigt smalt användningsområde.

Permalänk
Festpilot 2020, Antiallo

Konkurrens välkomnas. Hoppas AMDs ARM-cpu dyker upp på nytt, att Nvidias ARM-baserade servar får fart, RISC-V får ett brett mottagande och gott stöd även i prestanda segmentet.

Permalänk
Medlem

1995 kom Intel med Pentium Pro och demonstrerade att vägen mot mer prestanda var out of order execution (OoOE). Efter det verkar allt Intel hittar på i åtminstone 15 år handla om att ta bort OoOE på något sätt och få prestanda genom andra trick - Itanium, första Atom, Larrabee. Bara för säkerhets skull brukar de göra en uppfräschning av Pentium Pro också, och det är det som alltid räddar dem när de mer högtflygande planerna kraschar som ett JAS-plan. Är det intern konkurrens på Intel som gör att gruppen som inte gjorde Pentium Pro skall hämnas eller nåt?

Permalänk
Medlem

Har sett IA-64 som arkitektur för ISO/operativsystem installationer. Men visste aldrig vad det var. Kul att veta nu

Permalänk
Medlem

Itanium.

Har en HP-itanium dual-processor server i retro-avelningen, drar ca 300W och ungefär samma prestanda om en Raspberry-PI.

Synd att HP lade ned utvecklingen av Digitals Alpha-arkitektur då man satsade på Itanium i stället. Hade varit intressant att se vilken prestanda man kunde nått på den. En gång i tiden var det den snabbaste processorn som fanns.

Permalänk
Medlem
Skrivet av SAFA:

Har en HP-itanium dual-processor server i retro-avelningen, drar ca 300W och ungefär samma prestanda om en Raspberry-PI.

Synd att HP lade ned utvecklingen av Digitals Alpha-arkitektur då man satsade på Itanium i stället. Hade varit intressant att se vilken prestanda man kunde nått på den. En gång i tiden var det den snabbaste processorn som fanns.

Var inte en av arkitekterna bakom Alphan också bakom AMD64?

EDIT: Jim Keller gjorde en del alpha-design och var med och tog fram x86-64

Permalänk
Medlem
Skrivet av OSkar000:

Vila i fred Itanic :/

Intel var lite för självsäkra på att allt de gjorde var rätt då runt millenieskiftet. Rdram, Netburst/P4, inte hoppa på ddr-tåget och sen Itanium...

Cool teknik dock, men väldigt smalt användningsområde.

Intel jagade helt klart den där "Kioskvältande" tekniken för att vända det faktum att man började hamna efter på marknaden. Och då blir det mycket hit n' miss även om Intel verkade missa betydligt mer än de träffade där ett bra tag.

Det kan lite jämföras med AMDs försök när de började hamna efter med halvkärnor (moduler) och Bulldozer som slutade i fiasko. Till skillnad från Intel valde dock AMD att lära sig något ur sina misstag och lanserade Ryzen. Intel valde istället att skrota sina och hoppas på att ingen kom ihåg dem.

Skrivet av Youjimbo:

Var inte en av arkitekterna bakom Alphan också bakom AMD64?

EDIT: Jim Keller gjorde en del alpha-design och var med och tog fram x86-64

Jim Keller är helt klart en pionjär när det kommer till utveckling av processorer. Det var AMDs utveckling av x86-64 som låg till grund för deras dominans på början av 2000-talet. Det är även Jim Keller som är hjärnan bakom AMDs Zen-arkitektur.

Permalänk
Chefredaktör 🕹
Skrivet av Xinpei:

Intel jagade helt klart den där "Kioskvältande" tekniken för att vända det faktum att man började hamna efter på marknaden. Och då blir det mycket hit n' miss även om Intel verkade missa betydligt mer än de träffade där ett bra tag.

Det kan lite jämföras med AMDs försök när de började hamna efter med halvkärnor (moduler) och Bulldozer som slutade i fiasko. Till skillnad från Intel valde dock AMD att lära sig något ur sina misstag och lanserade Ryzen. Intel valde istället att skrota sina och hoppas på att ingen kom ihåg dem.

Jag tror det är svårt att dra paralleller där, arbetet med Itanium påbörjades ju när Intel var kungar på tronen på konsumentmarknaden men det här var ett av stegen att försöka få in Intel på HPC och servermarknaden som på den tiden var en ganska konkurrensutsatt marknad med MIPS, Sparc, DEC Alpha, PowerPC mfl.
Och den levde ju trots allt i 20 år (eller 16-17 beroende på hur man räknar) långt efter att ovan nämnda konkurrenter i princip försvunnit.

Men den lanserades onekligen precis mitt i Intels svacka där vid millenieskiftet om vi talar x86. Men då hade ju arbetet redan pågått i över fem år (10 om vi räknar med när HP påbörjade det). men det blir fel att säga at det vore en reaktion på att de halkat efter.

I slutändan så lyckades ju också Intel med det de ville, att slå sig in på HPC/workstation/server etc fast dock med Xeon istället för Itanium.

Permalänk
Medlem
Skrivet av UndaC:

Jag tror det är svårt att dra paralleller där, arbetet med Itanium påbörjades ju när Intel var kungar på tronen på konsumentmarknaden men det här var ett av stegen att försöka få in Intel på HPC och servermarknaden som på den tiden var en ganska konkurrensutsatt marknad med MIPS, Sparc, DEC Alpha, PowerPC mfl.
Och den levde ju trots allt i 20 år (eller 16-17 beroende på hur man räknar) långt efter att ovan nämnda konkurrenter i princip försvunnit.

Men den lanserades onekligen precis mitt i Intels svacka där vid millenieskiftet om vi talar x86. Men då hade ju arbetet redan pågått i över fem år (10 om vi räknar med när HP påbörjade det). men det blir fel att säga at det vore en reaktion på att de halkat efter.

I slutändan så lyckades ju också Intel med det de ville, att slå sig in på HPC/workstation/server etc fast dock med Xeon istället för Itanium.

Att något lever länge är i sig inte ett argument för att teknologin varit bra. Sedan skall man vara medveten om att Intel var på kraftig nedgång för 17 år sedan. Var ju i samma veva som man insåg att Netburst var en fullständigt flopp. Det var även i samma veva man började muta diverse parter för att slå undan benen för AMD.

Sedan sa jag inte att det var orsaken att de halkat efter utan snarare var resultatet av att de börjat halka efter alt. stagnerat. Vilket just Netburst bevisade.

Permalänk
Chefredaktör 🕹
Skrivet av Xinpei:

Att något lever länge är i sig inte ett argument för att teknologin varit bra. Sedan skall man vara medveten om att Intel var på kraftig nedgång för 17 år sedan. Var ju i samma veva som man insåg att Netburst var en fullständigt flopp. Det var även i samma veva man började muta diverse parter för att slå undan benen för AMD.

Sedan sa jag inte att det var orsaken att de halkat efter utan snarare var resultatet av att de börjat halka efter alt. stagnerat. Vilket just Netburst bevisade.

Jag tänker mer att inget av detta hade med framtagandet av Itanium att göra. Det påbörjades av HP 1989, Intel hoppade på tåget 1995. Det var inte en reaktion på vad som hände på konsumentmarknaden för x86.

Och angående att plattformen var relativt långlivad så var det bara ett svar på det du skrev om att de bara skrotade satsningen och glömde den. Det gjorde de ju inte, de fortsatte lansera Itanium-modeller fram till 2017.
Det betyder ju inte att de var bra eller att de sålde jättemycket: men det var ju iaf inte att "skrota och hoppas att folk ska glömma bort" var allt jag menade.

Permalänk
Medlem

Att Itanium togs fram hade många anledningar. En av dem var att HP hade sina egna VLIW-processorer (PA-RISC) och extremt gärna ville att ersättaren till dem skulle komma från Intel för att slippa stå för hela kostnaden själva. Detta ledde till EPIC, som kan ses som en utveckling av VLIW. Intel hade allt tänkt att göra något nytt att ersätta x86 - dels för att PowerPC såg lite farligt ut ett tag, dels för att man ville göra sig av med AMD. Dessutom hade man fabriker att fylla, och ville expandera in på den lukrativa server-marknaden. När HP kom och knackade och hade ett koncept klart, var det perfekt för Intel.

Fun fact, för övrigt: Itaniums första kodnamn var P7, som ersättare till P6 (Pentium Pro). När första generationen var oanvändbart långsam på x86-kod och Athlon grillade Intel, fick det bli en ”P67”, det som sedan blev Netburst.

Permalänk
Datavetare
Skrivet av mpat:

1995 kom Intel med Pentium Pro och demonstrerade att vägen mot mer prestanda var out of order execution (OoOE). Efter det verkar allt Intel hittar på i åtminstone 15 år handla om att ta bort OoOE på något sätt och få prestanda genom andra trick - Itanium, första Atom, Larrabee. Bara för säkerhets skull brukar de göra en uppfräschning av Pentium Pro också, och det är det som alltid räddar dem när de mer högtflygande planerna kraschar som ett JAS-plan. Är det intern konkurrens på Intel som gör att gruppen som inte gjorde Pentium Pro skall hämnas eller nåt?

En möjlighet är ju: Intel insåg tidigt att om OeOE är enda vettiga vägen framåt så är x86 inte rätt teknik för framtiden, eller?

Ett sätt runt det är ju att hitta andra sätt att dra upp prestanda, sätt där bagaget x86 drar på inte sätt några stora hinder. Både Intel och AMD lär har testat "smala" designer klockade till månen, för det om det hade fungerat vore det ett sätt att undvika begränsningar i x86.

Itanium var på flera sätt att göra att "by the book" och ändå helt köra i diket. När det projektet drog igång var VLIW, eller någon variant av den tekniken, det väldigt många forskare ansåg vara "framtiden". Grundtanken var att flytta mer av analys in i kompilatorer och OS, detta då man snabbt insåg hur mycket kisel (och därmed yta och ström) det kostade att lägga in sådan i HW.

Tankevurpan visade sig vara att man bara tänkt på halva problemet... Man kan bara göra analys av det man faktiskt vet "up-front", d.v.s. man kan göra en statisk analys av programmet. Ju mer gapet växte mellan hastighet mot RAM och hastigheten CPUer kunde köra på, ju viktigare blev den dynamiska analysen av programmet som körs!

D.v..s det var rätt att satsa på IA-64, man insåg att x86 började visa sina brister och man gick efter det forskningsvärlden trodde var rätt. Tyvärr gjorde man det när forskningsvärlden var i en rejäl återvändsgränd

Arm och RISC-V gänget har nog haft god nytta av Itanium, för de såg ett annat problem med VLIW/EPIC, att skapa en bra kompilator för ett sådan system var också något som visade sig vara långt mer komplicerat än någon kunde förutse. Så de vände helt på steken: designa en ISA som gör det så enkelt som möjligt att designa effektiva verktyg + kollade också på vad som hindrar äldre ISA från att göras extremt "breda" och undvek även de problemen.

Det jag anser vara Itaniums viktigaste bidrag till eftervärlden är just jobbet som gjordes runt kompilatordesign, för man forskade en hel del på detta. Detta sammanfattades i ett dokument som sedan rejält inspirerat programspråksdesign, specifikt hur man idag specificerar vilka regler ett programspråk har runt garantier hos multitrådade program. Man hade tänkt mycket på den aspekten i designen av Itanium, men som alla v1.0 nådde man inte riktigt ända fram, fanns en del designmissar. Även här var Arm och RISC-V framme och tog lärdom, de har idag "perfekta" ISA på HW-nivå för C, C++, Java, m.fl.

Sen lever faktiskt Netburst kvar mer än man kan tro. Pentium Pro upp till Nehalem var rätt mycket en evolution av föregående modell. Sandy Bridge (SNB) ser på en översiktsbild rätt mycket ut som en fortsättning på Nehalem, och dess "back-end" delar väldigt mycket med Nehalem.

Men SNB var en syntes av PPro linjen och de saker som faktiskt var vettiga idéer i Netburst. SNB hade en helt "från-scratch" front-end, den innehåller bl.a. en mikro-op cache som var en vidareutveckling av P4:ans trace-cache. Dessa är en bra idé då de kommer runt den extremt komplexa (strömtörstiga) delen att avkoda x86 instruktioner. AMD implementerade också detta i Zen.

Back-end må se ut väldigt mycket som Nehalem, men skrapar man på ytan är detaljerna kring hur OoOE implementeras väldigt olika i Nehalem och SNB, SNB använder samma grundläggande teknik som användes i P4 fast med en betydligt "bredare" back-end.

Atom-spåret lär väl ändå anses vara framgångsrikt? Svårt att se Intel ha någon relevans alls bland inbyggda-system utan Atom. Nu är Atom standardvalet i t.ex. NAS, våra 5G system kommer primärt köras på Atom-baserade plattformar (Tremont).

Intel hade länge en policy att för varje funktion som lades till för prestandaökning måste ökning i relativ prestanda vara minst dubbelt så stor som ökning i strömförbrukning. Det bidrog nog till den relativt långsamma prestandaökningen fram till Skylake, tror denna "regel" åket ut genom fönstret när de började känna tryck från AMD.

Bärbara x86 datorer är ett skämt idag, U-serie modellerna ha peak-effekt på 45-50 W medan H-modellerna når peakeffekter på strax under 100 W. P4 var illa, men den drog faktiskt "bara" 88 W om man håller sig till standardmodellerna, för skrivbordet....
Här tror jag Atom kan bli ett rejält fall framåt, tror Gracemont kan överraska på perf/W delen. Det är fortfarande x86, så man kan inte förvänta sig att de kliver förbi t.ex. Apple. Men det kan nog visa sig att Atom har en klar poäng vid sidan av "prestanda till vilken kostnad som helst Core-spåret".

Permalänk
Medlem
Skrivet av UndaC:

Jag tror det är svårt att dra paralleller där, arbetet med Itanium påbörjades ju när Intel var kungar på tronen på konsumentmarknaden men det här var ett av stegen att försöka få in Intel på HPC och servermarknaden som på den tiden var en ganska konkurrensutsatt marknad med MIPS, Sparc, DEC Alpha, PowerPC mfl.
Och den levde ju trots allt i 20 år (eller 16-17 beroende på hur man räknar) långt efter att ovan nämnda konkurrenter i princip försvunnit.

Men den lanserades onekligen precis mitt i Intels svacka där vid millenieskiftet om vi talar x86. Men då hade ju arbetet redan pågått i över fem år (10 om vi räknar med när HP påbörjade det). men det blir fel att säga at det vore en reaktion på att de halkat efter.

I slutändan så lyckades ju också Intel med det de ville, att slå sig in på HPC/workstation/server etc fast dock med Xeon istället för Itanium.

Vad jag har förstått var tanken med Itanium att ersätta X86 men sen fick ju X86 64 bitars stöd och då rullade X86 på istället och Itanium tappade en väldigt stort del av sitt syfte eller tänker jag fel här.

Permalänk
Chefredaktör 🕹
Skrivet av Sorten:

Vad jag har förstått var tanken med Itanium att ersätta X86 men sen fick ju X86 64 bitars stöd och då rullade X86 på istället och Itanium tappade en väldigt stort del av sitt syfte eller tänker jag fel här.

Jo men på sätt och vis, men snarare än att se Itanium som en ersättare för x86 på alla plan (dvs även konsumentmarknaden) tror jag snarare det är mer relevant att se det som en efterföljare till HP:s PA-RISC och även Intels i860.

Permalänk
Medlem

Oj!

Hade fått för mig att Itanium hörde till det förflutna, att Itanium varit borta sen länge.
Där ser man...

Permalänk
Medlem
Skrivet av mpat:

Att Itanium togs fram hade många anledningar. En av dem var att HP hade sina egna VLIW-processorer (PA-RISC) och extremt gärna ville att ersättaren till dem skulle komma från Intel för att slippa stå för hela kostnaden själva. Detta ledde till EPIC, som kan ses som en utveckling av VLIW. Intel hade allt tänkt att göra något nytt att ersätta x86 - dels för att PowerPC såg lite farligt ut ett tag, dels för att man ville göra sig av med AMD. Dessutom hade man fabriker att fylla, och ville expandera in på den lukrativa server-marknaden. När HP kom och knackade och hade ett koncept klart, var det perfekt för Intel.

Fun fact, för övrigt: Itaniums första kodnamn var P7, som ersättare till P6 (Pentium Pro). När första generationen var oanvändbart långsam på x86-kod och Athlon grillade Intel, fick det bli en ”P67”, det som sedan blev Netburst.

Härligt att läsa historia

Tack!

Permalänk
Chefredaktör 🕹
Skrivet av Bengt-Arne:

Oj!

Hade fått för mig att Itanium hörde till det förflutna, att Itanium varit borta sen länge.
Där ser man...

Itanium fick ju ett väldigt dåligt rykte, kanske framförallt bland oss entusiaster.
Men även när det gick riktigt bra för AMD:s Opteron med x86-64 så omsatte Intel mycket mer med Itanium t.ex.

Ett exempel från 2011 är att Intel sålde Itaniums för 4 miljarder medan AMD sålde för cirka 6-7 miljarder - men totalt då konsumentprocessorer, opteron, grafikkort, konsolverksamheten osv.

Säger inte att Itanium är en succé, för det är det inte. Men ibland ser saker lite annorlunda ut om man skiftar perspektiv.
Intels flopp t.ex. hade ju varit en enorm framgång om det var AMD som stod för det, sett till företagens relativa storlek. *duckar*

Permalänk
Medlem
Skrivet av SAFA:

Har en HP-itanium dual-processor server i retro-avelningen, drar ca 300W och ungefär samma prestanda om en Raspberry-PI.

Synd att HP lade ned utvecklingen av Digitals Alpha-arkitektur då man satsade på Itanium i stället. Hade varit intressant att se vilken prestanda man kunde nått på den. En gång i tiden var det den snabbaste processorn som fanns.

Jag antar att du menar Raspberry Pi 4 ?

För Raspberry Pi (1) @ stock (700Mhz) skulle ungefär motsvara en Pentium II 350Mhz.
Skulle vara ganska illa om Itanium är SÅÅ slö.

Raspberry Pi Model 2B/3B/3B+
Var hyfsat stor uppgradering mot Pi 1, med övergång från singel core till quad core och ökning i klockfrekvens.

Raspberry Pi Model 4B
Fortfarande quad core och inte så mycket högre klockad än 3B+, men med en ny SoC med bättre IPC (och ny GPU och mer RAM).

Permalänk
Skrivet av Bengt-Arne:

Härligt att läsa historia

Tack!

Enig! En av dom bästa påföljande kommentar-trådarna i SweCs historia också. Tack till alla inblandande! 🥰

//LD

Permalänk
Medlem
Skrivet av Sorten:

Vad jag har förstått var tanken med Itanium att ersätta X86 men sen fick ju X86 64 bitars stöd och då rullade X86 på istället och Itanium tappade en väldigt stort del av sitt syfte eller tänker jag fel här.

Det är väl mer tidslinjen som är fel.

Marty åkte till framtiden innan han åkte till vilda västern*

Om Intel började arbetet med Itanium i en tid När Intels Pentium (1) och AMDs K5 var heta på marknaden så är det ändå ett tag innan AMD släppte Athlon 64 och Opteron.

Men sen blev ju resultatet för större delen av datormarknaden som du säger.
Personligen så hade jag gärna gjort ett "misslyckande" som jag kunde tjäna någon miljard på.

* = Irrelevant Tillbaka till framtiden referens.

Permalänk
Medlem
Skrivet av UndaC:

Itanium fick ju ett väldigt dåligt rykte, kanske framförallt bland oss entusiaster.
Men även när det gick riktigt bra för AMD:s Opteron med x86-64 så omsatte Intel mycket mer med Itanium t.ex.

Ett exempel från 2011 är att Intel sålde Itaniums för 4 miljarder medan AMD sålde för cirka 6-7 miljarder - men totalt då konsumentprocessorer, opteron, grafikkort, konsolverksamheten osv.

Säger inte att Itanium är en succé, för det är det inte. Men ibland ser saker lite annorlunda ut om man skiftar perspektiv.
Intels flopp t.ex. hade ju varit en enorm framgång om det var AMD som stod för det, sett till företagens relativa storlek. *duckar*

Vet inte om jag vill säga dåligt rykte, kanske hos en del, själv såg jag den som avancerad för sin tid.
Itanium var en stor och dyr krets när den kom, avsedd för stora dataset med hög intern och extern bandbredd med instruktioner därefter.
Antagligen orsaken till att jag inte följde den, och då "missade" att den fortfarande producerades.

Den hade sin nisch men absolut inte på PC sidan.
Men tar man en titt i backspegeln och lägger till en av dagens CPU'er som jämförelse, så... Ja...
Tider och teknik är nog lite relativt

Sen ditt exempel från 2011 är intressant, ger verkligen ett perspektiv

Permalänk
Medlem
Skrivet av OSkar000:

Vila i fred Itanic :/

Intel var lite för självsäkra på att allt de gjorde var rätt då runt millenieskiftet. Rdram, Netburst/P4, inte hoppa på ddr-tåget och sen Itanium...

Cool teknik dock, men väldigt smalt användningsområde.

Tänker att det låg i tiden också, försöken att låsa in folk i proprietära standarder med höga licenskostnader och monopolsträvan måste ha nått sin peak där. Jag upplever att det var betydligt fulare spel där kring millenieskiftet.

Permalänk
Medlem
Skrivet av Yoshman:

En möjlighet är ju: Intel insåg tidigt att om OeOE är enda vettiga vägen framåt så är x86 inte rätt teknik för framtiden, eller?

Ett sätt runt det är ju att hitta andra sätt att dra upp prestanda, sätt där bagaget x86 drar på inte sätt några stora hinder. Både Intel och AMD lär har testat "smala" designer klockade till månen, för det om det hade fungerat vore det ett sätt att undvika begränsningar i x86.

Itanium var på flera sätt att göra att "by the book" och ändå helt köra i diket. När det projektet drog igång var VLIW, eller någon variant av den tekniken, det väldigt många forskare ansåg vara "framtiden". Grundtanken var att flytta mer av analys in i kompilatorer och OS, detta då man snabbt insåg hur mycket kisel (och därmed yta och ström) det kostade att lägga in sådan i HW.

Tankevurpan visade sig vara att man bara tänkt på halva problemet... Man kan bara göra analys av det man faktiskt vet "up-front", d.v.s. man kan göra en statisk analys av programmet. Ju mer gapet växte mellan hastighet mot RAM och hastigheten CPUer kunde köra på, ju viktigare blev den dynamiska analysen av programmet som körs!

D.v..s det var rätt att satsa på IA-64, man insåg att x86 började visa sina brister och man gick efter det forskningsvärlden trodde var rätt. Tyvärr gjorde man det när forskningsvärlden var i en rejäl återvändsgränd

Arm och RISC-V gänget har nog haft god nytta av Itanium, för de såg ett annat problem med VLIW/EPIC, att skapa en bra kompilator för ett sådan system var också något som visade sig vara långt mer komplicerat än någon kunde förutse. Så de vände helt på steken: designa en ISA som gör det så enkelt som möjligt att designa effektiva verktyg + kollade också på vad som hindrar äldre ISA från att göras extremt "breda" och undvek även de problemen.

Det jag anser vara Itaniums viktigaste bidrag till eftervärlden är just jobbet som gjordes runt kompilatordesign, för man forskade en hel del på detta. Detta sammanfattades i ett dokument som sedan rejält inspirerat programspråksdesign, specifikt hur man idag specificerar vilka regler ett programspråk har runt garantier hos multitrådade program. Man hade tänkt mycket på den aspekten i designen av Itanium, men som alla v1.0 nådde man inte riktigt ända fram, fanns en del designmissar. Även här var Arm och RISC-V framme och tog lärdom, de har idag "perfekta" ISA på HW-nivå för C, C++, Java, m.fl.

Sen lever faktiskt Netburst kvar mer än man kan tro. Pentium Pro upp till Nehalem var rätt mycket en evolution av föregående modell. Sandy Bridge (SNB) ser på en översiktsbild rätt mycket ut som en fortsättning på Nehalem, och dess "back-end" delar väldigt mycket med Nehalem.

Men SNB var en syntes av PPro linjen och de saker som faktiskt var vettiga idéer i Netburst. SNB hade en helt "från-scratch" front-end, den innehåller bl.a. en mikro-op cache som var en vidareutveckling av P4:ans trace-cache. Dessa är en bra idé då de kommer runt den extremt komplexa (strömtörstiga) delen att avkoda x86 instruktioner. AMD implementerade också detta i Zen.

Back-end må se ut väldigt mycket som Nehalem, men skrapar man på ytan är detaljerna kring hur OoOE implementeras väldigt olika i Nehalem och SNB, SNB använder samma grundläggande teknik som användes i P4 fast med en betydligt "bredare" back-end.

Atom-spåret lär väl ändå anses vara framgångsrikt? Svårt att se Intel ha någon relevans alls bland inbyggda-system utan Atom. Nu är Atom standardvalet i t.ex. NAS, våra 5G system kommer primärt köras på Atom-baserade plattformar (Tremont).

Intel hade länge en policy att för varje funktion som lades till för prestandaökning måste ökning i relativ prestanda vara minst dubbelt så stor som ökning i strömförbrukning. Det bidrog nog till den relativt långsamma prestandaökningen fram till Skylake, tror denna "regel" åket ut genom fönstret när de började känna tryck från AMD.

Bärbara x86 datorer är ett skämt idag, U-serie modellerna ha peak-effekt på 45-50 W medan H-modellerna når peakeffekter på strax under 100 W. P4 var illa, men den drog faktiskt "bara" 88 W om man håller sig till standardmodellerna, för skrivbordet....
Här tror jag Atom kan bli ett rejält fall framåt, tror Gracemont kan överraska på perf/W delen. Det är fortfarande x86, så man kan inte förvänta sig att de kliver förbi t.ex. Apple. Men det kan nog visa sig att Atom har en klar poäng vid sidan av "prestanda till vilken kostnad som helst Core-spåret".

Jag kan köpa logiken i att försöka sig på EPIC, och följaktligen att man då går tillbaka till in-order, men när det inte gick så bra så fortsatte Intel med in-order. Första Atom (allt innan Silvermont) är in-order, och det är först när Intel släpper det som det blir något att ha. Larrabee är också det. ARM kör fortfarande med in-order på sina ”små”, trots att allt demonstrerar att det är mindre effektivt. Jag har svårt att begripa att utvecklare kör vidare med det - finns det nån lobby som vill ha in-order? Nån filosofisk idé att det är renare? Ja jag vet att man inte behöver ha ström till ett stort exekveringsfönster och därför kan kärnan vara ”igång” med extremt låg energiförbrukning, men är det värt effektivitetsförlusten? Och om man nu skall ha det, varför ha mer än en?

Vad gäller Netburst…den arkitekturen har en del rejäla glaskäkar, och Intels plan var att folk helt enkelt skulle undvika de situationerna. Den litade extremt mycket på sin tracecache, och när den missade där så blev decode en flaskhals. Sandy Bridge och därefter har en cache för uops, och när den används så liknar den Pentium 4 rätt mycket, men när den inte används så finns hela den gamla dekodern där, klar att starta och fylla cachen igen. Det är det som jag ser som den stora skillnaden mellan Netburst och modernare Core - inte så mycket glaskäkar.

Sen måste man ju säga att alla processorer som har den strukturen med exekveringsportar ser ut som en Pentium Pro i ett blockdiagram, det är rätt oundvikligt.

Permalänk
Datavetare
Skrivet av mpat:

Jag kan köpa logiken i att försöka sig på EPIC, och följaktligen att man då går tillbaka till in-order, men när det inte gick så bra så fortsatte Intel med in-order. Första Atom (allt innan Silvermont) är in-order, och det är först när Intel släpper det som det blir något att ha. Larrabee är också det. ARM kör fortfarande med in-order på sina ”små”, trots att allt demonstrerar att det är mindre effektivt. Jag har svårt att begripa att utvecklare kör vidare med det - finns det nån lobby som vill ha in-order? Nån filosofisk idé att det är renare? Ja jag vet att man inte behöver ha ström till ett stort exekveringsfönster och därför kan kärnan vara ”igång” med extremt låg energiförbrukning, men är det värt effektivitetsförlusten? Och om man nu skall ha det, varför ha mer än en?

Vad gäller Netburst…den arkitekturen har en del rejäla glaskäkar, och Intels plan var att folk helt enkelt skulle undvika de situationerna. Den litade extremt mycket på sin tracecache, och när den missade där så blev decode en flaskhals. Sandy Bridge och därefter har en cache för uops, och när den används så liknar den Pentium 4 rätt mycket, men när den inte används så finns hela den gamla dekodern där, klar att starta och fylla cachen igen. Det är det som jag ser som den stora skillnaden mellan Netburst och modernare Core - inte så mycket glaskäkar.

Sen måste man ju säga att alla processorer som har den strukturen med exekveringsportar ser ut som en Pentium Pro i ett blockdiagram, det är rätt oundvikligt.

Tja, är ju bara "in-order" designerna som helt klarar sig från Spectre och Meltdown. Alla aktuella OoOE är mottagliga för vissa former av Spectre.

Men ja, "in-order" vurmandet ter sig allt mer märkligt. Enda fördelen är att sådana kretsar går att göra långt enklare, så de har riktigt bra perf/W under last. Men i praktiken är nästan allt någon form av "race-to-sleep" och då blir det effektivare med OoOE.

Nu övergav Intel in-order efter första generationen. Just för Atom försökte man sig ju kompensera med SMT, Atom är den x86 CPU (om vi ignorerar Xeon Phi som var mer en GPU som körde x86) som haft överlägset störst utväxling av SMT. Var regelmässigt >50 % högre prestanda per kärna när båda trådarna användes. Det kan låta "bra", men är ju en konsekvens av att "in-order" designer är så väldigt ineffektiva. Andra tråden har i normalfallet ju gott om resurser att jobba med då "in-order" gör att pipeline "stallar" hela tiden.

Huvudproblemet med P4 var ju löjligt långa pipeline:en och man gjorde det ännu värre med hur front-end och back-end samverkade (motverkade?). Core och Zen är även de kraftigt beroende av god hit-rate från uop-cache, men det Intel lärde sig från P4 är att man kan inte helt förlita sig på trace/uop-cache och ha en nära nog värdelös "normalväg".

Så var ju inte trace-cachen som var problemet, det var hur man hanterade "fall-back". Det fixades i Sandy Bridge.

För Itanium, och VLIW/EPIC rent generellt, var ju ett av huvudpoängerna att man skulle kunna klara sig med väsentligt "in-order" designer och förlita sig på att kompilatorn löser schemaläggningen. I vissa fall, t.ex. traditionell fix-function 3D-grafik, fungerade det riktigt bra. AMD kunde matcha Nvidas prestanda med betydligt färre transistorer när det använde VLIW. Itanium var ju populär inom HPC just då den var rejält mycket bättre på många former av flyttalsberäkningar jämfört med x86.

Problemet för både GPUer och än mer Itanium var ju att mer komplexa / mindre förutsägbara laster fungerar öken på den designen. Itaniums enda fördel raderas ut av GPGPU, det andra CPUer var väsentligt bättre på än GPUer var ju just det Itanium sög på...

Och så vitt jag vet är väl GPUer ett exempel på där "in-order" fortfarande fungerar och är optimalt. Hade det varit vettigt att designa CPUer med hundratals kärnor hade nog "in-order" varit rätt väg att gå, high-end x86 "out-of-order" kärnor drar ju 40-50 W per kärna i peak. Men förstod aldrig hur någon trodde det skulle gå att skriva den typ av programvara vi typiskt kör på CPUer så det effektivt går att köra på hundratals kycklingar i stället för ett fåtal oxar....

Permalänk
Medlem
Skrivet av GuessWho:

Jag antar att du menar Raspberry Pi 4 ?

För Raspberry Pi (1) @ stock (700Mhz) skulle ungefär motsvara en Pentium II 350Mhz.
Skulle vara ganska illa om Itanium är SÅÅ slö.

Raspberry Pi Model 2B/3B/3B+
Var hyfsat stor uppgradering mot Pi 1, med övergång från singel core till quad core och ökning i klockfrekvens.

Raspberry Pi Model 4B
Fortfarande quad core och inte så mycket högre klockad än 3B+, men med en ny SoC med bättre IPC (och ny GPU och mer RAM).

Beror rätt mycket på hur bra kompilator man har, med gcc 4.3.2 så är 2x900 MHz itanium ungefär samma som en Pi 2B 4x900 MHz... så klart beror det mycket på vad man gör också.

Var jag hittade så kostade systemet mellan 20K och 30K usd när det var nytt.

Permalänk
Medlem
Skrivet av Yoshman:

Huvudproblemet med P4 var ju löjligt långa pipeline:en och man gjorde det ännu värre med hur front-end och back-end samverkade (motverkade?). Core och Zen är även de kraftigt beroende av god hit-rate från uop-cache, men det Intel lärde sig från P4 är att man kan inte helt förlita sig på trace/uop-cache och ha en nära nog värdelös "normalväg".

Så var ju inte trace-cachen som var problemet, det var hur man hanterade "fall-back". Det fixades i Sandy Bridge.

Exakt min poäng med glaskäkarna: om branch prediktorn funkar så är prestandan lysande, men om den missar så kostar det massor med den långa pipelinen. Om allt finns i trace cache så går det jättebra, men missar man där så rasar prestandan.

Sen hade ju Intel lite otur med flyttalsprestandan. De fokuserade stenhårt på heltal med dubbelpumpade ALU, och försämrade medvetet flyttalsenheten, för vem skulle köra enskilda x87-operationer i framtiden? Alla vet väl att det är heltal eller SSE som gäller. Det krävs ju nästan att någon designar ett helt programmeringsspråk som gör allt till flyttal, och så korkad kan väl ingen vara? Och om någon är det, så kommer nog det programmeringsspråket inte att få någon spridning.

Citat:

Och så vitt jag vet är väl GPUer ett exempel på där "in-order" fortfarande fungerar och är optimalt. Hade det varit vettigt att designa CPUer med hundratals kärnor hade nog "in-order" varit rätt väg att gå, high-end x86 "out-of-order" kärnor drar ju 40-50 W per kärna i peak. Men förstod aldrig hur någon trodde det skulle gå att skriva den typ av programvara vi typiskt kör på CPUer så det effektivt går att köra på hundratals kycklingar i stället för ett fåtal oxar....

GPUer är in-order och bygger på att man har massor av trådar igång samtidigt. Dock finns det en gräns även här - ett av problemen med AMDs Vega som löstes med Navi var att det var svårt att hålla shaderbanken sysselsatt, eftersom det krävdes så enormt många oberoende trådar. Navi kapade det värdet till en fjärdedel och fick ut markant mycket mer prestanda ur en design som i allt annat är nästan identisk. Trenden är även här att man över tid lägger fler transistorer på ”bokföringen” av vad som skall göras, även om ingen försökt sig på OoOE än.

(Ja, OK, de bytte ut usla GlobalFoundries 14nm mot TSMC 7nm också, och det skadade inte klockfrekvensen direkt, men i arkitekturen var det nästan bara detta man ändrade).

Permalänk
Datavetare
Skrivet av mpat:

Exakt min poäng med glaskäkarna: om branch prediktorn funkar så är prestandan lysande, men om den missar så kostar det massor med den långa pipelinen. Om allt finns i trace cache så går det jättebra, men missar man där så rasar prestandan.

Det hade aldrig gått att göra något riktigt bra med P4-designen, den var verkligen "broken by design". Men vissa val som Intel gjorde resulterade i att slutresultatet blev värre än vad det borde varit.

Itanium hade väl något liknande. Man trodde ju så mycket på att kompilatorn skulle lösa allt att man initialt inte brydde sig om saker som SMT. Just det felet rättade man senare och det gjorde Itanium lite mindre dålig (p.g.a. EPIC var även denna "broken by design") i fall utanför HPC.

Skrivet av mpat:

Sen hade ju Intel lite otur med flyttalsprestandan. De fokuserade stenhårt på heltal med dubbelpumpade ALU, och försämrade medvetet flyttalsenheten, för vem skulle köra enskilda x87-operationer i framtiden? Alla vet väl att det är heltal eller SSE som gäller. Det krävs ju nästan att någon designar ett helt programmeringsspråk som gör allt till flyttal, och så korkad kan väl ingen vara? Och om någon är det, så kommer nog det programmeringsspråket inte att få någon spridning.

Vet inte om man hade otur med med än timing: x87-operationer är bortom räddning och i 64-bitars x86 används de i praktiken inte alls! Även när man kör "skalära" flyttal används SSE/AVX.

Sen JS... Tror du JS skulle kunna prestera så väl som det i praktiken gör med t.ex. Googles V8 motor om man faktiskt använde flyttal för alla beräkningar?

Kollar man vad JIT:en spottar ur sig för t.ex. denna klassiker

function fib(n) { if ( n < 2 ) { return n } return fib(n - 1) + fib(n - 2) }

Så genereras enbart heltalsinstruktioner. Ändrar man den t.ex. till detta så blir det även i praktiken ett flyttalsproblem och väsentligt långsammare

function fib(n) { if ( n < 2 ) { return n } return fib(n - 1.0001) + fib(n - 2) }

Permalänk
Medlem
Skrivet av Yoshman:

Det hade aldrig gått att göra något riktigt bra med P4-designen, den var verkligen "broken by design". Men vissa val som Intel gjorde resulterade i att slutresultatet blev värre än vad det borde varit.

Itanium hade väl något liknande. Man trodde ju så mycket på att kompilatorn skulle lösa allt att man initialt inte brydde sig om saker som SMT. Just det felet rättade man senare och det gjorde Itanium lite mindre dålig (p.g.a. EPIC var även denna "broken by design") i fall utanför HPC.

Nu kan jag ha fel, men jag tror inte att Itanium någonsin stödde SMT - det var fine-grained multithreading AKA Superthreading. Riktig SMT hade varit ännu bättre.

Citat:

Vet inte om man hade otur med med än timing: x87-operationer är bortom räddning och i 64-bitars x86 används de i praktiken inte alls! Även när man kör "skalära" flyttal används SSE/AVX.

Vet det. Problemet med just P4 var x87ans fantastiska stack av flyttalsregister, där det ena registret i varje operation måste vara det första. I P3 och Athlon löste man detta genom att göra FXCH, operationen som byter mellan två flyttals-register, ”gratis” (dvs, den försvann i reordering-steget). Denna trevliga funktion försvann i P4, så all kod som var gjord för tidigare processorer tog helt plötsligt tre operationer att genomföra.

Citat:

Sen JS... Tror du JS skulle kunna prestera så väl som det i praktiken gör med t.ex. Googles V8 motor om man faktiskt använde flyttal för alla beräkningar?

2021, nej. 2001 genererade nog JITen x87-kod. Javascript var långsamt på den tiden, även om man inte körde P4.

Permalänk
Medlem
Skrivet av Yoshman:

Tja, är ju bara "in-order" designerna som helt klarar sig från Spectre och Meltdown. Alla aktuella OoOE är mottagliga för vissa former av Spectre.

Men ja, "in-order" vurmandet ter sig allt mer märkligt. Enda fördelen är att sådana kretsar går att göra långt enklare, så de har riktigt bra perf/W under last. Men i praktiken är nästan allt någon form av "race-to-sleep" och då blir det effektivare med OoOE.

Att in-order designerna är inkompatibla med Spectre och Meltdown är ett plus.

Sen beror det på vad man försöker göra.
Kör man något enklare där en Raspberry Pi Model 2B/3B/3B+ räcker så är det ju rätt onödigt att bygga en X86 PC med en Core i9-9900K eller snabbare för att lösa samma problem.
Även om den är snabbare i "race-to-sleep" så är det svårt att motivera Miditower, 700+ Watt nätagg osv om man klarar sig med något som är mindre än en NUC.

Även Raspberry Pi 4 (OoOE) drar mer ström än Pi 2B/3B/3B+
Så har man ingen/liten nytta av den extra CPU prestandan, RAM och bättre I/O så kan man lika gärna köra på en Pi 2B/3B/3B+

Men Raspberri Pi (oavsett version) är mer för SOHO lösningar och hobbyister.

Itanium var ändå något avsett för HPC lösningar.
Högre säkerhet är bra.
Men om det inte kommer med användbar prestanda för problemet man försöker lösa så är det inte värt så mycket.

Generellt brukar OoOE vara bättre än in-order p.g.a. generellt betydligt bättre prestanda.
Men det betyder inte att in-order system måste vara fel till alla tillämpningar.

Det behöver inte vara helt svart eller vitt.