De ce a fost dificil de scris un compilator pentru procesorul Itanium? (Inginerie software, Istoric, Compilator)

Mason Wheeler a intrebat.

Se afirmă în mod obișnuit că arhitectura procesorului Intel Itanium pe 64 de biți a eșuat din cauza faptului că revoluționarul set de instrucțiuni EPIC a fost foarte dificil de scris un compilator bun, ceea ce a însemnat lipsa unor instrumente bune pentru dezvoltatorii de IA64, ceea ce a însemnat lipsa dezvoltatorilor care să creeze programe pentru această arhitectură, astfel că nimeni nu a vrut să folosească hardware fără prea mult software pentru acesta, astfel că platforma a eșuat, și totul din cauza lipsei de un cui de potcoavă compilatoare bune.

Dar de ce a fost chestiunea compilatoarelor o problemă tehnică atât de dificilă? Mi se pare că, dacă paralelismul explicit din EPIC era dificil de implementat de către furnizorii de compilatoare… de ce să le impună această povară în primul rând? Nu este ca și cum nu exista deja o soluție bună și bine înțeleasă la această problemă: puneți această sarcină pe seama Intel și oferiți compilatorilor o țintă mai simplă.

Itanium a apărut în 1997. Până în acest moment, sistemul Codul P al UCSD era vechi de aproape 20 de ani, iar sistemul de bytecode Z-machine doar puțin mai tânăr, iar JVM era noua stea în ascensiune în lumea limbajelor de programare. Există vreun motiv pentru care Intel nu a specificat un limbaj „bytecode Itanium simplu” și nu a furnizat un instrument care să convertească acest bytecode în cod EPIC optimizat, valorificând experiența celor care au proiectat sistemul?

Comentarii

  • IR-urile de nivel foarte scăzut (care sunt de fapt specificate dincolo de faptul că sunt interne unui compilator și sunt destinate să fie compilate pe un hardware specific, mai degrabă decât interpretate în mod portabil) sunt o invenție mai recentă AFAIK. Asta nu înseamnă că nu au existat deloc, dar cred că ideea nu a fost deloc evidentă sau bine cunoscută pentru o perioadă destul de lungă de timp. Adică, majoritatea oamenilor încă asociază „bytecode” cu „interpretor”. – user7043
  • Presupunând că asta nu se rezolvă pur și simplu la „la ce se gândeau”, este o întrebare destul de bună. –  > Por Robert Harvey.
  • Sistemul P era câine lent în comparație cu ceea ce putea face codul mașină nativ. Pentru viitoarele arhitecturi de procesoare, strategia pe care o descrieți ar putea fi bună acum, când JVM a demonstrat că un JIT poate obține o performanță a codului de uz general care să fie competitivă cu cea a codului nativ, dar nu cred că acest lucru era clar atunci când se dezvolta IA64. Încărcarea unei noi arhitecturi presupus mai rapide cu un VM lent nu ar face probabil cumpărătorii foarte fericiți. –  > Por supercat.
  • @supercat: Nu vorbesc despre o VM ipotetică, ci despre un IR ipotetic care ar fi compilat în restul timpului de un generator de cod Intel. –  > Por Mason Wheeler.
  • Îmi amintesc că am discutat această întrebare specifică la cursul meu de absolvire a cursului de Arhitectură a calculatoarelor cu ani în urmă. Existau motive specifice pentru care Intel a făcut ceea ce a făcut, din păcate nu pot dezgropa nicio resursă definitivă pentru a oferi un răspuns. – user22815
10 răspunsuri
Robert Munn

Din câte îmi amintesc la acea vreme, problema nu era doar particularitățile IA64, ci și concurența cu setul de instrucțiuni x86-64 al AMD. Făcându-și arhitectura retrocompatibilă cu setul de instrucțiuni x86, AMD a reușit să valorifice instrumentele și seturile de competențe existente ale dezvoltatorilor. Mișcarea AMD a avut un succes atât de mare încât Intel (și Via) au fost practic forțate să adopte arhitectura x86-64.

Marea barieră la acea vreme era reprezentată de 4 GB de RAM pe PC-urile desktop (mai realist, ~3,4 GB utilizabili pe Windows). x86-64 a distrus această barieră și a deschis tuturor calculatoarele de putere mai mare. Dacă AMD nu ar fi inventat niciodată x86-64, sunt sigur că Intel ar fi fost fericită să îi facă pe toți cei care doreau să treacă la 4GB+ RAM să plătească ani de zile o primă mare pentru acest privilegiu. Demonstrând cât de încet se mișcă piețele, a fost nevoie de ani de zile pentru ca aplicațiile să ajungă din urmă programarea pe 64 de biți, cu mai multe fire de execuție, și chiar și acum, 4GB RAM este un standard pe PC-urile low-end.

