di  -  lunedì 19 giugno 2017

Cari lettori, vi presento un altro articolo del nostro autore Nessuno. Buona lettura e grazie a Nessuno per il suo contributo.

1.0 I processi produttivi

Parlare di processi produttivi è sempre difficile perché è un argomento abbastanza complesso e molto ampio.
È diffusa la moda di discutere nei forum, anche in maniera minuziosa e pignola, solo dei nanometri che sono attribuiti ad un determinato processo produttivo senza sapere esattamente cosa questo valore indichi. Cercheremo in questo articolo di chiarire parte di quali siano le caratteristiche di un processo produttivo e come queste possono essere confrontate tra processi produttivi differenti, per quanto possibile. Ovviamente parleremo dei processi produttivi che permettono di costruire le GPU, i nostri prodotti finali che più ci appassionano.

Un processo produttivo (da qui in poi anche PP) usato per la costruzione di un chip (più precisamente definito come circuito integrato) è responsabile per buona parte delle caratteristiche e quindi delle limitazioni che questo possiede. Spesso si tende a pensare che un chip sia progettato anni prima indipendentemente dal PP per poi semplicemente adattare il layout (la trasposizione tra il modello teorico e quello fisico) quando il PP diventa disponibile.

In verità la progettazione di una architettura di un chip viene iniziata sì diversi anni prima, ma tenendo conto del processo produttivo (o processi produttivi) su cui si vuole realizzarla. Ovviamente per fare ciò è indispensabile che chi progetta sappia quali siano le caratteristiche fondamentali del PP anni prima che questo sia adottato per la produzione. Ecco perché si sente parlare di PP futuristici in prova diversi anni prima di vedere al supermercato prodotti realizzati con essi.

Ed ecco perché talvolta il prodotto finale non rispecchia quelle che erano le promesse fatte durante il suo sviluppo: non sempre alla fine dello sviluppo del processo produttivo, che è svolto parallelamente e indipendentemente dai prodotti che lo useranno, le sue caratteristiche (o quelle che erano state stimate dover essere quelle definitive) sono soddisfatte.

Tutto questo implica anche che una architettura nata per un determinato PP non sia semplice da adattare ad un altro, ma necessita un lavoro di revisione più profondo e costoso sia in termini economici che di tempo. E non sempre alla fine le caratteristiche del prodotto finale realizzato sono quelle ottimali.

Da anni quindi i produttori di GPU hanno adottato la consuetudine di creare nuove architetture, o revisioni di queste, ad ogni nuovo PP. Questa pratica permette di realizzare chip che meglio si adattano alle loro caratteristiche. In un mercato dove le prestazioni sono tutto per meglio competere, è fondamentale riuscire a sfruttare al meglio tutti i vantaggi che un PP più avanzato mette a disposizione e lo si fa progettando una architettura che ne sfrutti il più possibile i suoi vantaggi.
Vediamo quindi quali sono le caratteristiche proprie delle GPU che i nuovi processi produttivi possono migliorare.

2.0 GPU veloci… il limite dov’è?

Sappiamo che ogni nuova generazione di GPU produce un sensibile aumento delle prestazioni. Ci chiediamo ingenuamente qui perché è necessario progettare e investire in una nuova architettura con nuovi processi produttivi per ottenere maggiori prestazioni. Cosa impedisce di fare chip con la tecnologia che abbiamo oggi che siano veloci come quelli che si vorranno produrre tra 2 o 3 anni?

Ci concentreremo sui motivi specifici delle GPU , anche se molto di quanto viene detto vale anche per le normali CPU (o i SoC degli Smartphone). Vedremo che l’avanzamento permesso dai nuovi processi produttivi è necessario per diversi motivi: economici, energetici, pratici.

Consideriamo per un momento quanto detto negli scorsi articoli (parte prima, seconda, terza) riguardo al fatto che le GPU sono dispositivi altamente scalabili.
Ipoteticamente sarebbe possibile crearle grandi a piacere e quindi con prestazioni e consumi grandi a loro volta a piacere. Per esempio, voglio una GPU che va il doppio di un’altra, mi basta farla grande il doppio (raddoppiando le unità di calcolo presenti) o più semplicemente raddoppiandone la frequenza. E cosa ci impedisce di fare ancora la stessa cosa per creare una GPU ancora più veloce? E se la volessi ancora più veloce perché la concorrenza ne ha appena creata una migliore? Cosa ci impedisce di fare ciò infinite volte fino ad arrivare alla potenza di calcolo voluta (teoricamente infinita)?

