Perché è stato difficile scrivere un compilatore per il processore Itanium?

È comunemente affermato che l'architettura del processore Intel Itanium a 64 bit non è riuscita perché il set di istruzioni EPIC rivoluzionario è stato molto difficile da scrivere un buon compilatore, il che significava la mancanza di buoni strumenti di sviluppo per IA64, il che significava una mancanza di sviluppatori che creavano programmi per l'architettura , e quindi nessuno voleva usare l'hardware senza molto software per esso, e quindi la piattaforma fallì, e tutto per mancanza diun chiodo a ferro di cavallo buoni compilatori.

Ma perché il compilatore era un problema tecnico così difficile? Mi sembra che se il parallelismo esplicito in EPIC fosse difficile da implementare per i venditori di compilatori ... perché mettere questo onere su di loro in primo luogo? Non è come una buona soluzione ben compresa a questo problema non esistesse già: metti invece quel fardello su Intel e dai agli autori di compilatori un obiettivo più semplice.

Itanium è uscito nel 1997. A questo punto, il sistema bytecode UCSD P-Code aveva quasi 20 anni, la macchina Z era leggermente più giovane e la JVM era la nuova stella nascente nel mondo dei linguaggi di programmazione. C'è qualche motivo per cui Intel non ha specificato un linguaggio "semplice bytecode Itanium" e non ha fornito uno strumento che converte questo bytecode in codice EPIC ottimizzato, sfruttando la loro esperienza come persone che hanno progettato il sistema in primo luogo?

Come ricordo all'epoca, il problema non riguardava solo i dettagli di IA64, ma era la competizione con il set di istruzioni x86-64 di AMD. Rendendo la loro architettura retrocompatibile con il set di istruzioni x86, AMD è stata in grado di sfruttare gli strumenti esistenti e i set di abilità degli sviluppatori. La mossa di AMD ebbe un tale successo che Intel (e Via) furono essenzialmente costretti ad adottare l'architettura x86-64.

La grande barriera all'epoca era di 4 GB di RAM sui PC desktop (più realisticamente ~ 3,4 GB utilizzabili su Windows). x86-64 ha infranto quella barriera e ha aperto la potenza di calcolo più elevata a tutti. Se AMD non avesse mai trovato x86-64, sono sicuro che Intel sarebbe stata contenta di avere tutti coloro che volevano saltare a 4 GB + RAM pagando un grosso premio per anni per quel privilegio. Dimostrando quanto lentamente si muovono i mercati, ci sono voluti anni perché le applicazioni raggiungessero una programmazione multi-thread a 64 bit, e anche adesso 4 GB di RAM sono standard sui PC di fascia bassa.

In breve, Intel ha provato a fare un salto rivoluzionario con l'architettura IA64 e AMD ha fatto un passo evolutivo con x86-64. In un mercato consolidato, i passaggi evolutivi che consentono ai knowledge worker di sfruttare le competenze esistenti vinceranno su passaggi rivoluzionari che richiedono a tutti di acquisire nuove competenze. Indipendentemente dalle differenze qualitative tra le architetture, IA64 non ha potuto superare lo slancio della propria piattaforma x86 una volta che AMD ha aggiunto le estensioni x86-64.

Non compro la spiegazione per la quale IA64 era troppo difficile da programmare. Era solo difficile rispetto alle alternative. Il punto di @ delnan sull'IR di basso livello è perfetto, non penso che avrebbe fatto la differenza.

Quanto al motivo per cui Intel non ha provato a farsi carico di questo peso, chi lo sa? All'epoca erano il potere di mercato. AMD rappresentava una minaccia, ma Intel era il re della collina. Forse hanno pensato che IA64 sarebbe stato molto meglio di qualsiasi altra cosa che avrebbero potuto spostare l'intero mercato. Forse stavano cercando di ottenere un livello premium e lasciare AMD, VIA, ecc. Nel secondo livello, combattendo su hardware di fascia bassa, una strategia che sia Intel che Apple hanno impiegato con successo.