Pe scurt, Intel a încercat să facă un salt revoluționar cu arhitectura IA64, iar AMD a făcut un pas evolutiv cu x86-64. Pe o piață consacrată, pașii evolutivi care permit lucrătorilor din domeniul cunoștințelor să valorifice abilitățile existente vor câștiga în fața pașilor revoluționari care impun tuturor să învețe noi abilități. Indiferent de diferențele calitative dintre arhitecturi, IA64 nu a putut depăși impulsul propriei platforme x86 odată ce AMD a adăugat extensiile x86-64.

Nu cred în explicația conform căreia IA64 era prea dificil de programat. A fost dificil doar în raport cu alternativele. Punctul de vedere al lui @delnan cu privire la IR de nivel scăzut este corect, doar că nu cred că ar fi făcut diferența.

Cât despre motivul pentru care Intel nu a încercat să își asume această sarcină, cine știe? Ei erau cei mai puternici pe piață la acea vreme. AMD era o amenințare, dar Intel era regele dealului. Poate că au crezut că IA64 ar fi atât de mult mai bun decât orice altceva încât ar putea muta întreaga piață. Poate că încercau să creeze un nivel premium și să lase AMD, VIA etc. în al doilea nivel, luptându-se pentru hardware de bază cu marjă mică – o strategie pe care atât Intel, cât și Apple au folosit-o cu succes.

A fost Itanium o încercare deliberată de a crea o platformă premium și de a trage covorul de sub AMD, VIA, etc.? Desigur, așa funcționează afacerile.

Comentarii

  • Toate acestea sunt foarte interesante, dar în mare parte explicați de ce a eșuat Itanium, în timp ce întrebarea se referea la strategia Intel de a promova Itanium. Există un indiciu în „Intel ar fi fost fericit să aibă toată lumea […]”, dar nu îmi este clar dacă insinuați dacă aceasta a fost o decizie deliberată a Intel (și dacă da, ce aveți pentru a susține această afirmație). – user7043
  • Puncte foarte bune. În calitate de fost scriitor de compilatoare, este adevărat că a fi capabil să iei înapoi un compilator existent și să îl ajustezi pentru performanță este mai bine decât să scrii unul din nou. Pe atunci (și poate și acum… nu sunt sigur) scrierea unui back-end de compilator era ceva ce o echipă de 4 sau 5 dezvoltatori putea face într-un an. Este o nucă greu de spart atunci când nimeni nu a adoptat hardware-ul. La vremea respectivă, am ales să construim back-end-uri PowerPC pentru a susține variantele de cutii Unix care erau construite pe acestea. –  > Por Chris Steele.
  • Mai pe scurt, Intel a subestimat foarte mult inerția celor care poartă jugul compatibilității retroactive. AMD a învins Intel la propriul joc, făcând același pas evolutiv față de familia x86 pe care familia x86 l-a făcut față de familia 8086/8088. –  > Por Blrfl.
  • Erm. 80×86 a suportat adresarea fizică pe 36 de biți (sau o limită de „nu chiar 64 GiB de RAM”) încă de la introducerea PAE și PSE36 în jurul anului 1995. Problema a fost că foarte puține versiuni de Windows suportau PAE din cauza incompatibilităților cu driverele de dispozitiv (dar unele o făceau). –  > Por Brendan.
  • @Nubok: Nu este corect – au existat două mecanisme, PAE & PSE-36, pentru a obține acces la memorie >4GB pe mașini pe 32 de biți și niciunul nu a implicat deloc descriptorii de segment. PAE este cel pe care piața a sfârșit prin a-l utiliza (și a fost extins în era 64 de biți). Aceasta mărește dimensiunea intrărilor în tabela de pagini la 8 octeți, permițând adrese mai mari. Cu toate acestea, tabelele de pagini conțin atunci mai puține intrări, astfel încât se adaugă un strat suplimentar de tabele de pagini. PSE evită acest strat prin utilizarea a 4 biți rezervați în tabelele de pagini pentru a specifica biții de nivel înalt. Cu toate acestea, ca urmare, dimensiunea paginii este limitată la 2M pentru paginile care se mapează >4GB . –  > Por Morty.
rwong

Site-ul articolul din Wikipedia despre EPIC a subliniat deja numeroasele pericole comune la VLIW și EPIC.

Dacă cineva nu prinde sentimentul de fatalism din acel articol, permiteți-mi să subliniez acest lucru:

Răspunsurile de încărcare de la o ierarhie de memorie care include memoria cache a CPU și DRAM nu au o întârziere deterministă.

Cu alte cuvinte, orice proiect hardware care nu reușește să facă față (*) latenței nedeterministe din accesul la memorie va deveni pur și simplu un eșec spectaculos.