Semplicemente i limiti della fisica o quelli dell’economia o quelli dell’ergonomia (o praticità) a seconda di quale interviene prima.
Tutti e tre validi in modi e pesi diversi a seconda del mercato a cui il prodotto si rivolge ma comunque validi motivi per non poter seguire il semplice pattern sopra descritto.

Cominciamo con descrivere le varie modalità con cui è possibile aumentare le prestazioni.

  1. La prima e più semplice è quella che è stata suggerita sopra: aumento della frequenza. È una modalità usata talvolta per creare nuovi prodotti, talvolta intere nuove serie di prodotti, semplicemente variando la velocità con cui la circuiteria (o parte di essa) opera. Costo praticamente nullo dell’operazione, ma l’aumento non è né infinito né senza ripercussioni, visto che va ad incidere sui consumi (vedremo come). Esiste infatti un limite massimo di frequenze sostenibili dal circuito, il cui valore è determinato da molti fattori, oltre le quali non è possibile andare. All’origine le GPU sono già vendute alla frequenza che comporta i migliori compromessi, quindi spingersi oltre porta a nuovi equilibri. I miglioramenti alla velocità possibile senza alterare i compromessi iniziali derivano spesso dai miglioramenti del processo produttivo che col tempo matura e sono sempre vantaggi contenuti. Il guadagno spesso non raggiunge il 10% rispetto alla versione precedente più lenta del chip, con consumi che possono rimanere costanti se l’aumento è all’interno dei miglioramenti concessi dal PP. [es: serie 700 di NVIDIA, serie 300 di AMD]
  2. Un’altra possibilità di aumento delle prestazioni deriva dall’aumentare il numero di unità di calcolo presenti sul chip (per il principio di scalabilità proporzionalmente quasi lineare delle GPU con il loro aumento). Con lo stesso processo produttivo raddoppiare le unità di calcolo (e le risorse per poterle sfruttare al meglio) significa sostanzialmente raddoppiare la dimensione della superficie del chip (chiamato die). Gli impatti sono abbastanza semplici da comprendere: aumento (sostanziale) dei costi, aumento (proporzionale alla crescita di dimensioni) dell’energia consumata.
    Questa modalità è quella che viene usata per creare le GPU dalle più piccole alle più grandi di una stessa generazione. Si parte da GPU basilari che vengono poi aumentate di risorse e unità di calcolo, quindi anche in dimensioni e consumi, fino a raggiungere la GPU limite di quella generazione.
    Da cosa è definita la dimensione massima, e quindi il massimo numero di unità di elaborazione integrabili?
    I limiti sono imposti principalmente da tre fattori:
    . aumento dei costi (vedremo dopo in dettaglio come e perché) e quindi ad un certo punto avrò dei processori enormi dal costo altrettanto enorme, adatti solo ad un numero molto limitato di destinazioni d’uso
    . il limite di lavorazione delle macchine che oltre ad una certa dimensione della superficie non riescono più a “stampare” correttamente (per questioni relative alle ottiche e delle maschere)
    . limiti pratici per la quantità di energia che un circuito troppo grande richiederebbe di gestire.
  3. La terza possibilità di miglioramento delle prestazioni è quella di creare una nuova architettura che a parità di spazio e/o energia possa eseguire il lavoro più velocemente della precedente. L’impatto è dovuto al costo e ai tempi necessari per sviluppare una nuova architettura (diversi anni e centinaia di milioni di dollari) e al limitato guadagno ottenibile: a meno di non aver precedentemente fatto una architettura spazzatura difficilmente la nuova sarà tanto più veloce della precedente se non per compiti specifici, visto che molto probabilmente richiederà comunque più transistor per le ottimizzazioni applicate e quindi la valutazione tra area occupata, prestazioni ottenute e energia assorbita è meno vantaggiosa del considerare solo le nuove prestazioni. [es. Maxwell di NVIDIA]
  4. L’ultima possibilità che prendiamo in esame è quella di usare un diverso processo produttivo che permette in un solo colpo di spostare più avanti i limiti che frenano i punti 1,2,3 sopra discussi e quindi trarre beneficio congiunto dell’applicazione delle 3 strategie. In questo modo il costo di progettazione di una nuova GPU, che è abbastanza alto, viene ammortizzato da un notevole aumento di prestazioni e contenimento dei costi, quindi di valore aggiunto al prodotto che si concretizza in maggiore richiesta, maggiore margine, maggiore tempo di permanenza sul mercato.