Itanium è stato un tentativo deliberato di creare una piattaforma premium ed estrarre il tappeto da AMD, VIA, ecc.? Certo, funziona così.

L' articolo di Wikipedia su EPIC ha già delineato i molti pericoli comuni a VLIW ed EPIC.

Se qualcuno non cattura il senso di fatalismo da quell'articolo, vorrei evidenziarlo:

Le risposte di caricamento da una gerarchia di memoria che include cache della CPU e DRAM non hanno un ritardo deterministico.

In altre parole, qualsiasi progetto hardware che non riesce a far fronte (*) alla latenza non deterministica dall'accesso alla memoria diventerà semplicemente un fallimento spettacolare.

(*) "Affrontando", è necessario ottenere prestazioni di esecuzione ragionevolmente buone (in altre parole "competitive in termini di costi"), il che richiede di non lasciare la CPU inattiva per decine o centinaia di cicli così spesso.

Si noti che la strategia di coping adottata da EPIC (menzionata nell'articolo Wikipedia collegato sopra) non risolve effettivamente il problema. Dice semplicemente che l'onere di indicare la dipendenza dei dati ora ricade sul compilatore. Va bene; il compilatore dispone già di tali informazioni, quindi è semplice che il compilatore si conformi. Il problema è che la CPU resterà inattiva per decine o centinaia di cicli su un accesso alla memoria. In altre parole, esternalizza una responsabilità secondaria, pur non riuscendo a far fronte alla responsabilità primaria.

La domanda può essere riformulata come: "Data una piattaforma hardware destinata a fallire, perché (1) non (2) gli autori del compilatore non hanno potuto fare uno sforzo eroico per riscattarla?"

Spero che la mia riformulazione renderà ovvia la risposta a questa domanda.

C'è un secondo aspetto del fallimento che è anche fatale.

Le strategie di coping (menzionate nello stesso articolo) presuppongono che il prefetching basato su software possa essere utilizzato per recuperare almeno parte della perdita di prestazioni dovuta alla latenza non deterministica dall'accesso alla memoria.

In realtà, il prefetching è redditizio solo se si eseguono operazioni di streaming (lettura della memoria in modo sequenziale o altamente prevedibile).

(Detto questo, se il tuo codice accede frequentemente ad alcune aree di memoria localizzate, la memorizzazione nella cache ti aiuterà.)

Tuttavia, la maggior parte dei software per scopi generici deve effettuare numerosi accessi casuali alla memoria. Se consideriamo i seguenti passaggi:

• Calcola l'indirizzo e quindi
• Leggi il valore e quindi
• Usalo in alcuni calcoli

Per la maggior parte dei software generici, questi tre devono essere eseguiti in rapida successione. In altre parole, non è sempre possibile (entro i limiti della logica del software) calcolare l'indirizzo in anticipo o trovare abbastanza lavoro da fare per riempire le bancarelle tra questi tre passaggi.

Per aiutare a spiegare perché non è sempre possibile trovare abbastanza lavoro per riempire le bancarelle, ecco come è possibile visualizzarlo.

• Diciamo, per nascondere efficacemente le bancarelle, dobbiamo riempire 100 istruzioni che non dipendono dalla memoria (quindi non soffriranno di ulteriore latenza).
• Ora, come programmatore, caricare qualsiasi software di propria scelta in un disassemblatore. Scegli una funzione casuale per l'analisi.
• Riesci a identificare ovunque una sequenza di 100 istruzioni (*) che sono esclusivamente prive di accessi di memoria?

(*) Se potessimo mai NOPfare un lavoro utile ...

Le moderne CPU cercano di far fronte alle stesse informazioni dinamiche, monitorando contemporaneamente l'avanzamento di ciascuna istruzione mentre circolano attraverso le condutture. Come ho accennato in precedenza, parte di tali informazioni dinamiche è dovuta a una latenza di memoria non deterministica, pertanto non può essere prevista con precisione da alcun compilatore. In generale, al momento della compilazione non sono disponibili informazioni sufficienti per prendere decisioni che potrebbero riempire quelle bancarelle.

In risposta alla risposta di AProgrammer

Non è che "compilatore ... estrarre il parallelismo è difficile".

Il riordino della memoria e delle istruzioni aritmetiche da parte dei moderni compilatori è la prova che non ha problemi a identificare operazioni indipendenti e quindi eseguibili contemporaneamente.

Il problema principale è che la latenza di memoria non deterministica significa che qualsiasi "accoppiamento di istruzioni" codificato per il processore VLIW / EPIC finirà per essere bloccato dall'accesso alla memoria.

L'ottimizzazione delle istruzioni che non si bloccano (solo registro, aritmetica) non aiuterà con i problemi di prestazioni causati da istruzioni che molto probabilmente si fermeranno (accesso alla memoria).

È un esempio di mancata applicazione della regola di ottimizzazione 80-20: l'ottimizzazione delle cose che sono già veloci non migliorerà significativamente le prestazioni complessive, a meno che anche le cose più lente non vengano ottimizzate.

In risposta alla risposta di Basile Starynkevitch

Non è "... (qualunque cosa) sia difficile", è che EPIC non è adatto a qualsiasi piattaforma che deve affrontare un elevato dinamismo in latenza.

Ad esempio, se un processore ha tutte le seguenti caratteristiche:

• Nessun accesso diretto alla memoria;
  • Qualsiasi accesso alla memoria (lettura o scrittura) deve essere programmato tramite trasferimento DMA;
• Ogni istruzione ha la stessa latenza di esecuzione;
• Esecuzione in ordine;
• Unità di esecuzione ampie / vettoriali;

Quindi VLIW / EPIC andrà bene.

Dove si trovano tali processori? DSP. Ed è qui che VLIW è fiorito.

Con il senno di poi, il fallimento di Itanium (e il continuo riversamento dello sforzo di ricerca e sviluppo in un fallimento, nonostante l'evidenza evidente) è un esempio di fallimento organizzativo e merita di essere approfondito.

Certo, le altre iniziative del venditore, come hyperthreading, SIMD, ecc., Sembrano avere molto successo. È possibile che l'investimento in Itanium abbia avuto un effetto arricchente sulle capacità dei suoi ingegneri, il che potrebbe aver consentito loro di creare la prossima generazione di tecnologia di successo.

TL; DR: 1 / ci sono altri aspetti nel fallimento di Itanium oltre ai problemi del compilatore e potrebbero benissimo essere sufficienti a spiegarlo; 2 / un codice byte non avrebbe risolto i problemi del compilatore.

È comunemente affermato che l'architettura del processore Intel Itanium a 64 bit non è riuscita perché il set di istruzioni EPIC rivoluzionario è stato molto difficile scrivere un buon compilatore per

Bene, erano anche in ritardo (previsto per 98, prima spedizione nel 2001) e quando finalmente hanno consegnato l'hardware, non sono nemmeno sicuro che abbia consegnato ciò che era stato promesso per la data precedente (IIRC, almeno hanno lasciato cadere parte del emulazione x86 inizialmente prevista), quindi non sono sicuro che anche se i problemi di compilazione fossero stati risolti (e AFAIK, non è ancora stato risolto), avrebbero avuto successo. L'aspetto del compilatore non era l'unico aspetto troppo ambizioso.

C'è qualche ragione per cui Intel non ha specificato un linguaggio "semplice bytecode Itanium" e non ha fornito uno strumento che converte questo bytecode in codice EPIC ottimizzato, sfruttando la loro esperienza come persone che hanno progettato il sistema in primo luogo?

Non sono sicuro dove si posiziona lo strumento.

Se è nel processore, hai solo un'altra micro-architettura e non c'è motivo di non utilizzare x86 come ISA pubblico (almeno per Intel, l'incompatibilità ha un costo più elevato di qualsiasi cosa possa portare a un ISA pubblico più pulito).

Se è esternamente, partire da un codice byte lo rende ancora più difficile che partire da una lingua di livello superiore. Il problema con EPIC è che può usare solo il parallelismo che un compilatore può trovare ed estrarre quel parallelismo è difficile. Conoscere le regole della lingua ti dà più possibilità che se sei vincolato da qualcosa di già programmato. Il mio (ammesso inaffidabile e da qualcuno che l'ha seguito da lontano) è che ciò che HP (*) e Intel non sono riusciti a ottenere sul fronte del compilatore è l'estrazione del parallelismo a livello linguistico, non il livello basso che sarebbe stato presente in un byte codice.

Stai forse sottovalutando il costo a cui l'attuale processore raggiunge le sue prestazioni. OOO è più efficace delle altre possibilità, ma sicuramente non è efficiente. EPIC voleva utilizzare il budget di area utilizzato dall'implementazione di OOO per fornire più elaborazioni non elaborate, sperando che i compilatori fossero in grado di utilizzarlo. Come scritto sopra, non solo non siamo ancora in grado - come AFAIK, anche in teoria - di scrivere compilatori che hanno quella capacità, ma Itanium ha abbastanza altre funzionalità difficili da implementare che era tardi e la sua potenza grezza non lo era anche competitivo (tranne forse in alcuni mercati di nicchia con un sacco di calcolo FP) con l'altro processore di fascia alta quando è uscito da fab.

(*) Sembra anche sottovalutare il ruolo di HP in EPIC.

Poche cose.

IPF era in ordine, per uno. Ciò significava che non potevi fare affidamento sul riordino per salvarti in caso di mancanza di cache o altri eventi di lunga durata. Di conseguenza, alla fine è stato necessario fare affidamento su funzionalità speculative - vale a dire, carichi speculativi (carichi che potevano fallire - utili se non si sapeva se avresti avuto bisogno di un risultato di carico) e carichi avanzati (carichi che potrebbero essere riesegui, utilizzando il codice di ripristino, se si è verificato un pericolo.) Ottenere questi giusti era difficile, soprattutto i carichi avanzati! C'erano anche suggerimenti per il prefetch di branch e cache che potevano davvero essere usati in modo intelligente solo da un programmatore di assiemi o usando l'ottimizzazione guidata dal profilo, non generalmente con un compilatore tradizionale.

Altre macchine all'epoca - vale a dire UltraSPARC - erano in ordine, ma IPF aveva anche altre considerazioni. Uno stava codificando lo spazio. Le istruzioni Itanium per natura non erano particolarmente dense: un bundle a 128 bit conteneva tre operazioni e un campo template a 5 bit, che descriveva le operazioni nel bundle e se potevano emettere tutte insieme. Ciò ha consentito di ottenere una dimensione operativa di 42,6 bit: confrontarla con 32 bit per la maggior parte delle operazioni dei RISC commerciali dell'epoca. (Questo era prima di Thumb2, et al - RISC significava ancora rigidità a lunghezza fissa.) Ancora peggio, non si aveva sempre abbastanza ILP per adattarsi al modello che si stava usando - quindi si dovrebbe NOP-pad per compilare il modello o il pacchetto. Questo, combinato con l'attuale bassa densità relativa, ha significato che ottenere un tasso di successo della i-cache decente era a) molto importante,

Mentre ho sempre sentito che l'argomento "il compilatore era l'unico e unico problema" era esagerato - c'erano legittimi problemi microarchitetturali che in realtà non avevano alcun favore per il codice per scopi generici - non era particolarmente divertente generare codice a confronto alle macchine OoO più strette e con clock più alto del giorno. Quando hai potuto davvero riempirlo correttamente, che spesso comportava sia la PGO che la codifica manuale, ha funzionato benissimo - ma per la maggior parte del tempo, le prestazioni dei compilatori erano davvero poco interessanti. IPF non ha reso facile la generazione di ottimo codice, ed è stato spietato quando il codice non era eccezionale.

Ma perché il compilatore era un problema tecnico così difficile? Mi sembra che se il parallelismo esplicito in EPIC fosse difficile da implementare per i venditori di compilatori ... perché mettere questo onere su di loro in primo luogo? Non è come una buona soluzione ben compresa a questo problema non esistesse già: metti invece quel fardello su Intel e dai agli autori di compilatori un obiettivo più semplice.

Quello che descrivi è un po 'quello che Transmeta ha cercato di fare con il loro software di morphing del codice (che traduceva in modo dinamico "bytecode" x86 in codice macchina interno di Transmeta).

Quanto al perché Intel è riuscito a fare un buon compilatore sufficiente per IA64 ... immagino è che non avevano sufficiente esperienza compilatore a casa (anche se, naturalmente, hanno avuto alcuni ottimi esperti del compilatore interno, ma probabilmente non abbastanza per fare una massa critica). Immagino che la loro gestione abbia sottovalutato gli sforzi necessari per creare un compilatore.

AFAIK, Intel EPIC ha fallito perché la compilazione per EPIC è davvero difficile, e anche perché quando la tecnologia del compilatore è migliorata lentamente e gradualmente, altri concorrenti sono stati anche in grado di migliorare il proprio compilatore (ad esempio per AMD64), condividendo alcune conoscenze del compilatore.

A proposito, avrei voluto che AMD64 sarebbe stato un altro set di istruzioni RISCy. Potrebbe essere stato un po 'di POWERPC64 (ma probabilmente non era a causa di problemi di brevetto, a causa delle richieste di Microsoft in quel momento, ecc ...). L'architettura del set di istruzioni x86-64 non è in realtà un'architettura "molto buona" per lo scrittore di compilatori (ma è in qualche modo "abbastanza buona").

Anche l'architettura IA64 ha incorporato alcune forti limitazioni, ad esempio le 3 istruzioni / parola sono state buone fintanto che il processore aveva 3 unità funzionali per elaborarle, ma una volta che Intel è passata ai chip IA64 più recenti hanno aggiunto più unità funzionali e l'istruzione- il parallelismo di livello è stato ancora una volta difficile da raggiungere.

Forse RISC-V (che è un ISA open source) avrà gradualmente abbastanza successo da renderlo competitivo con altri processori.

Come ha sottolineato Robert Munn, è stata la mancanza di compatibilità con le versioni precedenti a uccidere Itanium (e molte altre "nuove" tecnologie).

Mentre scrivere un nuovo compilatore potrebbe essere stato difficile, ne hai bisogno solo alcuni. Il compilatore AC che produce un codice ottimizzato è un must, altrimenti non avrai un sistema operativo utilizzabile. Hai bisogno di un compilatore C ++, Java e dato che la base di utenti principale sarebbe Windows una sorta di Visual Basic. Quindi questo non è stato davvero un problema. C'era un sistema operativo decente (NT) e un buon compilatore C disponibile.

Quello che sembrerebbe uno sforzo insignificante per un'azienda che offre un prodotto software - ricompilare e ripetere il test della base di codice C (e in quel momento la maggior parte sarebbe stata scritta in puro C!) Non era così semplice; la conversione di un ampio set di programmi C che presupponeva un numero intero a 32 bit e supponeva che l'indirizzamento a 32 bit in un'architettura nativa a 64 bit fosse piena di insidie. Se IA64 fosse diventato un chip dominante (o anche popolare!) La maggior parte delle aziende di software avrebbe morso il proiettile e fatto lo sforzo.

Chip così veloce con un sistema operativo ragionevole ma un set di software molto limitato disponibile, quindi non molte persone lo hanno acquistato, quindi non molte società di software hanno fornito prodotti per questo.

Ciò che ha ucciso Itanium sono stati i ritardi nelle spedizioni che hanno aperto le porte a AMD64, prima che i produttori di software si impegnassero a migrare su IA64 per le app a 64 bit.

Lasciare l'ottimizzazione al compilatore è stata una buona idea. Si può fare un sacco di roba statica che altrimenti è inefficiente nell'hardware. I compilatori sono diventati abbastanza bravi a farlo, soprattutto quando si utilizzava la profilazione PGO (ho lavorato presso HP e il compilatore HP tendeva a superare quello di Intel). PGO è stata una vendita difficile, tuttavia è un processo difficile per il codice di produzione.

L'IPF doveva essere compatibile con le versioni precedenti, ma una volta lanciato AMD64 è diventato discutibile, la battaglia è andata perduta e credo che l'hardware X86 nella CPU sia stato appena rimosso per essere retarget come CPU server. Itanium come architettura non era male, le 3 istruzioni per parola non erano un problema. Ciò che rappresentava un problema era l'implementazione dell'hyper-threading che scambiava gli stack durante l'IO della memoria era troppo lento (per svuotare e ricaricare la pipeline) fino a Montecito ecc., Che gli impediva di competere contro CPU PowerPC fuori servizio. I compilatori hanno dovuto correggere in ritardo i difetti delle implementazioni della CPU e parte del vantaggio prestazionale è stato perso a causa di errori difficili da prevedere.

L'architettura ha permesso a Itanium di essere relativamente semplice fornendo allo stesso tempo strumenti per il compilatore per ottenere prestazioni da esso. Se la piattaforma fosse vissuta, le CPU sarebbero diventate più complesse, e alla fine sarebbero diventate thread, fuori servizio ecc. Come x86. Tuttavia, le prime ragazze si sono concentrate sul conteggio dei transistor su altri schemi di prestazioni poiché il compilatore ha gestito molte cose difficili.

La piattaforma IPF ha puntato sul compilatore e sugli strumenti ed è stata la prima architettura a esporre un design PMU (Performance Monitoring Unit) estremamente completo e potente, che è stato successivamente riportato su Intel x86. Gli sviluppatori di strumenti così potenti non lo usano ancora per la sua piena capacità di profilare il codice.

Se guardi ai successi dell'ISA, spesso non è il lato tecnico che lancia i dadi. È il suo posto nel tempo e nelle forze del mercato. Guarda SGI Mips, DEC Alpha ... Itanium è stato appena supportato da perdenti, server SGI e HP, aziende con gestioni che si sono accumulate su errori aziendali strategici. Microsoft non è mai stata full-in e ha abbracciato AMD64 per non essere inscatolata con Intel solo come giocatore, e Intel non ha giocato bene con AMD per dare loro un modo di vivere nell'ecosistema, poiché intendevano snuffare AMD.

Se guardi dove siamo oggi, il complesso hardware di X86 lo ha portato ad un vicolo cieco di evoluzione finora. Siamo bloccati a 3 + GHz e scarichiamo core con un uso insufficiente. Il design più semplice di Itanium avrebbe spinto più materiale sul compilatore (spazio per la crescita), consentendo di costruire condotte più sottili e veloci. Alla stessa generazione e tecnologia favolosa, avrebbe funzionato più velocemente e comunque limitato, ma un po 'più in alto, con forse altre porte da aprire per spingere la legge di Moore.

Beh, almeno quanto sopra è il mio credo :)

La memoria sta diventando vaga ... Itanium aveva alcune grandi idee che avrebbero avuto bisogno di un ottimo supporto per il compilatore. Il problema era che non era una caratteristica, erano molte. Ognuno non era un grosso problema, lo erano tutti insieme.

Ad esempio, c'era una funzione di looping in cui una iterazione del loop avrebbe funzionato su registri di diverse iterazioni. x86 gestisce lo stesso problema grazie a un'enorme capacità fuori servizio.

A quel tempo Java e JVM erano di moda. Quello che IBM ha detto è che con PowerPC, è possibile compilare rapidamente bytecode e la CPU lo renderebbe veloce. Non su Itanium.