(*) Prin „a face față”, este necesar să se obțină performanțe de execuție rezonabil de bune (cu alte cuvinte, „competitive din punct de vedere al costurilor”), ceea ce necesită să nu se lase CPU-ul să cadă în inactivitate pentru zeci sau sute de cicluri din când în când.

Rețineți că strategia de coping folosită de EPIC (menționată în articolul din Wikipedia legat mai sus) nu rezolvă de fapt problema. Ea spune doar că sarcina de a indica dependența de date cade acum în sarcina compilatorului. Este în regulă; compilatorul are deja aceste informații, deci este simplu pentru compilator să se conformeze. Problema este că unitatea centrală de procesare va rămâne în continuare inactivă timp de zeci sau sute de cicluri pentru un acces la memorie. Cu alte cuvinte, acesta externalizează o responsabilitate secundară, în timp ce nu reușește să facă față responsabilității principale.

Întrebarea poate fi reformulată astfel: „Având în vedere o platformă hardware care este destinată să fie un eșec, de ce (1) nu (2) nu au putut scriitorii compilatorului să facă un efort eroic pentru a o răscumpăra?”

Sper că reformularea mea va face ca răspunsul la această întrebare să fie evident.


Există un al doilea aspect al eșecului care este, de asemenea, fatal.

Strategiile de rezolvare (menționate în același articol) presupun că prefetching-ul bazat pe software poate fi utilizat pentru a recupera cel puțin o parte din pierderea de performanță datorată latenței nedeterministe din accesul la memorie.

În realitate, prefetching-ul este profitabil doar dacă efectuați operațiuni de streaming (citirea memoriei într-un mod secvențial sau foarte previzibil).

(Acestea fiind spuse, dacă codul dvs. face acces frecvent la unele zone de memorie localizate, memoria cache va fi de ajutor).

Cu toate acestea, majoritatea programelor software de uz general trebuie să efectueze o mulțime de accesări aleatorii ale memoriei. Dacă luăm în considerare următorii pași:

  • Calculați adresa și apoi
  • Citiți valoarea și apoi
  • Utilizați-o în anumite calcule

În cazul majorității programelor de uz general, cele trei trebuie să fie executate în succesiune rapidă. Cu alte cuvinte, nu este întotdeauna posibil (în limitele logicii software-ului) să se calculeze adresa în avans sau să se găsească suficient de multe lucruri de făcut pentru a umple intervalul dintre aceste trei etape.

Pentru a explica de ce nu este întotdeauna posibil să se găsească suficientă muncă pentru a umple spațiile de lucru, iată cum se poate vizualiza situația.

  • Să spunem că, pentru a ascunde în mod eficient blocajele, trebuie să umplem 100 de instrucțiuni care nu depind de memorie (deci nu vor suferi de latență suplimentară).
  • Acum, în calitate de programator, vă rugăm să încărcați orice software la alegere într-un dezasamblorator. Alegeți o funcție aleatorie pentru analiză.
  • Puteți identifica undeva o secvență de 100 de instrucțiuni (*) care să fie exclusiv fără acces la memorie?

(*) Dacă am putea face vreodată NOP să facă o muncă utilă …


Unitățile centrale de procesare moderne încearcă să facă față cu ajutorul informațiilor dinamice – prin urmărirea concomitentă a progresului fiecărei instrucțiuni pe măsură ce circulă prin conducte. După cum am menționat mai sus, o parte din aceste informații dinamice se datorează latenței nedeterministe a memoriei, prin urmare, nu pot fi prezise cu un anumit grad de precizie de către compilatoare. În general, pur și simplu nu există suficiente informații disponibile în momentul compilării pentru a lua decizii care ar putea eventual să umple aceste blocaje.


Ca răspuns la răspunsul lui AProgrammer

Nu este vorba că „compilatorul … extragerea paralelismului este dificilă”.

Reordonarea instrucțiunilor de memorie și aritmetice de către compilatoarele moderne este dovada că nu are nicio problemă în a identifica operațiile care sunt executabile independent și, prin urmare, concomitent.

Principala problemă este că latența nedeterministă a memoriei înseamnă că orice „pereche de instrucțiuni” codificată pentru procesorul VLIW/EPIC va sfârși prin a fi blocată de accesul la memorie.

Optimizarea instrucțiunilor care nu se blochează (numai registru, aritmetică) nu va ajuta la rezolvarea problemelor de performanță cauzate de instrucțiunile care au o mare probabilitate de a se bloca (acces la memorie).

Acesta este un exemplu de neaplicare a regulii 80-20 a optimizării: Optimizarea lucrurilor care sunt deja rapide nu va îmbunătăți în mod semnificativ performanța generală, cu excepția cazului în care sunt optimizate și lucrurile mai lente.


Ca răspuns la răspunsul lui Basile Starynkevitch