Le strategie 1,2 e 3 descritte sopra sono usate individualmente quando non c’è un nuovo PP a disposizione perché come abbiamo detto non permettono un vero salto di qualità del prodotto e per i punti 2 e 3 richiedono comunque investimenti non indifferenti con ritorni non sempre sufficienti a coprire i costi.
Per esempio la pratica 1 è stata usata da AMD e NVIDIA per rispettivamente la serie 300 e serie 700 (last update, anche per la nuova serie 500 di AMD).

La pratica 2 è stata usata da AMD per creare Fiji e NVIDIA per creare il GM200. Non è un caso che entrambe queste GPU abbiano una dimensione che è al limite delle capacità di lavorazione dei macchinari a 28nm (circa 600mmq). E non è un caso che entrambe le GPU siano state prodotte quando il PP a 28nm è maturato a sufficienza per diminuire i costi derivanti dagli scarti (unità non funzionati).
Allo stesso tempo l’aumento delle dimensioni, dei costi associati e il livello delle prestazioni ha fatto decidere AMD di non andare oltre ai 192mmq per il die dell’RV670 (vecchia serie 3000) o ai 230mmq per Polaris. Questi infatti sono i chip più grandi prodotti per quelle architetture (da confrontare con i 324mmq del G92 del tempo e dei 610mmq di Pascal di oggi).

La pratica 3 è stata usata da AMD per creare Tonga (rifacimento con nuova variante di architettura di Tahiti) e tutta la serie Maxwell di NVIDIA. In entrambi i casi la situazione era favorevole per tale scelta, dato che il nuovo PP era molto distante e in teoria le due aziende hanno calcolato di avere tutto il tempo per recuperare gli investimenti (sopratutto NVIDIA che ha disegnato 5 nuove GPU con la nuova architettura sullo stesso PP di quella vecchia).

Non c’è quindi un modo semplice ed economico di aumentare le prestazioni dei propri prodotti. La pratica 1 non ha costi ma è limitatissima nei risultati (serve giusto da tampone momentaneo in attesa di soluzioni decisamente migliori). 2 e 3, indipendentemente dai risultati prestazionali raggiunti si scontrano contro l’enorme costo necessario per realizzarle, con la 2 che ad un certo punto comunque trova un limite fisico invalicabile, indifferente ad investimenti incrementali.

Ne deriva uno scenario dove, senza i miglioramenti permessi da un nuovo processo produttivo, ad un certo punto non ha economicamente senso sviluppare alcun nuovo prodotto. E siccome le aziende non sono ONLUS e sono create per produrre soldi e non necessariamente buoni prodotti (questi sono solo un mezzo per fare i primi), senza guadagni pur anche rischiosi non si fanno nuovi prodotti.
Ecco quindi che l’arrivo dei nuovi PP ha come tolto un tappo a quello che erano i progetti delle due aziende rivali ormai in stasi da tempo.

Nota a margine:
Ribadiamo che si parla di realizzare prodotti da vendere e da cui possibilmente trarre profitto, per cui oltre a tutte le caratteristiche tecniche, i numeri tecnologici, i Volt, i Watt, gli Ampere, i TFLOPS e i GB/s usati solitamente per confrontare modelli e per le discussioni sui forum, bisogna sempre considerare i costi relativi (quindi rispetto a quanto fatto dagli altri) di come arrivare a quei numeri: parlando di prodotti che aumentano le loro prestazioni per diventare più appetibili degli altri e quindi potenzialmente vendere di più, le strategie delle aziende cambiano a seconda di quanto è il loro costo di realizzazione, o meglio, del margine che riescono a ottenere che dipende da come si posizionano sul mercato.