Nu este vorba de „… (orice) este greu”, ci de faptul că EPIC este nepotrivit pentru orice platformă care trebuie să facă față unui dinamism ridicat în ceea ce privește latența.

De exemplu, dacă un procesor are toate următoarele:

  • Nu are acces direct la memorie;
    • Orice acces la memorie (citire sau scriere) trebuie să fie programat prin transfer DMA;
  • fiecare instrucțiune are aceeași latență de execuție;
  • execuție în ordine;
  • Unități de execuție largi / vectorizate;

Atunci VLIW/EPIC se potrivește perfect.

Unde se pot găsi astfel de procesoare? DSP. Și aici este locul în care VLIW a înflorit.


Privind retrospectiv, eșecul Itanium (și vărsarea continuă a eforturilor de cercetare și dezvoltare într-un eșec, în ciuda dovezilor evidente) este un exemplu de eșec organizațional și merită să fie studiat în profunzime.

De acord, celelalte proiecte ale furnizorului, cum ar fi hyperthreading, SIMD etc., par să aibă un mare succes. Este posibil ca investiția în Itanium să fi avut un efect de îmbogățire a competențelor inginerilor săi, ceea ce le-ar fi permis să creeze următoarea generație de tehnologie de succes.

Comentarii

  • Prin prezenta mă distanțez de acest răspuns vechi. La momentul respectiv nu am cunoștințe istorice reale despre tehnologia compilatorului Itanium. Răspunsul meu se baza pe opinia mea (naivă) care, la rândul ei, se baza pe dezasamblarea x86 pe care o citesc zilnic. Nu am citit niciodată o singură piesă de dezasamblare Itanium. Prin urmare, răspunsul meu trebuie tratat cu scepticism. Majoritatea cititorilor ar trebui să ignore răspunsul meu în întregime. –  > Por rwong.
AProgramator

TL;DR: 1/ există și alte aspecte în eșecul Itanium decât problemele legate de compilator și este foarte posibil ca acestea să fie suficiente pentru a-l explica; 2/ un cod de octeți nu ar fi rezolvat problemele legate de compilator.

Se afirmă în mod obișnuit că arhitectura procesorului Intel Itanium pe 64 de biți a eșuat deoarece revoluționarul set de instrucțiuni EPIC era foarte dificil de scris un compilator bun pentru acesta

Ei bine, au întârziat și ei (planificat pentru 98, prima livrare în 2001), iar când au livrat în sfârșit hardware-ul, nu sunt sigur nici măcar că a livrat ceea ce a fost promis pentru data anterioară (IIRC, au renunțat cel puțin la o parte din emulația x86 care a fost planificată inițial), așa că nu sunt sigur că, chiar dacă problemele de compilare ar fi fost rezolvate (și AFAIK, nu a fost încă), ar fi reușit. Aspectul compilatorului nu a fost singurul aspect care a fost prea ambițios.

Există vreun motiv pentru care Intel nu a specificat un limbaj „bytecode Itanium simplu” și nu a furnizat un instrument care să convertească acest bytecode în cod EPIC optimizat, valorificând expertiza lor ca oameni care au proiectat sistemul în primul rând?

Nu sunt sigur unde plasați instrumentul.

Dacă este în procesor, aveți doar o altă microarhitectură și nu există niciun motiv pentru a nu folosi x86 ca ISA public (cel puțin pentru Intel, incompatibilitatea are un cost mai mare decât orice ar putea aduce un ISA public mai curat).

În cazul în care este extern, pornind de la un cod de octeți, este chiar mai greu decât pornind de la un limbaj de nivel superior. Problema cu EPIC este că poate folosi doar paralelismul pe care un compilator îl poate găsi, iar extragerea acestui paralelism este dificilă. Cunoașterea regulilor limbajului vă oferă mai multe posibilități decât dacă sunteți constrâns de ceva deja programat. Amintirea mea (recunoscută ca fiind nesigură și provenind de la cineva care a urmărit asta de departe) este că ceea ce HP(*) și Intel nu au reușit să realizeze în ceea ce privește compilatorul este extragerea paralelismului la nivel de limbaj, nu la nivel scăzut, care ar fi fost prezent într-un cod de octeți.

Poate că subestimați costul cu care procesoarele actuale își obțin performanțele. OOO este mai eficient decât celelalte posibilități, dar cu siguranță nu este eficient. EPIC a vrut să folosească bugetul de suprafață utilizat de implementarea OOO pentru a oferi mai mult calcul brut, în speranța că compilatoarele vor fi capabile să se folosească de el. După cum s-a scris mai sus, nu numai că nu suntem încă în imposibilitatea – după cum AFAIK, nici măcar în teorie – de a scrie compilatoare care să aibă această capacitate, dar Itanium a primit suficient de multe alte caracteristici greu de implementat încât a întârziat, iar puterea sa brută nu era nici măcar competitivă (cu excepția, poate, a unor piețe de nișă cu mult calcul FP) cu celelalte procesoare de vârf atunci când a ieșit din fabrică.


(*) De asemenea, se pare că subestimați rolul HP în EPIC.

Comentarii

  • Mi-am actualizat răspunsul ca răspuns la una dintre afirmațiile dumneavoastră. În opinia mea, eșecul de a face față latenței memoriei este singura cauză a morții arhitecturii EPIC. Compilatoarele au un succes decent în extragerea paralelismului la nivel de instrucțiuni, la fel ca și hardware-ul procesoarelor moderne. –  > Por rwong.
  • @rwong, am făcut un TLDR a ceea ce consider că sunt punctele mele principale. BTW, pentru mine, latența variabilă – între modele, date dependente pentru anumite instrucțiuni în anumite modele, accesul la memorie este evident o categorie majoră aici – este un aspect al dificultății de extragere a paralelismului. Hardware-ul CPU are avantajul programării dinamice, și nu cred că există un exemplu de procesor programat static care să fie competitiv la performanța pură pentru un singur fir cu OOO. Nu cred că nici măcar echipa Mill nu face această afirmație (factorul lor de merit include puterea). –  > Por AProgrammer.
Lexi

Câteva lucruri.

IPF a fost în ordine, pentru început. Acest lucru însemna că nu te puteai baza pe reordonare pentru a te salva în cazul unei ratări a memoriei cache sau a unui alt eveniment de lungă durată. Ca urmare, ați ajuns să trebuiască să vă bazați pe caracteristici speculative – și anume, sarcini speculative (sarcini care puteau eșua – utile dacă nu știați dacă veți avea nevoie de un rezultat al încărcării) și sarcini avansate (sarcini care puteau fi rulate din nou, folosind codul de recuperare, în cazul în care apărea un pericol.) Atingerea corectă a acestora a fost dificilă, în special a sarcinilor avansate! Existau, de asemenea, indicii de ramificație și de prefetch cache care puteau fi utilizate în mod inteligent doar de către un programator de asamblare sau folosind optimizarea ghidată de profil, nu în general cu un compilator tradițional.

Alte mașini de la acea vreme – și anume UltraSPARC – erau în ordine, dar IPF avea și alte considerente. Una dintre ele era spațiul de codificare. Instrucțiunile Itanium nu erau, prin natura lor, deosebit de dense – un pachet de 128 de biți conținea trei operații și un câmp de șablon de 5 biți, care descria operațiile din pachet și dacă acestea puteau fi emise toate împreună. Acest lucru a dus la o dimensiune efectivă a operației de 42,6 biți – în comparație cu 32 de biți pentru majoritatea operațiilor RISC-urilor comerciale de la acea vreme. (Aceasta a fost înainte de Thumb2, et al – RISC încă însemna rigiditate de lungime fixă.) Chiar mai rău, nu aveai întotdeauna suficient ILP pentru a se potrivi cu șablonul pe care îl foloseai – așa că trebuia să faci NOP-pad pentru a completa șablonul sau pachetul. Acest lucru, combinat cu densitatea relativ scăzută existentă, a însemnat că obținerea unei rate de accesare decente a i-cache-ului era a) foarte importantă și b) dificilă – mai ales că I2 avea doar un L1I de 16KB (deși era destul de rapid.)

În timp ce am simțit întotdeauna că argumentul „compilatorul a fost singura și unica problemă” a fost exagerat – au existat probleme legitime de microarhitectură care într-adevăr nu au făcut I2 favoruri pentru codul de uz general – nu a fost deosebit de distractiv să generezi cod pentru acesta în comparație cu mașinile OoO mai înguste și cu ceas mai mare din acea vreme. Atunci când puteai să o umpli cu adevărat în mod corespunzător, ceea ce implica adesea fie PGO, fie codare manuală, se descurca grozav – dar în mare parte din timp, performanța din compilatoare era într-adevăr neinspirată. IPF nu a facilitat generarea unui cod excelent și era neiertător atunci când codul nu era excelent.

Dan T.

Ceea ce a ucis Itanium au fost întârzierile de livrare care au deschis ușa pentru AMD64 înainte ca furnizorii de software să se angajeze să migreze la IA64 pentru aplicațiile pe 64 de biți.

Să lăsăm optimizarea în seama compilatorului a fost o idee bună. O mulțime de lucruri pot fi făcute static, care altfel ar fi ineficiente în hardware. Compilatoarele au devenit destul de bune în acest sens, în special atunci când se folosea profilarea PGO (am lucrat la HP, iar compilatorul HP avea tendința de a fi mai performant decât cel al Intel). PGO a fost totuși greu de vândut, este un proces dificil pentru codul de producție.