E le strategie a loro volta influenzano come e sopratutto perché certi prodotti sono realizzati in un determinato modo piuttosto che un altro, o perché certi prodotti esistano e altri invece no. Cercare di capire i perché di determinate scelte aiuta anche a capire più profondamente come considerare i numeri che mettiamo a confronto, quali sono i veri limiti e le probabili potenzialità dei risultati che vediamo e possibilmente alla fine fare discussioni più costruttive e utili rispetto alle sterili lotte che normalmente assistiamo con digressioni talvolta ridicole su aspetti non completamente compresi.

3.0 Processi produttivi e costi di produzione, l’importanza delle dimensioni

Da tenere presente in tutte queste valutazioni sulle scelte effettuate dalle aziende che una delle cose a cui i designer di circuiti integrati puntano maggiormente è ovviamente pagare meno possibile il chip finale sfornato dalle fonderie. Uno dei parametri più importanti da valutare è dunque la resa, ovvero il rapporto tra chip funzionanti e il totale di quelli prodotti. Quelli funzionanti possono essere venduti magari in fasce diverse a seconda delle prestazioni finali che riescono a raggiungere (selezione chiamata in gergo “binning”), e devono coprire i costi totali di produzione anche di quelli che dovranno essere scartati.

Le aziende che non hanno fabbriche proprie pagano le fonderie per “wafer” completi, ovvero per i dischi di silicio di dimensione standard sui quali sono realizzati i chip. Viene facile capire come sia importante riuscire a realizzare il maggior numero di chip funzionanti per ogni wafer prodotto: se il wafer acquistato costa 1000 e con esso si riesce a realizzare solo 10 chip funzionanti, ogni chip costa 100. Se si riescono a produrre 20 chip funzionanti, il costo scende a 50. Se i chip sono 100 il costo è di 10. Il costo derivante dalla resa deve essere sufficiente basso per mantenerne il prezzo finale del prodotto all’interno della fascia in cui lo si vuole posizionare.

La dimensione del chip da produrre ha però un impatto doppio sui costi: più infatti le dimensioni crescono più alto è il costo del chip perché ovviamente usa più superficie (meno chip sfornati in assoluto per wafer) e minore sarà il numero di chip funzionanti che escono dalla lavorazione a causa dei difetti che sono presenti sulla superficie del silicio stesso (più probabilità di incontrare uno o più difetti nell’area occupata dal chip). Quindi al crescere della dimensione si hanno meno chip totali prodotti per wafer, una frazione minore di chip che risultano funzionanti e una risultante quantità maggiore di silicio sprecato (ma pagato) per ogni chip scartato. La crescita dei costi non è quindi lineare al crescere della superficie occupata, ma è di tipo esponenziale, che significa che un piccolo aumento di dimensione produce un più grande aumento dei costi.

Come può un chip risultare completamente funzionate se ogni più piccolo difetto della superficie del silicio o del processo di produzione è potenzialmente causa di un difetto di funzionamento di uno o più transistor?
La risposta facile si chiama ridondanza. Semplificando, i circuiti elettronici non sono realizzati usando il minimo numero di porte logiche che li costituiscono, ma ne implementano molte di più. In questo modo il malfunzionamento di una di esse non è sufficiente a rendere il circuito non funzionante ma il difetto deve essere più grande e coinvolgere più porte o colpire zone critiche che non vengono ridondate. I

noltre, essendo le GPU fatte da parti molto simili tra loro organizzate in gruppi, una soluzione per recuperare in parte un chip che non risulta totalmente funzionate secondo le specifiche desiderate è quella di escludere uno di questi gruppi dall’elenco delle risorse disponibili, in modo che la parte difettosa non sia mai usata a scapito di prestazioni che risulteranno inferiori. La presenza di un enorme numero di unità di calcolo nelle GPU in effetti dona loro una sorta di “ridondanza naturale” che è usata per creare più versioni di un chip con caratteristiche diverse e non è detto che esista sempre una versione che abbia tutte le risorse di cui il chip è fisicamente dotato completamente funzionanti (es: NVIDIA GF100). L’aggiunta di parti ridondati però aumenta le dimensioni.

Resa e dimensioni sono poi profondamente interrelati: dimensioni piccole permettono di produrre più chip per wafer, ma aumentare la dimensione introducendo parti ridondanti nel chip permette di aumentare la resa.
Però abbiamo appena visto che la resa stessa è essa stessa influenzata in maniera inversamente proporzionale alla dimensione dei chip. In un senso la ridondanza aumenta le rese perché evita di buttare un chip salvandolo completamente o in parte, mentre dall’altra diminuisce la resa perché aumenta le dimensioni. La progettazione è un gioco di compromessi molto delicato che funziona meglio quanto meglio si conosce il processo produttivo che si va ad usare, evitando di sprecare spazio per troppa ridondanza o di gettare un numero eccessivo di chip per insufficienza della stessa.