IPF trebuia să fie compatibil cu trecutul, dar odată cu lansarea AMD64 a devenit discutabil, bătălia a fost pierdută și cred că hardware-ul X86 din CPU a fost pur și simplu dezbrăcat pentru a fi reorientat ca CPU de server. itanium ca arhitectură nu a fost rău, cele 3 instrucțiuni pe cuvânt nu au fost o problemă. Ceea ce a fost o problemă este implementarea hyper-threading prin swapping stack-uri în timpul IO de memorie a fost prea lentă (pentru a goli și reîncărca pipeline-ul) până la Montecito etc., ceea ce a împiedicat-o să concureze împotriva CPU-urilor PowerPC out-of-order. Compilatorii au trebuit să remedieze defectele de implementare a CPU-urilor detectate târziu, iar o parte din avantajul de performanță a fost pierdut din cauza unor greșeli greu de prevăzut.

Arhitectura a permis ca Itanium să fie relativ simplu, oferind în același timp instrumente pentru compilator pentru a obține performanțe din el. Dacă platforma ar fi supraviețuit, procesoarele ar fi devenit mai complexe și, în cele din urmă, ar fi devenit cu fire, fără ordine etc., ca x86. Cu toate acestea, primele generații s-au concentrat asupra numărului de tranzistori și asupra altor scheme de performanță, deoarece compilatorul se ocupa de o mare parte din lucrurile dificile.

Platforma IPF a mizat pe compilator și pe instrumente și a fost prima arhitectură care a expus un proiect de unitate de monitorizare a performanțelor (PMU) extrem de complet și puternic, care a fost ulterior portat înapoi la Intel x86. Dezvoltatorii de instrumente atât de puternice încă nu le folosesc la capacitatea lor deplină de a face profilul codului.

Dacă vă uitați la succesele ISA, de multe ori nu partea tehnică este cea care aruncă zarurile. Este locul său în timp și forțele pieței. Uitați-vă la SGI Mips, DEC Alpha… Itanium a fost susținut doar de cei care au pierdut, SGI & serverele HP, companii cu manageri care au acumulat greșeli strategice de afaceri. Microsoft nu a fost niciodată pe deplin implicată și a îmbrățișat AMD64 pentru a nu fi încadrată doar de Intel ca jucător, iar Intel nu a jucat corect cu AMD pentru a le oferi o modalitate de a trăi în ecosistem, deoarece intenționa să elimine AMD.

Dacă ne uităm unde ne aflăm astăzi, hardware-ul complex al lui X86 l-a condus până acum într-o fundătură a evoluției. Suntem blocați la 3+GHz și aruncăm nuclee care nu sunt suficient de utile. Designul mai simplu al lui Itanium ar fi impus mai multe lucruri pe compilator (spațiu de creștere), permițând construirea de pipeline-uri mai subțiri și mai rapide. La aceeași generație și tehnologie de fabricare, ar fi funcționat mai repede și ar fi fost limitat la fel, dar puțin mai sus, cu poate alte uși de deschis pentru a împinge legea lui Moore.

Ei bine, cel puțin cele de mai sus sunt convingerile mele 🙂

Basile Starynkevitch

Dar de ce a fost chestia cu compilatorul o problemă tehnică atât de dificilă? Mi se pare că, dacă paralelismul explicit din EPIC era dificil de implementat pentru furnizorii de compilatoare… de ce să le pună această povară în primul rând? Nu e ca și cum nu exista deja o soluție bună și bine înțeleasă la această problemă: puneți această sarcină pe seama Intel și oferiți compilatorilor o țintă mai simplă.

Ceea ce descrieți dvs. este un pic ceea ce Transmeta a încercat să facă cu software-ul lor de transformare a codului (care traducea dinamic „bytecode” x86 în cod mașină intern Transmeta).

În ceea ce privește motivul pentru care Intel nu a reușit să realizeze un compilator suficient de bun pentru IA64… cred că este că nu au avut suficient expertiză în compilare în cadrul companiei (chiar dacă, desigur, au avut unele foarte buni experți în compilatoare în interior, dar probabil nu suficient pentru a crea o masă critică). Cred că managementul lor a subestimat eforturile necesare pentru a realiza un compilator.

După părerea mea, Intel EPIC a eșuat pentru că compilarea pentru EPIC este foarte dificilă și, de asemenea, pentru că atunci când tehnologia de compilare s-a îmbunătățit încet și treptat, alți concurenți au reușit, de asemenea, să își îmbunătățească compilatorul (de exemplu, pentru AMD64), împărtășind o parte din know-how-ul de compilare.