Il costo per wafer ha la brutta abitudine di crescere ad ogni nuovo processo produttivo per via del numero di trattamenti necessari che aumentano, dei materiali sempre più rari e particolari che vengono usati per limitare le dispersioni, della precisione richiesta nella produzione delle maschere litografiche e del loro numero che pure aumenta per il numero di passaggi di incisione che cresce inesorabilmente. Il costo per millimetro quadro (mmq) alla fine ovviamente aumenta.

Per raggiungere il costo per singolo chip adeguato a mantenersi competitivi (anche rispetto ai propri prodotti precedenti) è necessario quindi prima di tutto avere un processo produttivo che applichi dei costi che siano compensati dalla diminuzione ùdella dimensione dei chip, dall’aumento delle prestazioni e infine dalle rese totali.

Si tratta quindi di valutare una serie di parametri che si influenzano l’un l’altro per capire come è possibile continuare a realizzare chip sempre più complessi e potenti il cui costo (che non è il prezzo applicato a noi consumatori) relativo alle performance e non alle semplici dimensioni, per via delle diverse modalità che abbiamo visto con cui aumentare il valore del proprio prodotto che non richiede necessariamente l’uso di più silicio, sia quanto più possibile minore.

Per fare un esempio esemplificativo che sia vicino a quello che realizzano i produttori di GPU, il desiderio ad ogni nuova generazione è realizzare il chip con prestazioni X, che con il vecchio PP era prodotto con costo Y, a costo Y/2 con il nuovo PP.

Avere sul mercato un chip che ha prestazioni X con costo vicino a Y, perché realizzato ancora con il vecchio PP, o perché per qualsiasi ragione il costo del nuovo chip sul nuovo PP non ha potuto scalare come dovuto, porta ad avere problemi di competitività se la concorrenza è in grado di realizzare un chip con prestazioni simili con costi vicini a Y/2 (perché il nuovo PP lo permette). Con un costo di produzione inferiore a parità di prestazioni la concorrenza può vendere a prezzo inferiore o margine superiore. Il prodotto che non gode dei vantaggi del nuovo PP tanto quanto ottenuto dalla concorrenza ha quindi un valore aggiunto inferiore che ne limita i margini anche se apparentemente le caratteristiche prestazionali sono alte.

È per questo che ogni anno vengono investiti diverse centinaia di milioni di dollari per progettare nuove architetture e diversi miliardi (!!) di dollari per creare nuove fabbriche con processi produttivi sempre più avanzati: per risparmiare soldi (sembra un controsenso, ma è così) e poter realizzare prodotti può potenti che prendano il posto di quelli vecchi che con il vecchio PP era impossibile creare (sostentamento della domanda del mercato che altrimenti satura).

Dopo questa lunga introduzione ai processi produttivi e i loro impatti sulla produzione, andremo nella seconda parte a vedere quali vantaggi pratici propongono i nuovi processi produttivi di Samsung (tramite le fabbriche di Global Foundries, o GF) e TMSC.