BTW, mi-aș fi dorit ca AMD64 să fi avut un set de instrucțiuni mai RISCy. Ar fi putut fi ceva de genul POWERPC64 (dar probabil că nu a fost așa din cauza problemelor legate de brevete, din cauza cerințelor Microsoft la acea vreme, etc…). Arhitectura setului de instrucțiuni x86-64 nu este într-adevăr o arhitectură „foarte bună” pentru scriitorul de compilatoare (dar este cumva „suficient de bună”).

De asemenea, arhitectura IA64 are încorporate unele limitări puternice, de exemplu, cele 3 instrucțiuni/cuvânt au fost bune atâta timp cât procesorul avea 3 unități funcționale pentru a le procesa, dar odată ce Intel a trecut la noile cipuri IA64, a adăugat mai multe unități funcționale, iar paralelismul la nivel de instrucțiuni a fost din nou greu de realizat.

Poate că RISC-V (care este un ISA cu sursă deschisă) va reuși treptat suficient de bine pentru a-l face competitiv față de alte procesoare.

Comentarii

  • Cheltuielile Intel miliarde de euro pe cercetare și dezvoltare, îmi vine greu să cred că le-ar fi greu să dezvolte un compilator bun pentru o nouă platformă hardware. – user22815
  • Banii nu sunt totul: a se vedea luna omului mitic, nici un glonț de argint și să se ia în considerare, de asemenea, faptul că timpul de introducere pe piață este foarte important. –  > Por Basile Starynkevitch.
  • Ei angajează mulți ingineri și informaticieni talentați. Compilatoarele lor non-VLIW sunt de top, producând în mod regulat cod mult mai rapid decât alte compilatoare. Intel sunt probabil cei mai singurul companie care are mai multă expertiză internă în materie de compilatoare decât orice altă companie. Intel reușește în tot ceea ce face: de ce a fost Itanium un albatros? – user22815
  • Probabil că a fost puțin mai puțin adevărat în 1997. Și, după cum au explicat mai mulți, compilarea EPIC este foarte dificilă. –  > Por Basile Starynkevitch.
James Anderson

După cum a subliniat Robert Munn – lipsa compatibilității retroactive a fost cea care a ucis Itanium ( și multe alte tehnologii „noi”).

În timp ce scrierea unui nou compilator ar fi putut fi dificilă, aveți nevoie doar de câteva dintre ele. Un compilator C care produce cod optimizat este o necesitate — altfel nu veți avea un sistem de operare utilizabil. Aveți nevoie de un compilator C++, Java și, având în vedere că principala bază de utilizatori ar fi Windows, un fel de Visual Basic. Așadar, acest lucru nu a reprezentat o problemă. Exista un sistem de operare decent (NT) și un compilator C bun.

Ceea ce ar părea un efort banal pentru o companie care oferă un produs software – recompilarea și retestarea bazei de cod C (și la acea vreme majoritatea ar fi fost scrisă în C pur!) nu a fost atât de simplu; convertirea unui set mare de programe C care presupunea un întreg de 32 de biți și presupunea o adresare pe 32 de biți la o arhitectură nativă de 64 de biți era plină de capcane. Dacă IA64 ar fi devenit un cip dominant (sau chiar unul popular!), majoritatea companiilor de software ar fi mușcat glonțul și ar fi făcut acest efort.

Așadar, un cip rapid, cu un sistem de operare rezonabil, dar cu un set foarte limitat de software disponibil, prin urmare, nu mulți oameni l-au cumpărat, prin urmare, nu multe companii de software au oferit produse pentru el.

chx

Itanium a fost anunțat la în 1997 (sub numele de Merced la vremea respectivă), dar nu a fost livrat până în 2000, ceea ce l-a condamnat în cele din urmă, într-adevăr.

Motivul real al acestui eșec epic a fost fenomenul numit „prea mult investit pentru a renunța” (a se vedea și Licitația de dolari) cu o doză de efectul Osborne.

Povestea noastră începe cu adevărat în 1990 (!). HP încearcă să răspundă la întrebarea: ce urmează după PA-RISC? Ei au început un proiect de cercetare vizionar folosind personal și IP de la două companii VLIW notabile din anii ’80 (Cydrome și Multiflow — Multiflow Trace este btw răspunsul negativ pus în titlu, a fost un compilator VLIW de succes), acesta a fost Precision Architecture Wide-Word. În 1993 decid că merită să o dezvolte într-un produs și caută un partener de producție de semiconductori, iar în 1994 anunță parteneriatul cu Intel. Acesta este încă deloc evident că x86 va învinge totul, de exemplu, DEC Alpha AXP părea mult mai mult viitorul high-end.

Ei vor continua dezvoltarea și vor anunța EPIC în 1997 la Microprocessor Forum, dar ISA-ul nu va fi lansat până în februarie 1999, ceea ce face imposibilă crearea de instrumente pentru acesta înainte. Catastrofa lovește în octombrie 1999, când AMD anunță x86-64. Cu echipa de proiectare a cipurilor Alpha de la AMD, Athlon a demonstrat deja capacitatea lor de a crea performanțe competitive, iar x86-64 le ia avantajul celor 64 de biți. Deși propriul Pentium 4 nu era încă public, acesta a arătat, de asemenea, cât de departe poate ajunge x86 în ceea ce privește performanța. Pentru a înrăutăți lucrurile, McKinley a fost anunțat în 1998, cu o dată de livrare în 2001 și, după cum se arată în acest ZDNet articol din martie 1999 menționează „Word on the street sugerează că Merced va fi mai degrabă o platformă de dezvoltare cu puține livrări comerciale – majoritatea vor aștepta McKinley”.

Ce facem în acest moment? HP se ocupă de acest lucru din 1988, când a achiziționat Cydrome IP și i-a angajat pe Bob Rau și Michael Schlansker de la această companie atunci când aceasta s-a prăbușit (a se vedea Contextul istoric al arhitecturilor cu set de instrucțiuni EPIC și EPIC: O arhitectură pentru procesoare paralele la nivel de instrucțiuni ). Oare renunță pur și simplu la un proiect de peste zece ani și de mai multe miliarde de euro pentru că este vizibil prea târziu?

Mai târziu, alimentând și mai mult efectul Osborne, la începutul anului 2002, după ce vânzările de Itanium au avut un început lent se puteau citi analiști spunând: „O problemă este că McKinley… este scump de fabricat. Înseamnă, de asemenea, că randamentele sunt mai mici … Abia după ce se ajunge la Madison și Deerfield, în 2003, începe să se vorbească despre volum”. — deci, acolo unde oamenii au fost înșirați din 1998 până în 2002 să aștepte McKinley, acum, când a sosit anul McKinley, li s-a spus: „Așteptați, e prea scump, e prea scump, nu se mai poate face nimic”. următorul va fi mai bun, sau dacă nu, atunci cel de după. Dar Opteron a fost lansat cu două luni înainte de Madison și aproximativ acolo ar fi trebuit să se termine toată această șaradă.

gnasher729

Memoria devine vagă… Itanium a avut câteva idei grozave care ar avea nevoie de un suport mare de compilator. Problema era că nu era o singură caracteristică, ci mai multe. Fiecare dintre ele nu era mare lucru, toate împreună erau.

De exemplu, a existat o funcție de buclă în care o iterație a buclei ar opera pe registre din diferite iterații. x86 rezolvă aceeași problemă prin capacitatea masivă de ieșire din ordine.

La acea vreme, Java și JVM-urile erau la modă. IBM a spus că, cu PowerPC, puteai să compilezi rapid codul byte, iar procesorul îl va face rapid. Nu și pe Itanium.

Douglas Bell
  1. Compilatoarele au acces la informații de optimizare pe care hardware-ul OOO nu le va avea în momentul rulării, dar hardware-ul OOO are acces la informații care nu sunt disponibile compilatorului, cum ar fi costurile de latență de memorie neprevăzute. Optimizările hardware OOO au reușit să se lupte la egalitate cu optimizările compilatorului EPIC pe suficiente sarcini încât avantajul principal al EPIC nu a fost un câștigător clar. http://www.cs.virginia.edu/~skadron/cs654/cs654_01/slides/ting.ppt

  2. Pachetele de instrucțiuni VLIW ale Itanium au crescut frecvent dimensiunea codului cu un factor de 3 până la 6 în comparație cu CISC, în special în cazurile în care compilatorul nu a putut găsi paralelism.
    Acest lucru a consumat din lățimea de bandă de memorie disponibilă, care devenea o resursă din ce în ce mai limitată în momentul lansării Itanium. http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf

  3. Pachetele de instrucțiuni VLIW ale Itanium ofereau execuție speculativă pentru a evita costurile de predicție a ramurilor eșuate, dar practica de a executa calcule care erau eliminate în cea mai mare parte a timpului a consumat din bugetul de energie al procesorului, care devenea o resursă din ce în ce mai limitată la momentul lansării Itanium.

  4. A fost dificil să se realizeze un singur binar care să funcționeze în mod optim pe mai multe generații de procesoare Itanium. Acest lucru a reprezentat o provocare pentru furnizorii de software „shrink wrapped” și a crescut costul/riscul actualizării unei platforme Itanium la generația curentă.

  5. Itanium nu a atins niciodată avantajul preț/performanță necesar pentru a depăși „inerția platformei”, deoarece a fost amânat frecvent pentru a compensa problemele 1-4.

  6. Itanium nu a atins niciodată economia de scară pe care x86 & x64 a reușit să o valorifice pentru a reduce costurile de cercetare și dezvoltare pe unitate din cauza problemei 5.