5 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Cesare Di Mauro
     scrive: 

    Ottima nonché utile disamina. Finalmente un altro articolo. :)

    Aggiungo che la terza soluzione è fattibile in ambito GPU, perché queste ultime non espongono direttamente la loro architettura (ISA), ma ci si affida alle API grafiche + shader language, che verranno poi tradotte, internamente e trasparentemente, dal driver nelle istruzioni eseguite effettivamente dagli shader processor.

    Una cosa del genere in ambito CPU non è, purtroppo, fattibile, perché l’ISA è pubblicamente esposta, e ci sono milioni di eseguibili che rappresentano il “legacy”, il quale è contemporaneamente croce e delizia (delizia perché… si può usare. Croce perché è legato strettamente a quell’ISA, per l’appunto).

    Infatti in ambito CPU si usa cambiare la micro-architettura. Anzi, aggiornare, per lo più.

    L’ISA si cambia pure, ma aggiungendo nuove istruzioni e/o registri a quelli esistenti. Quindi preservando il passato / legacy.

    Purtroppo c’è ben poco spazio a un cambio di ISA. Succede pure, sia chiaro (vedi IA-32 -> x64. ARM -> ARM64/v8), ma avviene in tempi biblici (decine d’anni).

  • # 2
    Nessuno
     scrive: 

    Premetto che non è certo un saggio tecnico sui processi produttivi.
    Non era mia intenzione e non ne ho le capacità. Comunque darà qualche spunto di riflessione nei capitoli futuri.

    Quello che dici del punto 3 non è esattamente vero. L’ISA non è legata a filo unico con l’architettura sotto. Vero, è più facile realizzare sistemi nuovi più efficienti dei precedenti avendo le mani completamente libere (anche se non è così neanche con le GPU) ma non è vero che se non si cambia l’ISA non si possono aumentare le prestazioni.
    L’abbiamo visto con l’Athlon dove AMD ha cambiato completamente l’architettura sottostante per eseguire le istruzioni x86 lasciando al palo il P4, abbiamo visto che non è stato così con x64 dove AMD avrebbe potuto fare molto di più, e lo vediamo tutti i giorni con ARM dove ci sono diversi produttori con licenza libera di eseguire l’ISA come meglio gli pare con HW custom ottenendo più o meno prestazioni secondo “quanto vogliono spendere” in silicio e Watt. I core di Apple per esempio non sono quelli di Mediatek anche se eseguono lo stesso codice.
    Così come Denver di nvidia non è il Kryo di Qualcomm.

    Nelle GPU non è che l’ISA precedente viene buttata via e se ne fa una nuova ad ogni generazione. Viene piano piano aggiornata di volta in volta con nuove istruzioni abbandonando quelle obsolete (tranne nei casi radicali come il passaggio da TeraScale a GCN). Anche Intel lo potrebbe fare. Motorola lo fece ai tempi della famiglia 68000 dove le istruzioni obsolete dei chip più vecchi venivano “emulate” (esempio la gloriosa FPU del 68060 che era molto più veloce di quella del 68040 emulando alcune istruzioni rare di quest’ultima). Se Intel avesse iniziato 10 anni fa ora potremmo avere una ISA completamente diversa, con vecchi applicativi emulati (tanto se sono così vecchi le prestazioni non sono quello che contano). Intel lo ha fatto e lo fa tuttora con le AVX (prima MMX, poi SSE, fino a SSE4, poi AVX, fino a AVX-512, passando per tutte le istruzioni buttate là da Intel e AMD che non erano supportate da una o dall’altra).
    Ma non lo ha fatto con le istruzioni x86 “normali” non evolvendo la sua architettura. Forse perché sicura che non ne avrebbe avuto bisogno visto che non ha concorrenza per cui migliorare così tanto come cercano di fare i produttori di GPU.
    Fatto sta che comunque è possibile usare il piano di sviluppo 3 anche con ISA pubblica. Basta essere costretti a farlo perché altrimenti lo fa la concorrenza lasciandoti indietro.
    Il discorso “legacy” è una cosa che abbiamo subito solo nel campo desktop dove Intel domina da oltre 30 anni ormai.

  • # 3
    Cesare Di Mauro
     scrive: 

    Premetto che non è certo un saggio tecnico sui processi produttivi.
    Non era mia intenzione e non ne ho le capacità. Comunque darà qualche spunto di riflessione nei capitoli futuri.

    Va benissimo così, grazie. :)

    Quello che dici del punto 3 non è esattamente vero. L’ISA non è legata a filo unico con l’architettura sotto.

    I legami, nel bene e nel male, devono esserci. Per essere chiari, non si può utilizzare una micro-architettura completamente aliena dall’ISA, perché l’impatto prestazionale sarebbe notevole (in negativo).

    Ad esempio Transmeta coi suoi processori VLIW aveva comunque parte dell’ISA x86 (almeno la paginazione della memoria, se non ricordo male).

    Vero, è più facile realizzare sistemi nuovi più efficienti dei precedenti avendo le mani completamente libere (anche se non è così neanche con le GPU) ma non è vero che se non si cambia l’ISA non si possono aumentare le prestazioni.

    Non ho mai detto questo. Ma cambiando l’ISA abbiamo prova che è possibile aumentare le prestazioni, con costi relativamente bassi. Basti vedere x86 -> x64, e ARM32 -> ARM64/v8.

    L’abbiamo visto con l’Athlon dove AMD ha cambiato completamente l’architettura sottostante per eseguire le istruzioni x86 lasciando al palo il P4, abbiamo visto che non è stato così con x64 dove AMD avrebbe potuto fare molto di più, e lo vediamo tutti i giorni con ARM dove ci sono diversi produttori con licenza libera di eseguire l’ISA come meglio gli pare con HW custom ottenendo più o meno prestazioni secondo “quanto vogliono spendere” in silicio e Watt. I core di Apple per esempio non sono quelli di Mediatek anche se eseguono lo stesso codice.
    Così come Denver di nvidia non è il Kryo di Qualcomm.

    Sì, ho ben presente. Ma vedi anche il passaggio x86 -> x64 e quello ARM32 -> ARM64/v8, che hanno portato benefici prestazionali grazie alla nuova ISA.

    Nelle GPU non è che l’ISA precedente viene buttata via e se ne fa una nuova ad ogni generazione. Viene piano piano aggiornata di volta in volta con nuove istruzioni abbandonando quelle obsolete (tranne nei casi radicali come il passaggio da TeraScale a GCN). Anche Intel lo potrebbe fare. Motorola lo fece ai tempi della famiglia 68000 dove le istruzioni obsolete dei chip più vecchi venivano “emulate” (esempio la gloriosa FPU del 68060 che era molto più veloce di quella del 68040 emulando alcune istruzioni rare di quest’ultima). Se Intel avesse iniziato 10 anni fa ora potremmo avere una ISA completamente diversa, con vecchi applicativi emulati (tanto se sono così vecchi le prestazioni non sono quello che contano).

    In realtà, da ex-programmatore Amiga & 68K, mi è stato indigesto lo scempio che Motorola ha fatto con la sua architettura. Ha tolto istruzioni non per migliorare l’ISA, ma soltanto per semplificarsi la vita con l’implementazione.

    Di fatti non è che abbia proposte nuove ISA. Tutt’altro. Ha castrato in malo modo quella esistente. Per la somma disperazione degli sviluppatori.

    Intel lo ha fatto e lo fa tuttora con le AVX (prima MMX, poi SSE, fino a SSE4, poi AVX, fino a AVX-512, passando per tutte le istruzioni buttate là da Intel e AMD che non erano supportate da una o dall’altra).

    Sì, è di questo che parlavo prima.

    Ma non lo ha fatto con le istruzioni x86 “normali” non evolvendo la sua architettura. Forse perché sicura che non ne avrebbe avuto bisogno visto che non ha concorrenza per cui migliorare così tanto come cercano di fare i produttori di GPU.

    Il motivo è il legacy: tutto il software esistente.

    Fatto sta che comunque è possibile usare il piano di sviluppo 3 anche con ISA pubblica. Basta essere costretti a farlo perché altrimenti lo fa la concorrenza lasciandoti indietro.

    Sì, esatto. O perché sei arrivato a certi limiti.

    Il discorso “legacy” è una cosa che abbiamo subito solo nel campo desktop dove Intel domina da oltre 30 anni ormai.

    Nel bene e nel male. Nel bene perché abbiamo tonnellate di software. Nel male perché l’ISA non s’è potuta evolvere molto, purtroppo.

  • # 4
    Nesuno
     scrive: 

    Il motivo è il legacy: tutto il software esistente.

    Sono ancora in disaccordo. Se emuli, il problema legacy non esiste.
    Se emuli istruzioni vecchie supportate solo da compilatori vecchi non provochi nessun danno a nessuno, visto che le applicazioni di 20 anni fa non hanno come criticità la velocità sui processori nuovi.
    Nel frattempo puoi aggiungere nuove istruzioni più vicine al microcode che possono aumentare l’IPC invece di scervellarsi in modo da creare micro code che esegua più velocemente possibile istruzioni complesse.
    Apple nel passaggio 68000->PPC->X86 ha usato questo metodo (progetto Rosetta) ed è migrata per ben 2 ISA completamente diverse.
    Quindi si può. Basta volerlo. O come ho detto, essere costretti a farlo.

    Per ribadire che il punto 3 è possibile anche con una ISA pubblica usata da oltre 30 anni:http://wccftech.com/intel-developing-new-x86-uarch-succeed-core-generation/

    Ovviamente come scritto nell’articolo occorre molto tempo per fare una cosa del genere.

  • # 5
    Cesare Di Mauro
     scrive: 

    Sono ancora in disaccordo. Se emuli, il problema legacy non esiste.
    Se emuli istruzioni vecchie supportate solo da compilatori vecchi non provochi nessun danno a nessuno, visto che le applicazioni di 20 anni fa non hanno come criticità la velocità sui processori nuovi.

    Assolutamente d’accordo con questo, e infatti è la strada che ho già avviato con la mia architettura (ISA) per mantenere compatibilità con vecchie e complesse istruzioni, ma che verranno eseguite a velocità ridotta.

    Nel frattempo puoi aggiungere nuove istruzioni più vicine al microcode che possono aumentare l’IPC invece di scervellarsi in modo da creare micro code che esegua più velocemente possibile istruzioni complesse.

    Questo si fa già da tempo, infatti.

    Apple nel passaggio 68000->PPC->X86 ha usato questo metodo (progetto Rosetta) ed è migrata per ben 2 ISA completamente diverse.
    Quindi si può. Basta volerlo. O come ho detto, essere costretti a farlo.

    Qui però stai parlando di una cosa completamente diversa: cambiare totalmente l’ISA.

    Sia chiaro che pure qui sono assolutamente d’accordo, dati i vantaggi che possono esserci. Infatti è l’approccio che ho scelto con la mia architettura (che però ha il vantaggio di essere totalmente compatibile a livello di assembly con x86/x64. E dunque il porting / adattamento dal codice esistente è di gran lunga più semplice, visto che al 99,999% dei casi serve soltanto una ricompilazione).

    Però nello specifico contesto in chi hai citato quella mia frase il contesto era diverso. Nello specifico, si parlava di istruzioni “normali”: quelle non puoi buttarle via tutte come faresti con alcune parti (vedi sopra, ma anche sotto, visto che riprendi il discorso), proprio perché c’è tanto software.

    Per essere chiari, rimuovere alcune istruzioni e passare alla loro emulazione si può fare con roba legacy, appunto, perché è roba vecchia e poco usata, per cui ti puoi permettere il lusso di farle girare comunque, sebbene a una velocità inferiore.

    Ma tutte le altre istruzioni no. E il problema principale di x86/x64 è che le istruzioni più comuni generali, pur essendo semplici, risentono comunque della struttura degli opcode complicata che quest’ISA si porta dietro da quando è nata (non solo: le successive aggiunte hanno incrementato non poco la complessità degli opcode. Mi riferisco alla linea “0F”, tanto per essere chiari).

    Se vuoi buttare tutto devi fare come con Apple, per l’appunto.

    Per ribadire che il punto 3 è possibile anche con una ISA pubblica usata da oltre 30 anni:http://wccftech.com/intel-developing-new-x86-uarch-succeed-core-generation/

    Ovviamente come scritto nell’articolo occorre molto tempo per fare una cosa del genere.

    Certamente, ma nel pezzo citato si parla comunque di mantenere quasi tutta l’ISA x86/x64 attuale, e buttare via soltanto alcuni pezzi. Non è una notizia (nel senso di cosa nuova), perché se ne parla già dallo scorso anno, e ne ero al corrente.

    Ma faccio presente che una cosa del genere è perfettamente fattibile già da tempo. Infatti i processori x86/x64 non devono essere per forza compatibile con tutta l’ISA. Ogni feature è marcata da appositi flag che denotano la sua presenza (o meno), e dunque l’eventuale utilizzabilità.

    Questo significa che puoi benissimo progettare un processore senza le famigerate MMX, pur mantenendo compatibilità col passato. Basta non esporre MMX come feature, e il software sarà avvertito.

    Idem per l’FPU, SSE, e tutta una serie di istruzioni (anche singole) che sono regolate dallo stesso meccanismo.

    Ovviamente il problema di Intel è un altro: è che ha aggiunto sempre roba, senza mai togliere niente, pur a fronte del meccanismo di qui sopra. Per avere, insomma, totale compatibilità anche col vecchiume.

    Adesso sembra sia finalmente arrivato il momento di sfruttare questo meccanismo per abbandonare il vecchiume, pur mantenendo compatibilità con l’ISA.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.