40 milioni di chip mobile Intel nel 2014? Un obiettivo forse non alla portata

[LMCH]

Originariamente inviato da cdimauro

O non c'erano risorse, visti i tempi di sviluppo molto lunghi di EV8?

Erano cose che era state pianificate da molto prima che sorgessero problemi di risorse dedicate al progetto e che tutto venisse bloccato dalla cessione a CompaQ seguita dalla vendita di CompaQ ad HP con Intel che acquisiva tutte le IP relative all'Alpha.

Originariamente inviato da cdimauro

Avere registri distinti è comodo se hai una vecchia ISA come x87 che è troppo diversa dall'unità SIMD (SSE, nel caso di x86), per cui o usi l'una oppure l'altra anche se devi usare codice scalare. Infatti le SSE supportano sia codice scalare sia vettoriale, per cui ha senso usare x87 soltanto per la precisione estesa (80-bit).

Suvvia, non essere così x86-centrico.
Vi sono molteplici ragioni per cui si può decidere di introdurre registri distinti.
Una di queste è rendere accessibili ai pogrammatori ed ai compilatori un maggior numero di registri in modo da poter aumentare il numero di istruzioni eseguite out-of-order ed al tempo stesso aver maggior mano libera nelle ottimizzazioni a livello di implementazione.

Originariamente inviato da cdimauro

In ogni caso le applicazioni eseguono in genere soltanto codice scalare (per l'FPU, intendo) o vettoriale. Per cui riutilizzare lo stesso register set per entrambi è una gran comodità.

Non sempre, se hai variabili di controllo del loop ed altro su un set di registri ed i dati vettoriali su un altro set vi sono maggiori possibilità di ottimizzazione.

Originariamente inviato da cdimauro

Specialmente nel caso dell'introduzione dei float a 128-bit, visto che si tratta di codice scalare e Alpha ha già un'FPU molto veloce e potente, sarebbe stato meglio estenderne i registri a 128-bit e aggiungere il supporto questo nuovo tipo di dato. D'altra parte l'FPU supporta pure il formato floating point VAX (per questioni legacy, ovviamente), e dunque gestire un altro tipo non sarebbe certo un problema.

I float a 128bit erano solo una delle ragioni dell'introduzione di ulteriori istruzioni SIMD e di registri dedicati.

Originariamente inviato da cdimauro

A questo punto avendo esteso l'FPU con registri a 128-bit, si sarebbero potuti aggiungere gli opcode opportuni (e distinti) per i calcoli vettoriali SIMD.

Ma se le istruzioni SIMD stavano per essere aggiunte in ogni caso, era più semplice inserire il supporto per i float a 128bit direttamente in esse visto che introducevano anche registri di dimensioni adeguate.

Originariamente inviato da cdimauro

Scusami, ma il decoder che c'entra qui? AVX, peraltro, è un formato molto più compatto e di gran lunga più semplice da decodificare rispetto alle istruzioni "intere" ed SSE.

Ehm! La documentazione tecnica di Intel racconta tutta un altra storia.
Si risparmiano sino a tre prefissi (nel caso peggiore), ma contemporanemante si usa un prefisso più lungo e di lunghezza variabile.
Il prefisso VEX (che denota le AVX) ha lunghezza variabile (2 oppure 3 byte) , viene seguito dall'opcode del tipo di istruzione (1 byte) e dopo di esso c'e' il caro vecchio descrittore "mod r/m" (1 altro byte) seguito dal descrittore SIB (1 byte, opzionale), dall'offset/displacement (1..4 byte, opzionale) e/o da un valore immediato (1 byte, opzionale).
Insomma, si parla di istruzioni a lunghezza variabile da (minimo) 4 byte ad un massimo di 11 byte.

Originariamente inviato da cdimauro

Voglio dire: non è certo un problema per il decoder gestire le nuove istruzioni SIMD che operano su 256-bit. Non è certamente questo che limiterebbe la frequenza massima raggiungibile dal processore.

Il problema che creano registri troppo ampi non è a livello di decoder ma di unida di esecuzione e di bus interni.
Il clock skew non è un opinione.

Originariamente inviato da cdimauro

La tua tesi era che l'aumento della dimensione dei registri SIMD portasse a problemi nello scalare in frequenza. L'introduzione delle AVX con registri a 256-bit (tock) non ha mostrato nulla di ciò, pur usando lo stesso processo produttivo della precedente famiglia di processori (tick). Vedremo poi fra Broadwell (AVX2, 256-bit) e Skylake (AVX-512, 512-bit) cosa succederà, nelle medesime condizioni.

Limita la frequenza massima raggiungibile e porta a dover ricorrere a soluzioni più sofisticate per tener sotto controllo il clock skew, ma se per altre ragioni non ci si spinge alla frequenza massima o si accettano le complicazioni a livello di implementazione è ovvio che il problema non appare evidente.

Originariamente inviato da cdimauro

Magari fosse quello! Purtroppo, come ben sai, scalare in frequenza col silicio è diventato estremamente difficile da una dozzina d'anni a questa parte. Ci sono voluti circa 10 anni per tornare nuovamente a raggiungere i 4Ghz, dopo il capitolo Pentium 4, e si procede ormai a incrementi di qualche centinaio di Mhz ogni tanto.

Questo per quel che riguarda gli x86, guardacaso.
Questo perchè dopo la debacle tecnologica rappresentata dal Pentium 4
in Intel non hanno avuto altra scelta che puntare sull'aumentare il parallelismo interno a colpi di core e di registri sempre più ampi.

Originariamente inviato da cdimauro

E' quello che fanno tutti, Intel inclusa. Il multithreading, quando implementato da Intel, non è mai stato votato alle prestazioni estreme, infatti, ma per tenere impegnate le unità di calcolo esistenti cercando di ottimizzarne l'uso.

Ovvero per avere maggiori prestazioni nonostante il set di istruzioni x86
non fosse l'ideale per il multithreading.
C'era un buon motivo se con Alpha EV4 l'idea era di arrivare a 4 thread per core.

Originariamente inviato da cdimauro

Non è questione di ISA: POWER8 non ha nulla di particolare per l'aggressiva implementazione multi-threaded. E' che IBM con questa ISA ha deciso di spingere su questo fronte, ma il prezzo da pagare sono i consumi elevatissimi. Adesso non ricordo di preciso perché è passato tempo, ma mi sembra che un POWER8 a 3Ghz con 4 core consumasse qualcosa come 500W o più. Se vuole continuare su questa strada, faccia pure, ma a mio avviso è un segnale che stanno ormai alla canna del gas...

I chip POWER8 sono 6-core oppure 12-core (attualmente DCM ovvero dual module su un unico package, in futuro su singolo chip), ogni singolo core esegue simultanemente 8 thread, per un totale di 96 thread e tutto questo con un consumo sui 250Watt quando un 12-core è clockato a 4.5Ghz.
http://www.extremetech.com/computing...erver-monopoly
Non è che magari ti confondi con un sistema a 4 socket precedente ?

Comunque per server di fascia alta i consumi elevati non sono un problema se ad essi sono associate prestazioni adeguate.

[cdimauro]

Originariamente inviato da LMCH

Erano cose che era state pianificate da molto prima che sorgessero problemi di risorse dedicate al progetto e che tutto venisse bloccato dalla cessione a CompaQ seguita dalla vendita di CompaQ ad HP con Intel che acquisiva tutte le IP relative all'Alpha.

Sì, ma voglio dire che Digital era troppo lenta con lo sviluppo, visti i tempi di rilascio dei suoi prodotti. Probabilmente non aveva abbastanza risorse.

Suvvia, non essere così x86-centrico.

Sono CISC-centrico da quando sono nato informaticamente parlando.

Vi sono molteplici ragioni per cui si può decidere di introdurre registri distinti.
Una di queste è rendere accessibili ai pogrammatori ed ai compilatori un maggior numero di registri in modo da poter aumentare il numero di istruzioni eseguite out-of-order ed al tempo stesso aver maggior mano libera nelle ottimizzazioni a livello di implementazione.

I RISC sono messi molto bene, perché hanno in genere molti registri. Diciamo che un'esigenza del genere è più sentita dove c'è più scarsità di registri.

Non sempre, se hai variabili di controllo del loop ed altro su un set di registri ed i dati vettoriali su un altro set vi sono maggiori possibilità di ottimizzazione.

Hum. Per i loop in genere il codice eseguito è quello "general-purpose" / intero, per cui utilizzi già un set di registri diversi.

Posso pensare a casi in cui il compilatore eseguendo l'unrolling del loop finisca per utilizzare tutti i registri SIMD, non lasciandone alcuno libero per variabili scalari / di appoggio per risultati temporanei (non vettoriali).

Non so quanto possa essere utile avere un set di registri dedicati soltanto per questi casi. Ci vorrebbero delle statistiche per decidere se ne valga concretamente la pena.

I float a 128bit erano solo una delle ragioni dell'introduzione di ulteriori istruzioni SIMD e di registri dedicati.

Ma se le istruzioni SIMD stavano per essere aggiunte in ogni caso, era più semplice inserire il supporto per i float a 128bit direttamente in esse visto che introducevano anche registri di dimensioni adeguate.

Ma i float a 128-bit occupano l'intero registro. Di SIMD, insomma, non hanno nulla, perché li usi come dati scalari, esattamente come faresti con l'FPU.

Ehm! La documentazione tecnica di Intel racconta tutta un altra storia.
Si risparmiano sino a tre prefissi (nel caso peggiore), ma contemporanemante si usa un prefisso più lungo e di lunghezza variabile.
Il prefisso VEX (che denota le AVX) ha lunghezza variabile (2 oppure 3 byte) , viene seguito dall'opcode del tipo di istruzione (1 byte) e dopo di esso c'e' il caro vecchio descrittore "mod r/m" (1 altro byte) seguito dal descrittore SIB (1 byte, opzionale), dall'offset/displacement (1..4 byte, opzionale) e/o da un valore immediato (1 byte, opzionale).
Insomma, si parla di istruzioni a lunghezza variabile da (minimo) 4 byte ad un massimo di 11 byte.

Certamente, ma prendiamo il caso reale. Se vuoi utilizzare le istruzioni SSE l'opcode parte da un minimo di 2 byte (prefisso 0F + byte per l'opcode vero e proprio), e 3 per le istruzioni più nuove (0F + 38 + opcode, ad esempio, se ricordo bene il codice dell'opcode di una delle due estensioni). Poi segue il byte di mod r/m, eventualmente accompagnato dal SIB, e dall'offset se presente. In alcuni casi hai anche un valore immediato a 8-bit, quindi un altro byte. Mediamente con l'SSE si fa uso di un prefisso che "qualifica" se l'istruzione è scalare / vettoriale, e se deve agire sulla singola o doppia precisione, e quindi aggiungiamo un altro byte. Se devi utilizzare i registri alti (per x64) o forzare un registro intero a 64-bit (sempre x64) ti serve il famigerato prefisso REX, e abbiamo un altro byte.

Già soltanto prendendo le istruzioni SSE e codificandole coi due prefissi AVX copri tutti questi casi mediamente ottieni un codice o simile (x86) o più denso (x64), col netto vantaggio di avere una decodifica di gran lunga più semplice. Aggiungiamo poi che hai il supporto ai dati a 256-bit (che non puoi avere con le SSE), ma soprattutto che con entrambi i prefissi puoi specificare un terzo registro usato come seconda sorgente, e questo consente di aumentare ulteriormente la densità del codice (nonché le prestazioni).

Il problema che creano registri troppo ampi non è a livello di decoder ma di unida di esecuzione e di bus interni.
Il clock skew non è un opinione.

Limita la frequenza massima raggiungibile e porta a dover ricorrere a soluzioni più sofisticate per tener sotto controllo il clock skew, ma se per altre ragioni non ci si spinge alla frequenza massima o si accettano le complicazioni a livello di implementazione è ovvio che il problema non appare evidente.

Hai detto bene: ci sono anche i bus interni, e questi in genere sono molto ampi, perché in questo modo è facile aumentare molto la bandwidth a disposizione. Oggi è facile avere bus che consentono di trasferire 32 o 64 byte per ciclo di clock -> 256 o 512-bit: "casualmente" la stessa dimensione dei registri SIMD AVX e AVX-512 rispettivamente.

Per cui l'ampiezza elevata dei registri SIMD ha un'importanza relativa al contesto, ed è il motivo per cui gli effetti del clock skew sono contenuti.

Questo per quel che riguarda gli x86, guardacaso.

No, riguarda tutti i chip su silicio: la fisica vale per tutti allo stesso. Infatti non è che ci siano stati RISC con frequenze elevatissime.

Questo perchè dopo la debacle tecnologica rappresentata dal Pentium 4
in Intel non hanno avuto altra scelta che puntare sull'aumentare il parallelismo interno a colpi di core e di registri sempre più ampi.

Veramente questa è roba recente, e casualmente sul multi-core ci si sono buttati tutti, all'incirca nello stesso periodo, perché il trend dell'IT è quello. Come dicevo sopra, la fisica del silicio si comporta allo stesso modo per tutti, e tutti si riversano nell'uso di soluzioni simili.

Ovvero per avere maggiori prestazioni nonostante il set di istruzioni x86

Chiaro che si fa per le prestazioni: sfruttare le unità d'esecuzione inutilizzate porta dei vantaggi.

non fosse l'ideale per il multithreading.

Perché non sarebbe l'ideale? Per i problemi di decodifica? Questo si risolve a monte, nei primi stadi della pipeline.

C'era un buon motivo se con Alpha EV4 l'idea era di arrivare a 4 thread per core.

L'EV8, immagino. Beh, con 4 thread per core ci sono arrivati anche Larrabee/Xeon Phi, ma per altri motivi (vedi sopra).

I chip POWER8 sono 6-core oppure 12-core (attualmente DCM ovvero dual module su un unico package, in futuro su singolo chip), ogni singolo core esegue simultanemente 8 thread, per un totale di 96 thread e tutto questo con un consumo sui 250Watt quando un 12-core è clockato a 4.5Ghz.
http://www.extremetech.com/computing...erver-monopoly
Non è che magari ti confondi con un sistema a 4 socket precedente ?

Hai ragione. Forse erano i sistemi a 2 socket.

Comunque per server di fascia alta i consumi elevati non sono un problema se ad essi sono associate prestazioni adeguate.

Assolutamente. Comunque dall'articolo che hai linkato:

"In terms of performance per watt, though, the Xeon (~150W TDP) is probably just ahead of the Power8 — but in general, when you’re talking servers, power consumption generally plays second fiddle to performance density (how many gigaflops you can squeeze out of a single server)."

Non male per la vecchia, decrepita architettura x86...

[LMCH]

Originariamente inviato da cdimauro

Certamente, ma prendiamo il caso reale. Se vuoi utilizzare le istruzioni SSE l'opcode parte da un minimo di 2 byte (prefisso 0F + byte per l'opcode vero e proprio), e 3 per le istruzioni più nuove (0F + 38 + opcode, ad esempio, se ricordo bene il codice dell'opcode di una delle due estensioni). Poi segue il byte di mod r/m, eventualmente accompagnato dal SIB, e dall'offset se presente. In alcuni casi hai anche un valore immediato a 8-bit, quindi un altro byte. Mediamente con l'SSE si fa uso di un prefisso che "qualifica" se l'istruzione è scalare / vettoriale, e se deve agire sulla singola o doppia precisione, e quindi aggiungiamo un altro byte. Se devi utilizzare i registri alti (per x64) o forzare un registro intero a 64-bit (sempre x64) ti serve il famigerato prefisso REX, e abbiamo un altro byte.

Già soltanto prendendo le istruzioni SSE e codificandole coi due prefissi AVX copri tutti questi casi mediamente ottieni un codice o simile (x86) o più denso (x64), col netto vantaggio di avere una decodifica di gran lunga più semplice. Aggiungiamo poi che hai il supporto ai dati a 256-bit (che non puoi avere con le SSE), ma soprattutto che con entrambi i prefissi puoi specificare un terzo registro usato come seconda sorgente, e questo consente di aumentare ulteriormente la densità del codice (nonché le prestazioni).

Ah! Quindi ragionavi in termini di AVX vs. SSE, non in termini di AVX vs. RISC.

Originariamente inviato da cdimauro

Hai detto bene: ci sono anche i bus interni, e questi in genere sono molto ampi, perché in questo modo è facile aumentare molto la bandwidth a disposizione. Oggi è facile avere bus che consentono di trasferire 32 o 64 byte per ciclo di clock -> 256 o 512-bit: "casualmente" la stessa dimensione dei registri SIMD AVX e AVX-512 rispettivamente.

Ma in tutti i casi in cui il bus diventa troppo ampio, ci si ritrova ad avere limitazioni sulla frequenza massima o a dover spendere risorse in vari accorgimenti per tener a bada il clock skew.

La cosa buffa è che Intel prima con gli Itanium fece una scelta esagerata riguardo il numero di registri direttamente accessibili (mi riferisco ai 128 interi e 128 float, i 64bit di predicati "pesavano" come un singolo registro intero)
ottenendo dei registri "veloci" i cui tempi di accesso erano quasi paragonabili a quelli che si avevano per la cache L1 su altre cpu.

Quando invece già dai primi anni '90 era chiaro che oltre 32 per set si andava solo a complicarsi la vita, loro scelsero una dimensione che era il quadruplo.

Ed ora ripetono lo stesso errore con i registri a AVX-512 con registri guardacaso ampi il quadruplo di quelli utilizzati su altre architetture.

E' vero che cose come il set d'istruzioni e valori "ottimali" non contano come una volta se si è uno o due step tecnologici in vantaggio sulla concorrenza e ci si può permettere di dedicare molte più risorse sull' R&D (tre "famiglie" di cpu x86 strutturalmente molto diverse tra loro sviluppate e prodotte in parallelo), ma non è vero che "non contano" e specialmente Intel dovrebbe ricordarsi delle debacle precedenti.

Originariamente inviato da cdimauro

Per cui l'ampiezza elevata dei registri SIMD ha un'importanza relativa al contesto, ed è il motivo per cui gli effetti del clock skew sono contenuti.

Relativamente al contesto, perchè alla fine è il contesto che va considerato.

Originariamente inviato da cdimauro

No, riguarda tutti i chip su silicio: la fisica vale per tutti allo stesso. Infatti non è che ci siano stati RISC con frequenze elevatissime.

Ma con quel Ghz in più che non guasta mai, si.
Idem per versioni a basso numero di gate o a consumi ultra-ribassati.

Originariamente inviato da cdimauro

Veramente questa è roba recente, e casualmente sul multi-core ci si sono buttati tutti, all'incirca nello stesso periodo, perché il trend dell'IT è quello. Come dicevo sopra, la fisica del silicio si comporta allo stesso modo per tutti, e tutti si riversano nell'uso di soluzioni simili.

Uno dei motivi è anche perche se si hanno abbastanza gate e superficie disponibile le soluzioni multi-core sono meno dipendenti da uno specifico set d'istruzioni e sono possibili molte più opzioni per il risparmio energetico.

Il multithreading invece permette solo di avere prestazioni più elevate su un singolo core riducendo le "bolle" nelle varie pipeline grazie alla possibilità di poter eseguire 2 o più gruppi di istruzioni (quelli dei vari thread) senza interdipendenze tra i gruppi o con le interdipendenze gestite a livello del software.

Originariamente inviato da cdimauro

Perché non sarebbe l'ideale? Per i problemi di decodifica? Questo si risolve a monte, nei primi stadi della pipeline.

Numero di registri per una singola categoria (interi, float, simd) ed interdipendenze tra le istruzioni.

Originariamente inviato da cdimauro

L'EV8, immagino.

Già EV8, quando scrivo in fretta mi si incrociano le dita e se ricontrollo altrettanto velocemente ...

Originariamente inviato da cdimauro

Beh, con 4 thread per core ci sono arrivati anche Larrabee/Xeon Phi, ma per altri motivi (vedi sopra).

Ovvero perche si presuppone che saranno usati principalmente per eseguire istruzioni SIMD su registri a 512bit e con 32 registri ZMM visibili al programmatore/compilatore per thread.

Interessante come 32 spunti sempre fuori come dimensione ottimale di un set di registri.

[cdimauro]

Originariamente inviato da LMCH

Ah! Quindi ragionavi in termini di AVX vs. SSE, non in termini di AVX vs. RISC.

Ehm... sì. Confrontavo il passato col presente di x86/x64.

Per quanto mi riguarda non credo ci siano paragoni fra AVX e RISC, perché i primi consentono di operare direttamente con un dato in memoria, risparmiando la classica load (che è "fusa" in tutte le istruzioni), e il tutto mantenendo una lunghezza dell'istruzione mediamente inferiore (prefisso da 2 o 3 byte + opcode + mod/rm + offset a 8-bit = 5 o 6 byte; un RISC con load + operazione richiede 8 byte, e il divario aumenta con offset più grandi). Quindi a fronte di codice più denso (che ha i suoi benefici in tutte le gerarchie di memoria) si hanno anche prestazioni migliori (due operazioni in una, con l'ulteriore beneficio che non c'è dipendenza da load + successivo utilizzo del dato).

Ma in tutti i casi in cui il bus diventa troppo ampio, ci si ritrova ad avere limitazioni sulla frequenza massima o a dover spendere risorse in vari accorgimenti per tener a bada il clock skew.

OK, ma se tutti adottano bus ampi, avranno tutti gli stessi problemi, giusto?

La cosa buffa è che Intel prima con gli Itanium fece una scelta esagerata riguardo il numero di registri direttamente accessibili (mi riferisco ai 128 interi e 128 float, i 64bit di predicati "pesavano" come un singolo registro intero)
ottenendo dei registri "veloci" i cui tempi di accesso erano quasi paragonabili a quelli che si avevano per la cache L1 su altre cpu.

Quando invece già dai primi anni '90 era chiaro che oltre 32 per set si andava solo a complicarsi la vita, loro scelsero una dimensione che era il quadruplo.

Non ho mai studiato l'architettura dell'Itanium, per cui non posso risponderti in maniera precisa. Mi pare di ricordare che soltanto 32 registri alla volta era visibili in un preciso momento, perché faceva uso di un meccanismo a finestre (tipo SPARC, se non erro). Questo per facilitare l'implementazione delle chiamate a funzioni con relativo passaggio di parametri, fino a una certa profondità (dopo immagino che una parte del register set andava per forza di cose salvato sullo stesso, e poi ripristinato al ritorno). L'idea mi sembra buona, perché con 128 registri avresti la possibilità di effettuare 4 chiamate a funzioni senza toccare lo stack. Poi, ripeto, bisogna vedere come funziona effettivamente e l'impatto che ha sul codice reale.

Ed ora ripetono lo stesso errore con i registri a AVX-512 con registri guardacaso ampi il quadruplo di quelli utilizzati su altre architetture.

Però sono due cose diverse. Itanium aveva 128 + 128 registri a 64 bit. Quindi accedevi a 64-bit di dati alla volta, esattamente come tutti gli altri processori a 64-bit. L'unico problema era la numerosità, per cui bisogna vedere l'impatto che aveva sull'accesso. Ma penso che fosse in buona compagnia: l'EV8 a quanto pare aveva ben 512 registri internamente.

AVX-512, invece, ha soltanto 32 registri, ma a 512-bit. Quindi accedi a 512-bit alla volta, e il problema che si porta dietro è il clock skew.

E' vero che cose come il set d'istruzioni e valori "ottimali" non contano come una volta se si è uno o due step tecnologici in vantaggio sulla concorrenza e ci si può permettere di dedicare molte più risorse sull' R&D (tre "famiglie" di cpu x86 strutturalmente molto diverse tra loro sviluppate e prodotte in parallelo), ma non è vero che "non contano" e specialmente Intel dovrebbe ricordarsi delle debacle precedenti.

Credo che ne abbiano fatto tesoro, e avranno avuto delle buone ragioni per certe scelte. AVX non nasce certo ieri, ma dopo anni di R&D. Per Larrabee, precursore di AVX-512, addirittura sono stati scomodati Michael Abrash e Tim Sweeney...

Relativamente al contesto, perchè alla fine è il contesto che va considerato.

Appunto. Il POWER8, che abbiamo citato prima, utilizza un bus da 64-byte per ciclo di clock, quindi trasferisce 512-bit alla volta. Sarebbe interessante conoscere i dati degli altri processori, ma credo che ormai almeno 32-byte per ciclo li trasferiscano. D'altra parte non c'è altro modo per ottenere bandwidth elevate, visto che la frequenza cresce ormai di poco.

Ma con quel Ghz in più che non guasta mai, si.

Vorrei vederlo.

Idem per versioni a basso numero di gate o a consumi ultra-ribassati.

Senz'altro, questo è un vantaggio, ma ormai non più significativo, come abbiamo avuto modo di discutere un po' di giorni fa.

Numero di registri per una singola categoria (interi, float, simd)

Non dovrebbe essere un vantaggio questo? Devi duplicare meno risorse. Comunque con x64 ci sono 16 registri general-purpose e altrettanti per l'unità SIMD, come molti RISC.

ed interdipendenze tra le istruzioni.

Qui la questione è aperta, a mio avviso. I RISC, grazie alla possibilità di utilizzare 3 operandi, riducono le dipendenze che ci sono normalmente con le architetture che usano un operando sia come sorgente sia come destinazione.

Per contro CISC come x86 possono contare sul fatto che possono eseguire load + operazione direttamente, e questo elimina una dipendenza (che invece è presente nei RISC); inoltre possono anche operare direttamente sulla memoria senza nemmeno passare dai registri, e ciò elimina ancora altre dipendenze. Aggiungo che grazie ad AVX adesso è possibile utilizzare 3 operandi (anche per alcune istruzioni intere), per cui almeno per SIMD ed FPU (visto che ormai si usa l'unità SIMD anche per operazioni scalari) siamo esattamente nella stessa situazione dei RISC.

Complessivamente non mi pare che la situazione sia malvagia.

Ovvero perche si presuppone che saranno usati principalmente per eseguire istruzioni SIMD su registri a 512bit e con 32 registri ZMM visibili al programmatore/compilatore per thread.

Esattamente.

Interessante come 32 spunti sempre fuori come dimensione ottimale di un set di registri.

Per il codice SIMD sicuramente, perché si presta molto alla parallelizzazione e l'unrolling dei loop.

Per il codice general purpose si sente molto meno quest'esigenza. 16 registri coprono la stragrande maggioranza dei casi.
Certamente con 32 registri si riesce a fare molto di più e coprire molti più casi, ma il prezzo da pagare è lo spazio nella opcode table che impatta sulle scelte e infine sulla densità di codice.
Comunque ci sono anche soluzioni che consentono di utilizzare 32 registri o anche più (per l'unità SIMD) a costi molto contenuti a livello di codifica e, quindi, di densità di codice.

P.S. Non so a te, ma questa discussione mi sta piacendo molto.

[Ares17]

Originariamente inviato da cdimauro

P.S. Non so a te, ma questa discussione mi sta piacendo molto.

Da parte mia è la prima notizia che leggo la mattina (certo non avete il tempo per scrivere articoli, ma da discussioni come queste ne escono fuori dei compendi, sopratutto perchè arrivate da due visioni diametralmente opposte ma senza mai scontrarvi su posizioni rigide).
E' un piacere leggervi

[cdimauro]

Grazie.
Come avrai intuito, sono argomenti di cui potrei parlare per ore, perché li adoro.
Poi devo dire che incontrando interlocutori con cui è possibile intavolare una discussione civile e onesta (sebbene ovviamente ognuno abbia le propria visione delle cose, per l'appunto), è anche più piacevole.

[LMCH]

Originariamente inviato da cdimauro

OK, ma se tutti adottano bus ampi, avranno tutti gli stessi problemi, giusto?

Problemi simili su alcune cose, diversi su altre e con l'aumento dell'ampiezza del bus come parte delle soluzioni adottate.

Originariamente inviato da cdimauro

Non ho mai studiato l'architettura dell'Itanium, per cui non posso risponderti in maniera precisa. Mi pare di ricordare che soltanto 32 registri alla volta era visibili in un preciso momento, perché faceva uso di un meccanismo a finestre (tipo SPARC, se non erro). Questo per facilitare l'implementazione delle chiamate a funzioni con relativo passaggio di parametri, fino a una certa profondità (dopo immagino che una parte del register set andava per forza di cose salvato sullo stesso, e poi ripristinato al ritorno). L'idea mi sembra buona, perché con 128 registri avresti la possibilità di effettuare 4 chiamate a funzioni senza toccare lo stack. Poi, ripeto, bisogna vedere come funziona effettivamente e l'impatto che ha sul codice reale.

Le istruzioni supportavano sia l'indirizzamento "diretto" di tutti i 128 registri interi o float (selettore di registro a 7 bit nelle istruzioni) e sia l'indirizzamento "indiretto" in modalita RSE (Register Stack Engine) in cui i primi 32 registri erano indirizzati "staticamente"/"direttamente" mentre gli altri 96 vengono gestiti come se fossero le prime 96 word a 64bit sulla cima dello stack.

In Intel erano partiti con l'idea di realizzare un architettura VLIW con "compressione" delle istruzioni e sono finiti con il realizzare un "coso" con così tante feature che si intralciavano reciprocamente da complicare a livelli demenziali l'implementazione.

Immagina un VLIW, un CISC, un RISC, un AS/400, una calcolatrice RPN della TI, una pascalina ed un abaco che entrano in una stanza buia dopo essersi bombati di cocaina, viagra e coca-cola con aspirina dentro.

Itanium è praticamente figlio di tale ammucchiata, ma nessuna delle architetture rivendica la paternita e sopratutto non si capisce quale/come/cosa potesse essere la madre.

Originariamente inviato da cdimauro

Però sono due cose diverse. Itanium aveva 128 + 128 registri a 64 bit. Quindi accedevi a 64-bit di dati alla volta, esattamente come tutti gli altri processori a 64-bit. L'unico problema era la numerosità, per cui bisogna vedere l'impatto che aveva sull'accesso. Ma penso che fosse in buona compagnia: l'EV8 a quanto pare aveva ben 512 registri internamente.

Si ma i registri "solo interni" li puoi togliere, aggiungere, partizionare ed in generale implementare ed interfacciare alle altre componenti interne come vuoi mentre per quelli "visibili al programmatore/compilatore" non permettono simili rimaneggiamenti.

Originariamente inviato da cdimauro

AVX-512, invece, ha soltanto 32 registri, ma a 512-bit. Quindi accedi a 512-bit alla volta, e il problema che si porta dietro è il clock skew.

Credo che ne abbiano fatto tesoro, e avranno avuto delle buone ragioni per certe scelte. AVX non nasce certo ieri, ma dopo anni di R&D. Per Larrabee, precursore di AVX-512, addirittura sono stati scomodati Michael Abrash e Tim Sweeney...

Originariamente inviato da cdimauro

Appunto. Il POWER8, che abbiamo citato prima, utilizza un bus da 64-byte per ciclo di clock, quindi trasferisce 512-bit alla volta. Sarebbe interessante conoscere i dati degli altri processori, ma credo che ormai almeno 32-byte per ciclo li trasferiscano. D'altra parte non c'è altro modo per ottenere bandwidth elevate, visto che la frequenza cresce ormai di poco.

Originariamente inviato da cdimauro

Vorrei vederlo.

POWER6, venduto clockato "di serie" a 5Ghz.
Poi si sono resi conto che erano entrati in zona plaid (semitcit. "Spaceballs") ed hanno rallentato aggiungendo più core su moduli MCM
ma con POWER8 se non sbaglio c'e' nuovamente l'opzione per versioni a 5Ghz.

Se ricordo correttamente le versioni a clock "smodato" tornavano particolarmente utili nei casi in cui si doveva far girare vecchio codice binario
per altre architetture (tipo AS/400, ma anche roba vecchia per mainframe) in emulazione.

Originariamente inviato da cdimauro

Senz'altro, questo è un vantaggio, ma ormai non più significativo, come abbiamo avuto modo di discutere un po' di giorni fa.

Dipende.
Dipende ad esempio da quanti core si vogliono implementare per chip e con quali obiettivi
Ad esempio per gli ARM ha senso un architettura tipo big.LITTLE mentre con gli x86 proprio non se ne parla.
E non è un caso se per roba embedded c'e' una marcata preferenza per soluzioni basate su cpu RISC o simil-RISC (maggiori opzioni disponibili in termini di potenza di calcolo e consumi).

Originariamente inviato da cdimauro

Non dovrebbe essere un vantaggio questo? Devi duplicare meno risorse. Comunque con x64 ci sono 16 registri general-purpose e altrettanti per l'unità SIMD, come molti RISC.

Più registri sono visibili a livello di assembly (al programamtore o al compilatore) e maggiori sono le possibilità di ottimizzazione che si hanno mappando su registro gli operandi ecc.
Ma dall'altro lato più sono i registri visibili e più si allunga la lunghezza delle istruzioni e più si impongono vincoli all'implementazione dell'architettura.

Da anni e con un fottio di test e simulazione in supporto della cosa il numero ottimale è tra 16 e 32 per set di registri per cpu con word size ottimale a 32..64 bit (accessibili con istruzioni "semplici", senza prefissi ed altri barbatrucchi), con 32 la scelta ottimale per architetture a 64bit.
Per architetture a 16bit e word size ottimale 16bit invece il valore ottimale era 8..16 per set di registri.

x86 è nato come "evoluzione" a 16bit di un architettura (l'8080) ad 8 bit e si è portato la limitazione degli 8 registri molto a lungo, salendo a 16 con l'aggravio dei prefissi ma solo grazie ad AMD (che con x86-64 estese sia i registri GPR che quelli SSE a set di 16 registri) ed infine con l'ultima estensione a set di 32 registri solo per i registri SIMD di AVX.

Originariamente inviato da cdimauro

Qui la questione è aperta, a mio avviso. I RISC, grazie alla possibilità di utilizzare 3 operandi, riducono le dipendenze che ci sono normalmente con le architetture che usano un operando sia come sorgente sia come destinazione.

Per contro CISC come x86 possono contare sul fatto che possono eseguire load + operazione direttamente, e questo elimina una dipendenza (che invece è presente nei RISC); inoltre possono anche operare direttamente sulla memoria senza nemmeno passare dai registri, e ciò elimina ancora altre dipendenze. Aggiungo che grazie ad AVX adesso è possibile utilizzare 3 operandi (anche per alcune istruzioni intere), per cui almeno per SIMD ed FPU (visto che ormai si usa l'unità SIMD anche per operazioni scalari) siamo esattamente nella stessa situazione dei RISC.

Complessivamente non mi pare che la situazione sia malvagia.

Malvagia no, ma più complicata del necessario si.
Nel senso che Intel incapace di sganciarsi dagli x86 (ci ha provato in grande stile almeno tre volte) ora sembra intenzionata a farli evolvere in una specie di appendice del set d'istruzioni AVX.

Originariamente inviato da cdimauro

P.S. Non so a te, ma questa discussione mi sta piacendo molto.

Anche a me.

Ma credo che tra qualche tempo ci sposteremo su altri thread, nel senso che i core ARMv8 "per dispositivi mobili" di prossima uscita sembrano parecchio aggressivi sul lato prestazioni e quindi sorgeranno discussioni a riguardo e contronti con i-core-precedentemente-noti-come-Atom ecc. ecc.

Senza contare gli atti di necromanzia di Nvidia ...
che a quanto sembra con il Tegra K1 a 64bit
(pin compatibile con il Tegra K1 a 32 bit basato su core A15, ma
con core Denver ed architettura interna molto diversa)
sta usando con risultati interessanti un approccio simile a quello delle cpu Transmeta:
http://www.extremetech.com/computing...t-android-chip
(ovviamente credo che quei numeri siano gonfiati rispetto a quello che si otterrà nella realtà con un tablet con quel SoC, se non altro per evitare di mangiarsi viva la batteria )

[cdimauro]

Originariamente inviato da LMCH

Le istruzioni supportavano sia l'indirizzamento "diretto" di tutti i 128 registri interi o float (selettore di registro a 7 bit nelle istruzioni) e sia l'indirizzamento "indiretto" in modalita RSE (Register Stack Engine) in cui i primi 32 registri erano indirizzati "staticamente"/"direttamente" mentre gli altri 96 vengono gestiti come se fossero le prime 96 word a 64bit sulla cima dello stack.

In Intel erano partiti con l'idea di realizzare un architettura VLIW con "compressione" delle istruzioni e sono finiti con il realizzare un "coso" con così tante feature che si intralciavano reciprocamente da complicare a livelli demenziali l'implementazione.

Immagina un VLIW, un CISC, un RISC, un AS/400, una calcolatrice RPN della TI, una pascalina ed un abaco che entrano in una stanza buia dopo essersi bombati di cocaina, viagra e coca-cola con aspirina dentro.

Itanium è praticamente figlio di tale ammucchiata, ma nessuna delle architetture rivendica la paternita e sopratutto non si capisce quale/come/cosa potesse essere la madre.

Itanium dovrebbe essere anche figlio di HP. Comunque prima o poi dovrò decidermi ad approfondirne la conoscenza dell'ISA, primo perché sono dannatamente curioso per natura riguardo a questi argomenti, e secondo perché vorrei capire meglio quali scelte siano state corrette e quali sbagliate (a parte il fatto che sia un processore VLIW e in-order). Ma al momento ho ben altro da fare.

POWER6, venduto clockato "di serie" a 5Ghz.
Poi si sono resi conto che erano entrati in zona plaid (semitcit. "Spaceballs") ed hanno rallentato aggiungendo più core su moduli MCM
ma con POWER8 se non sbaglio c'e' nuovamente l'opzione per versioni a 5Ghz.

Più che altro perché a quelle frequenze il consumo diventa troppo elevato. IBM con la sua serie POWER non ha una storia di consumi contenuti; tutt'altro. Ma, come dicevamo anche prima, opera in un segmento in cui questo parametro non ha un peso così importante come in altri ambiti.

Tolto questo, è difficile vedere altri RISC arrivare a frequenze così elevate mantenendo consumi comparabili con quelli che ritroviamo in ambito desktop o mobile.

Se ricordo correttamente le versioni a clock "smodato" tornavano particolarmente utili nei casi in cui si doveva far girare vecchio codice binario
per altre architetture (tipo AS/400, ma anche roba vecchia per mainframe) in emulazione.

Non penso, perché POWER6 era un processore in-order, proprio in ambito emulazione non poteva eccellere.

Dipende.
Dipende ad esempio da quanti core si vogliono implementare per chip e con quali obiettivi
Ad esempio per gli ARM ha senso un architettura tipo big.LITTLE mentre con gli x86 proprio non se ne parla.

Ci sono diverse implementazioni ARM che non usano il modello big.LITTLE, perché preferiscono ricorrere ad altre soluzioni. Vedi Apple con l'A7, o l'appena arrivato Tegra K1 a 64-bit. Questo perché potresti aver sviluppato le tecnologie necessarie per ridurre ugualmente i consumi.

E non è un caso se per roba embedded c'e' una marcata preferenza per soluzioni basate su cpu RISC o simil-RISC (maggiori opzioni disponibili in termini di potenza di calcolo e consumi).

Senz'altro. Più piccoli sono i chip, e più si fa sentire il peso di qualche milione di transistor attivi. In certi settori non si può competere, se non con architetture adeguate.

Fortunatamente anche il settore embedded sta diventando sempre più esigente, per cui i chip diventano sempre più grossi per tutti, per cui si aprono degli spazi anche per x86.

Più registri sono visibili a livello di assembly (al programamtore o al compilatore) e maggiori sono le possibilità di ottimizzazione che si hanno mappando su registro gli operandi ecc.
Ma dall'altro lato più sono i registri visibili e più si allunga la lunghezza delle istruzioni e più si impongono vincoli all'implementazione dell'architettura.

Da anni e con un fottio di test e simulazione in supporto della cosa il numero ottimale è tra 16 e 32 per set di registri per cpu con word size ottimale a 32..64 bit (accessibili con istruzioni "semplici", senza prefissi ed altri barbatrucchi), con 32 la scelta ottimale per architetture a 64bit.
Per architetture a 16bit e word size ottimale 16bit invece il valore ottimale era 8..16 per set di registri.

Infatti. Un solo piccolo appunto: quel che conta è poter accedere ai registri. Se poi lo si fa con prefissi (x86) o altro (vedi THUMB, ad esempio), l'importanza è relativa, purché si mantenga una buona densità ed esecuzione del codice.

x86 è nato come "evoluzione" a 16bit di un architettura (l'8080) ad 8 bit e si è portato la limitazione degli 8 registri molto a lungo, salendo a 16 con l'aggravio dei prefissi ma solo grazie ad AMD (che con x86-64 estese sia i registri GPR che quelli SSE a set di 16 registri) ed infine con l'ultima estensione a set di 32 registri solo per i registri SIMD di AVX.

Perché è l'unità SIMD l'elemento su cui ruotano, da anni, le modifiche all'ISA e gli incrementi prestazionali. Per questo aveva senso mettere ordine e una solida base per il futuro, con AVX prima e soprattutto con AVX-512 in futuro. Non credo proprio che ci saranno esperimenti riguardo alle classiche istruzioni general purpose.

A parte questo, l'ISA CISC ha i suoi pregi, di cui ho già parlato prima, e che le consentono di richiedere un minor numero di registri per effettuare le stesse operazioni. Se disassembli un eseguibile x86 o x64, troverai tante istruzioni tipo MOV Memoria,ValoreImmediato, ADD Memoria,ValoreImmediato, e così via, che oltre a essere molto veloci, non sporcano alcun registro.

Malvagia no, ma più complicata del necessario si.
Nel senso che Intel incapace di sganciarsi dagli x86 (ci ha provato in grande stile almeno tre volte)

Io ricordo soltanto Itanium.

ora sembra intenzionata a farli evolvere in una specie di appendice del set d'istruzioni AVX.

Vedi sopra: solo per l'unità SIMD, per la quale ha certamente senso tutto ciò (troppi casini coi prefissi).

Anche a me.

Ma credo che tra qualche tempo ci sposteremo su altri thread, nel senso che i core ARMv8 "per dispositivi mobili" di prossima uscita sembrano parecchio aggressivi sul lato prestazioni e quindi sorgeranno discussioni a riguardo e contronti con i-core-precedentemente-noti-come-Atom ecc. ecc.

Senza contare gli atti di necromanzia di Nvidia ...
che a quanto sembra con il Tegra K1 a 64bit
(pin compatibile con il Tegra K1 a 32 bit basato su core A15, ma
con core Denver ed architettura interna molto diversa)
sta usando con risultati interessanti un approccio simile a quello delle cpu Transmeta:
http://www.extremetech.com/computing...t-android-chip
(ovviamente credo che quei numeri siano gonfiati rispetto a quello che si otterrà nella realtà con un tablet con quel SoC, se non altro per evitare di mangiarsi viva la batteria )

Esattamente. D'altra parte a una veloce occhiata si notano le seguenti cose:
- cache L1 codice quadruplicata (128KB) rispetto alla media (32KB) e cache dati raddoppiata (64KB), necessarie per sfamare questo mostro;
- architettura nativa incompatibile con ARM; le istruzioni ARMv8 (e immagino anche ARM32, Thumb, ecc.) vengono prima decodificate nell'ISA nativa, e soltanto dopo eseguite. Eventualmente possono essere memorizzate nella speciale cache in memoria;
- design VLIW in-order;
- design votato all'esecuzione single-thread (anche se questo fa a pugni con l'architettura in-order; anch'io voglio vedere i benchmark reali). Infatti nei pochi benchmark (sintetici, per lo più) presentati "casualmente" dominano quelli single-thread (con quelli multi-thread la musica sarebbe stata diversa, specialmente per BayTrail, che ha 4 core a disposizione);
- soltanto due massicci core a disposizione (rispetto ai 4 di K1 a 32-bit) che si sono fregati tutto lo spazio. E' pure sparito il mini-core da usare per risparmiare corrente quando c'è poco carico di lavoro;
- frequenze molto elevate (e anche per questo vorrei vedere i consumi reali). Decisamente più elevate rispetto ai processori x86 che sono stati inclusi nei benchmark.

A primo acchito direi che il reparto marketing abbia fatto un ottimo lavoro. Comunque aspetto qualche recensione da tecnici di terze parti per appurare come stiano realmente le cose.

Di questo nuovo progetto penso ci sarà di che parlare in qualche futura notizia a riguardo.

[LMCH]

Originariamente inviato da cdimauro

Non penso, perché POWER6 era un processore in-order, proprio in ambito emulazione non poteva eccellere.

Se si tratta il codice binario da emulare come se fosse codice sorgente
(quindi con compilazione offline seguita da uso di tecniche JIT solo nei casi in cui si rileva codice automodificante) anche un processore in-order va bene (perche il "ricompilatore" di fatto è in grado di riordinare le istruzioni e di eseguire un interleave di sequenze di istruzioni native che corrispondono alle istruzioni "originali") ed avere un clock elevato torna utile per alzare le prestazioni quando si esegue il codice ricompilato, ristrutturato & riordinato.

Originariamente inviato da cdimauro

Ci sono diverse implementazioni ARM che non usano il modello big.LITTLE, perché preferiscono ricorrere ad altre soluzioni. Vedi Apple con l'A7, o l'appena arrivato Tegra K1 a 64-bit. Questo perché potresti aver sviluppato le tecnologie necessarie per ridurre ugualmente i consumi.

E tutte traggono vantaggio dall'avere un set d'istruzioni relativamente semplice a livello decodifica.

Originariamente inviato da cdimauro

Esattamente. D'altra parte a una veloce occhiata si notano le seguenti cose:
- cache L1 codice quadruplicata (128KB) rispetto alla media (32KB) e cache dati raddoppiata (64KB), necessarie per sfamare questo mostro;
- architettura nativa incompatibile con ARM; le istruzioni ARMv8 (e immagino anche ARM32, Thumb, ecc.) vengono prima decodificate nell'ISA nativa, e soltanto dopo eseguite. Eventualmente possono essere memorizzate nella speciale cache in memoria;
- design VLIW in-order;
- design votato all'esecuzione single-thread (anche se questo fa a pugni con l'architettura in-order; anch'io voglio vedere i benchmark reali). Infatti nei pochi benchmark (sintetici, per lo più) presentati "casualmente" dominano quelli single-thread (con quelli multi-thread la musica sarebbe stata diversa, specialmente per BayTrail, che ha 4 core a disposizione);
- soltanto due massicci core a disposizione (rispetto ai 4 di K1 a 32-bit) che si sono fregati tutto lo spazio. E' pure sparito il mini-core da usare per risparmiare corrente quando c'è poco carico di lavoro;
- frequenze molto elevate (e anche per questo vorrei vedere i consumi reali). Decisamente più elevate rispetto ai processori x86 che sono stati inclusi nei benchmark.

A primo acchito direi che il reparto marketing abbia fatto un ottimo lavoro. Comunque aspetto qualche recensione da tecnici di terze parti per appurare come stiano realmente le cose.

Di questo nuovo progetto penso ci sarà di che parlare in qualche futura notizia a riguardo.

Già.
E' ovvio che NVidia pensa che se riesce a mettere a punto il sistema completo (hardware VLIW + "ottimizzatore" hardware/software) poi lo sviluppo successivo sarà un sistema multicore VLIW che in base al carico ed alle esigente opera sia come cpu multicore che come GPU.
Insomma, è un altra interpretazione de "il set d'istruzioni non è più rilevante"
(a patto che sia sufficientemente semplice ed ben ottimizzabile tramite ricompilazione, suppongo).

[cdimauro]

Originariamente inviato da LMCH

Se si tratta il codice binario da emulare come se fosse codice sorgente
(quindi con compilazione offline seguita da uso di tecniche JIT solo nei casi in cui si rileva codice automodificante) anche un processore in-order va bene (perche il "ricompilatore" di fatto è in grado di riordinare le istruzioni e di eseguire un interleave di sequenze di istruzioni native che corrispondono alle istruzioni "originali") ed avere un clock elevato torna utile per alzare le prestazioni quando si esegue il codice ricompilato, ristrutturato & riordinato.

Purtroppo anche così non risolvi col codice di un emulatore che è troppo intricato e strapieno di dipendenze. Ho scritto un emulatore 80186 per Amiga (68020+; interamente in assembly) e uno 65C02 (assembly 8086 per l'esecuzione delle istruzion 65C02; Turbo Pascal per tutto il resto), per cui conosco molto bene le problematiche che ci sono dietro.

Con questo tipo di codice puoi ricompilare come vuoi, ma un'architettura in-order darà sempre risultati peggiori rispetto a una OoO.

E tutte traggono vantaggio dall'avere un set d'istruzioni relativamente semplice a livello decodifica.

Non credo. Roba come il power-gating, ad esempio, non ha nulla a che vedere con la semplicità di decodifica. Era a questo che mi riferivo quanto parlavo di tecnologie per la riduzione dei consumi.

Ogni produttore di CPU ha nel suo portfolio di brevetti chissà quanta roba sull'argomento. Sicuramente Transmeta ne aveva sviluppata parecchia, e adesso è parte di nVidia (che l'ha acquisita un po' di anni fa), ma se non erro le licenze relative alla riduzione dei consumi sono state cedute o licenziate anche a Intel.

La semplicità delle istruzioni aiuta sicuramente nella decodifica, e di questo ne abbiamo parlato: i RISC hanno un vantaggio, ma questo vantaggio non ha impedito che uscissero fuori architetture come big.LITTLE, che risolvono ben altri problemi. Però Apple A7 e Tegra K1 64-bit... non ne fanno uso. E Intel può contare sul Loop Stream Detection.

Già.
E' ovvio che NVidia pensa che se riesce a mettere a punto il sistema completo (hardware VLIW + "ottimizzatore" hardware/software) poi lo sviluppo successivo sarà un sistema multicore VLIW che in base al carico ed alle esigente opera sia come cpu multicore che come GPU.

Francamente non lo vedo proprio. VLIW per le GPU è un modello architetturale che è stato sostanzialmente abbandonato. Ciò che le GPU implementano oggi è il modello SIMD, o comunque ci sono molto vicini.

Inoltre nVidia ha dichiarato (mi pare di averlo letto sul loro blog) che ciò che lei vede è l'accoppiata CPU per calcolo "general purpose" e GPU per il calcolo (massicciamente) parallelo.

D'altra parte è anche logico che sia così: la GPU non è fatta per soppiantare il lavoro in cui una CPU semplicemente eccelle.

La cosa che a mio avviso cozza tremendemente è l'aver scelto un modello VLIW per la CPU, che si è dimostrato sempre poco performante per il calcolo "general purpose". Esempi illustri ne abbiamo avuti in passato: Itanium e... proprio Transmeta.

Per questo voglio vedere (tant)i benchmark eseguiti con codice variegato.

Insomma, è un altra interpretazione de "il set d'istruzioni non è più rilevante"
(a patto che sia sufficientemente semplice ed ben ottimizzabile tramite ricompilazione, suppongo).

Invece proprio Project Denver continua a dimostrare che l'ISA è più che mai importante. Infatti ARM, inclusa ARMv8, era così bella e rinomata che hanno pensato bene di "buttarla" e soppiantarla con una loro architettura VLIW.

I risultati concreti sono di là da vedersi, come già detto, ma è un segnale significativo sull'argomento "ISA = importante".

[cdimauro]

Originariamente inviato da LMCH

I chip POWER8 sono 6-core oppure 12-core (attualmente DCM ovvero dual module su un unico package, in futuro su singolo chip), ogni singolo core esegue simultanemente 8 thread, per un totale di 96 thread e tutto questo con un consumo sui 250Watt quando un 12-core è clockato a 4.5Ghz.
http://www.extremetech.com/computing...erver-monopoly
Non è che magari ti confondi con un sistema a 4 socket precedente ?

Casualmente ho ritrovato il thread in cui avevo letto il dato che avevo riportato in precedenza.

Questo è il sistema POWER 8 in oggetto: singolo socket, con supporto a CPU con 4/6/8 core.

Riporto di seguito l'immagine, da quel thread, riguardo al consumo:



Sono 500W, ma credo si riferisca all'intera piattaforma (quindi non soltanto alla CPU). Comunque è un sistema con soli 4 core a 3Ghz, e il consumo mi pare molto elevato.

[LMCH]

Originariamente inviato da cdimauro

Riporto di seguito l'immagine, da quel thread, riguardo al consumo:



Sono 500W, ma credo si riferisca all'intera piattaforma (quindi non soltanto alla CPU). Comunque è un sistema con soli 4 core a 3Ghz, e il consumo mi pare molto elevato.

Si, il dato è riferito al sistema completo
( S814-8286-41A ovvero IBM Power System S814)
http://www-01.ibm.com/common/ssi/Sho...st_locale=null

E' un server con socket dual-chip module (DCM)
in formato 4U rack-mount oppure desk-side
con un fottio di roba oltre alla cpu
(fino a 512GB di ram, fino a 18 unita di memoria "formato DVD bay"
espansioni slot PCIe hot-swap, doppio alimentatore hot-plug
4 porte USB 3.0, 2 USB 2.0, 2 link HMC 1Gbit, ecc. ecc. ).

[LMCH]

Originariamente inviato da cdimauro

Purtroppo anche così non risolvi col codice di un emulatore che è troppo intricato e strapieno di dipendenze. Ho scritto un emulatore 80186 per Amiga (68020+; interamente in assembly) e uno 65C02 (assembly 8086 per l'esecuzione delle istruzion 65C02; Turbo Pascal per tutto il resto), per cui conosco molto bene le problematiche che ci sono dietro.

Ma nel caso del software che si deve far girare in emulazione sui POWER, si tratta di emulare solo il lato "user mode", non "tutta la cpu" e tutto l'hardware di basso livello, la cosa fa una differenza notevole e per questo è più semplice riordinare e fare l'interleave delle sequenze di istruzioni "native" che implementano le sequenze di istruzioni "emulate".

Originariamente inviato da cdimauro

Non credo. Roba come il power-gating, ad esempio, non ha nulla a che vedere con la semplicità di decodifica. Era a questo che mi riferivo quanto parlavo di tecnologie per la riduzione dei consumi.

Ma resta il fatto che un set d'istruzioni "semplice" è vantaggioso perché semplifica le cose a livello implementativo, semplificando indirettamente anche la circuiteria di gestione energia.

Originariamente inviato da cdimauro

Francamente non lo vedo proprio. VLIW per le GPU è un modello architetturale che è stato sostanzialmente abbandonato. Ciò che le GPU implementano oggi è il modello SIMD, o comunque ci sono molto vicini.

E' una questione di corsi e ricorsi tecnologici, nel senso che in base alle tecnologie ed al background teorico disponibile certe soluzioni sembrano più promettenti nel contesto di certe applicazioni, poi parametri e e contesto cambiano e si ripescano e rielaborano soluzioni che erano state abbandonate ma che nel nuovo contesto sembrano offrire dei vantaggi interessanti, ecc. ecc.

Ad esempio i CISC sono stati il risultato di successivi sviluppi tecnologici che permettevano di aggiungere sempre più funzionalità in hardware ed il termine CISC è nato per indicare il "problema" che si era venuto a creare e che l'approccio RISC si proponeva di risolvere (con architetture più snelle e con compilatori più avanzati).
Poi VLIW e TTA (Transport Triggered Architecture) sono stati un ulteriore tentativo di semplificare l'hardware spostando più oneri di ottimizzazione sui compilatori, anche se già le prime architetture di quel tipo resero chiaro che esistevano limiti riguardo quanto si poteva scaricare sul software e di quanto certi approcci potevano essere scalati in hardware (sempre nei limiti di tecnologie e background teorico disponibile).

Come del resto successe con l'approccio multicore del Cell con IBM che scommise troppo su quello che poteva fare il compilatore ... e perse.

Originariamente inviato da cdimauro

Inoltre nVidia ha dichiarato (mi pare di averlo letto sul loro blog) che ciò che lei vede è l'accoppiata CPU per calcolo "general purpose" e GPU per il calcolo (massicciamente) parallelo.

D'altra parte è anche logico che sia così: la GPU non è fatta per soppiantare il lavoro in cui una CPU semplicemente eccelle.

Quella è la versione ufficiale per i non addetti ai lavori, se cammin facendo vedranno opportunità migliori le seguiranno (o le stanno già seguendo).

Ad esempio, le GPU attuali eccellono in problemi in cui in genere l'approccio SIMD è quello ottimale.
Quindi cosa comporta per l'enfasi eccessiva che Intel pone sul lato SIMD delle sue cpu ?

Originariamente inviato da cdimauro

La cosa che a mio avviso cozza tremendemente è l'aver scelto un modello VLIW per la CPU, che si è dimostrato sempre poco performante per il calcolo "general purpose". Esempi illustri ne abbiamo avuti in passato: Itanium e... proprio Transmeta.

VLIW è solo un caso particolare di sistema MIMD in cui si espone esplicitamente il parallelismo interno a livello di unita funzionali.
In un certo senso "si delega al compilatore" il riordinamento e l'appaiamento delle istruzioni che in una cpu superscalare con esecuzione out-of-order viene gestito internamente.

Il modello VLIW "puro" usa istruzioni "larghe", senza "compilazione" a partire da un set d'istruzioni differente, ovviamente questo crea problemi in termini di dimensioni del codice, ecc. ecc.
Ed infatti i VLIW "reali" di solito implementano un formato più "compatto" che viene espanso in modo molto efficiente dal decoder delle istruzioni.

Per questo poi anche nell'Itanium si seguì l'approccio EPIC che tra le altre cose si basava su istruzioni "compatte" ottimizzate per essere "espanse" in istruzioni VLIW "interne" dal decoder (cosa che permetteva pure di aggiungere o togliere unita funzionali, entro certi limiti).

Nel caso dell'Itanium il vero problema non era tanto il lato VLIW/EPIC ma tutta la roba che avevano aggiunto a livello di funzionalità accessorie
e le poche ALU dedicate agli interi (nella prima implementazione) rispetto alle esigenze reali.

Nel caso di Transmeta invece il problema era il set d'istruzioni "compresso" utilizzato ed il codice che veniva eseguito (ottimizzato per un architettura decisamente non-VLIW e con relativamente pochi registri, visto che si trattava del set d'istruzioni x86 a 32bit.

Ma non era malaccio, il Crusoe a 700Mhz aveva le prestazioni di un Pentium III a 500Mhz ed aveva consumi relativamente bassi, solo che in quel periodo Intel poteva uscire per prima con i processi di produzione più avanzati (ed anche grazie a questo salire di prestazioni più rapidamente) e forniva incentivi a chi usava le sue cpu ed i suoi chipset in primo luogo in funzione anti-AMD (ma con Transmeta presa in mezzo dallo scontro allora in atto tra i due).

Originariamente inviato da cdimauro

Invece proprio Project Denver continua a dimostrare che l'ISA è più che mai importante. Infatti ARM, inclusa ARMv8, era così bella e rinomata che hanno pensato bene di "buttarla" e soppiantarla con una loro architettura VLIW.

Oppure ARMv8 è fatta così bene che si presta bene anche ad implementazioni VLIW, mentre altrettanto non si può dire di un altro set d'istruzioni.
In altre parole è più versatile.

L'implementazione "interna" è VLIW, ma l'architettura visibile al programmatore è ARMv8.

Guardacaso il set d'istruzioni scelto ha una decodifica semplice, molti registri "di uso generale" e molte più possibilità di parallelizzazione e riordino per esecuzione in-order grazie ad un modello logico che permette di ottenere un miglior parallelismo interno in fase di esecuzione.

[cdimauro]

Originariamente inviato da LMCH

Si, il dato è riferito al sistema completo
( S814-8286-41A ovvero IBM Power System S814)
http://www-01.ibm.com/common/ssi/Sho...st_locale=null

E' un server con socket dual-chip module (DCM)
in formato 4U rack-mount oppure desk-side
con un fottio di roba oltre alla cpu
(fino a 512GB di ram, fino a 18 unita di memoria "formato DVD bay"
espansioni slot PCIe hot-swap, doppio alimentatore hot-plug
4 porte USB 3.0, 2 USB 2.0, 2 link HMC 1Gbit, ecc. ecc. ).

OK, ma come il tizio del thread diceva, non c'erano montati nemmeno i dischi, e aveva soltanto 16GB di memoria installati. Quindi non penso che il consumo fosse dovuto al sistema stracarico di roba, ma al sistema quasi vuoto.

E' un peccato non avere altri dati per poter capire quanto incida realmente la CPU sul consumo.

Originariamente inviato da LMCH

Ma nel caso del software che si deve far girare in emulazione sui POWER, si tratta di emulare solo il lato "user mode", non "tutta la cpu" e tutto l'hardware di basso livello, la cosa fa una differenza notevole e per questo è più semplice riordinare e fare l'interleave delle sequenze di istruzioni "native" che implementano le sequenze di istruzioni "emulate".

Anch'io mi riferivo esclusivamente all'emulazione delle singole istruzioni, peraltro soltanto in user-space (negli 80186 e 65C02 non esiste il concetto di kernel-space: è tutto user ).

Purtroppo al momento non ho sotto mano il codice dei miei emulatori, ma appena lo recupero posto qualche spezzone, così sarà facile capire quali dipendenze ci sono in gioco e perché non posso essere eliminate riordinando il codice.

Ma resta il fatto che un set d'istruzioni "semplice" è vantaggioso perché semplifica le cose a livello implementativo, semplificando indirettamente anche la circuiteria di gestione energia.

Alla fine i decoder sono unità funzionali come le altre: blocchi di logica che puoi decidere di spegnere o accendere come faresti con una ALU, ad esempio. Io non vedo problemi dovuti alla complessità delle istruzioni, che è racchiusa nell'unità stessa. In ogni caso la micro-elettronica non è il mio campo, per cui mi fermo qui con le ipotesi.

E' una questione di corsi e ricorsi tecnologici, nel senso che in base alle tecnologie ed al background teorico disponibile certe soluzioni sembrano più promettenti nel contesto di certe applicazioni, poi parametri e e contesto cambiano e si ripescano e rielaborano soluzioni che erano state abbandonate ma che nel nuovo contesto sembrano offrire dei vantaggi interessanti, ecc. ecc.

Ad esempio i CISC sono stati il risultato di successivi sviluppi tecnologici che permettevano di aggiungere sempre più funzionalità in hardware ed il termine CISC è nato per indicare il "problema" che si era venuto a creare e che l'approccio RISC si proponeva di risolvere (con architetture più snelle e con compilatori più avanzati).

Hai ragione. Nulla vieta che in futuro certi concetti "dismessi" possano essere ripresi nuovamente.

Poi VLIW e TTA (Transport Triggered Architecture) sono stati un ulteriore tentativo di semplificare l'hardware spostando più oneri di ottimizzazione sui compilatori, anche se già le prime architetture di quel tipo resero chiaro che esistevano limiti riguardo quanto si poteva scaricare sul software e di quanto certi approcci potevano essere scalati in hardware (sempre nei limiti di tecnologie e background teorico disponibile).

Come del resto successe con l'approccio multicore del Cell con IBM che scommise troppo su quello che poteva fare il compilatore ... e perse.

Ecco, appunto: il nocciolo della questione sta tutto lì. Ed è il motivo per cui parecchio tempo fa si è passati da architetture in-order a OoO.

Non conoscevo l'esistenza delle architetture TTA. Immagino che si trovino in ambiti altamente specializzati.

Quella è la versione ufficiale per i non addetti ai lavori, se cammin facendo vedranno opportunità migliori le seguiranno (o le stanno già seguendo).

Senz'altro. E avendo nascosto la reale architettura, possono decidere di cambiare tutto quando e come vogliono.

Ad esempio, le GPU attuali eccellono in problemi in cui in genere l'approccio SIMD è quello ottimale.
Quindi cosa comporta per l'enfasi eccessiva che Intel pone sul lato SIMD delle sue cpu ?

Proprio perché Intel ha puntato tutto sul modello SIMD, e da ben prima che c'arrivassero le GPU: sono quasi 20 anni che le SIMD sono sbarcate su x86. E' un modello che si sposa molto bene con la sua architettura, visto che devi decodificare una sola istruzione, e poi replicare le operazioni diverse volte.

Le GPU ci sono arrivate adesso, e quindi s'è creata questa sovrapposizione / conflittualità.

Ovviamente ognuno spinge per la sua strada, ma alla fine, come per tutte le cose, contano i numeri commisurati ai costi per ottenerli. Ci sono ambiti in cui il modello SIMD di Intel si presta meglio di quello delle GPU, e viceversa. ISA, microarchitettura, e piattaforma hanno il loro peso in tutto ciò.

E' difficile affermare quale modello sia migliore in assoluto rispetto all'altro, e per questo è anche difficile prevedere quale s'imporrà alla fine.

Aggiungo, però, un'osservazione. Al momento se devi far eseguire un certo calcolo alla GPU, devi mettere in piedi un protocollo di offloading e condivisione delle risorse che penalizza molto le prestazioni complessive che si potrebbero ottenere se si potesse eseguire immediatamente il codice.
HSA di AMD & ARM nasce per migliorare molto quest'aspetto, ma non lo risolve del tutto, oltre al fatto, assolutamente non di poco conto, che risulta necessario riscrivere in parte il codice per poterne trarre beneficio.

Una CPU, invece, potrà sempre "partire subito" senza aspettare niente e nessuno per eseguire i calcoli, e questo ha e manterrà un suo vantaggio. Il problema, per la CPU, è di avere a disposizione un'unità SIMD abbastanza "massiccia" a cui smistare il lavoro. La direzione che Intel intrapreso è ovviamente proprio questa, vedi AVX e, soprattutto, il prossimo AVX-512.

VLIW è solo un caso particolare di sistema MIMD in cui si espone esplicitamente il parallelismo interno a livello di unita funzionali.
In un certo senso "si delega al compilatore" il riordinamento e l'appaiamento delle istruzioni che in una cpu superscalare con esecuzione out-of-order viene gestito internamente.

Il modello VLIW "puro" usa istruzioni "larghe", senza "compilazione" a partire da un set d'istruzioni differente, ovviamente questo crea problemi in termini di dimensioni del codice, ecc. ecc.
Ed infatti i VLIW "reali" di solito implementano un formato più "compatto" che viene espanso in modo molto efficiente dal decoder delle istruzioni.

Infatti. Ma immagino che l'architettura VLIW adottata da nVidia non faccia uso di alcuna compressione (come penso facesse anche Transmeta, coi suoi enormi bundle), visto l'enorme cache codice L1 adottata, come pure i ben 128MB di memoria che riserva solo per la cache di traduzione (per confronto, Transmeta ne usava 16MB).

Per questo poi anche nell'Itanium si seguì l'approccio EPIC che tra le altre cose si basava su istruzioni "compatte" ottimizzate per essere "espanse" in istruzioni VLIW "interne" dal decoder (cosa che permetteva pure di aggiungere o togliere unita funzionali, entro certi limiti).

Nel caso dell'Itanium il vero problema non era tanto il lato VLIW/EPIC ma tutta la roba che avevano aggiunto a livello di funzionalità accessorie
e le poche ALU dedicate agli interi (nella prima implementazione) rispetto alle esigenze reali.

Ma anche dopo la prima implementazione, non è che abbia brillato a livello prestazionale sul codice general purpose. La questione, a mio avviso, rimane sempre la stessa, che peraltro hai citato tu all'inizio: delegare parte della complessità del chip al software (compilatore in primis) non paga.

Nel caso di Transmeta invece il problema era il set d'istruzioni "compresso" utilizzato ed il codice che veniva eseguito (ottimizzato per un architettura decisamente non-VLIW e con relativamente pochi registri, visto che si trattava del set d'istruzioni x86 a 32bit.

A mio avviso l'ISA x86 non c'entra, perché non credo che siano partiti con un'architettura VLIW che non tenesse conto di quello che avrebbe dovuto fare principalmente (emulare x86, appunto). Sono convinto che il problema principale sia dovuto proprio all'architettura VLIW e ai suoi limiti intrinseci dovuti all'esecuzione in-order e all'impossibilità di poter gestire in scioltezza tutte le dipendenze.

Un'ISA come x86 ha pochi registri, ma li sfrutta parecchio, per cui si fa ampio uso di tecniche di register-renaming nelle microimplementazioni. Tutto ciò può facilmente venire implementato da un'ISA VLIW che ha parecchi registri a disposizione e può sfruttarli proprio per il renaming tracciando opportunamente il loro utilizzo.

Altra cosa, x86 ha una modalità d'indirizzamento della memoria molto complesso per un RISC (tranne per ARM, che ne mette a disposizione alcuni simili): Base + Indice * Scala (da 1 a 8) + Offset a 32 bit. Le micro-implementazioni x86 ne traggono vantaggio mettendo a disposizioni AGU dedicate soltanto a questo scopo, ottenendo ottimi risultati. Un'ISA VLIW immagino che abbia modalità d'indirizzamento estremamente semplici, ma dovendo emulare quelle di x86 e avendo a disposizione parecchi registri, può facilmente spalmare tutti questi calcoli nei suoi bundle & registri usati, magari intervallando i calcoli di più istruzioni x86.

Infine, x86 ha pure alcune istruzioni abbastanza complicate (ma che da tempo non si trovano più o sono molto rare) da richiedere l'esecuzione di parecchi calcoli che magari fanno uso di registri temporanei per i calcoli intermedi.

In sostanza, e per concludere il discorso, anche se x86 ha pochi registri, un'ISA VLIW potrebbe benissimo usare i suoi molti registri interni per accelerarne l'emulazione. Il problema rimane il solito: le dipendenze del codice sono comunque abbastanza rilevanti nel codice general-purpose, da mettere un freno alle prestazioni raggiungibili.

Ma non era malaccio, il Crusoe a 700Mhz aveva le prestazioni di un Pentium III a 500Mhz ed aveva consumi relativamente bassi, solo che in quel periodo Intel poteva uscire per prima con i processi di produzione più avanzati (ed anche grazie a questo salire di prestazioni più rapidamente) e forniva incentivi a chi usava le sue cpu ed i suoi chipset in primo luogo in funzione anti-AMD (ma con Transmeta presa in mezzo dallo scontro allora in atto tra i due).

E' vero che a causa di ciò anche Transmeta potrebbe essere rimasta coinvolta, ma all'epoca di quegli avvenimenti non era messa molto bene, per cui dubito che possa essere stata questa la causa. Intel e AMD avevano già intrapreso la strada del contenimento dei consumi, e a mio avviso Transmeta è rimasta strangolata da questo nuovo corso.

Quei dati delle prestazioni a mio avviso sono gonfiati tanto quanto quelli di nVidia per Project Denver. Ho recuperato gli estensivi test effettuati da Van's all'epoca, sia per Crusoe sia per Efficeon: mi pare che i risultati siano eloquenti (gli articoli sono pure molto tecnici, per cui consiglio di leggerli per l'analisi che viene fatta). Non soltanto le prestazioni reali sono decisamente scarse, ponendosi al di sotto del più scarso x86 (di Via), ma il risparmio sui transistor sostanzialmente non c'è, in particolare a causa dell'elevata quantità di cache L1 e L2 integrate, tant'è che le dimensioni del die di Efficeon sono superiori a tutte le altre soluzioni x86, a eccezione del P4. Altra cosa interessante, è che il clock è fermo inchiodato a 1Ghz: da un RISC, soprattutto VLIW, ci si sarebbe aspettati frequenze di gran lunga più elevate, no?

Last but not least, già il primo Crusoe aveva una cache L2 con linee di ben 128 byte = ben 1024 bit. Probabilmente è questo che ha frenato il clock, causa problematiche di clock skew.

Direi che almeno sull'approccio VLIW di Transmeta potremmo anche metterci sopra una bella pietra tombale.

Oppure ARMv8 è fatta così bene che si presta bene anche ad implementazioni VLIW, mentre altrettanto non si può dire di un altro set d'istruzioni.
In altre parole è più versatile.

L'implementazione "interna" è VLIW, ma l'architettura visibile al programmatore è ARMv8.

Guardacaso il set d'istruzioni scelto ha una decodifica semplice, molti registri "di uso generale" e molte più possibilità di parallelizzazione e riordino per esecuzione in-order grazie ad un modello logico che permette di ottenere un miglior parallelismo interno in fase di esecuzione.

Project Denver deve emulare anche ARM32 e Thumb-2 come minimo (penso anche ThumbEE), che non hanno assolutamente gli stessi pregi di ARMv8.

Certamente per l'ISA VLIW interna avranno tenuto conto di tutto ciò (non avranno realizzato un'ISA VLIW fine a se stessa), ma le 3 ISA ARM da emulare sono abbastanza diverse, sia a livello di decodifica sia d'esecuzione.

Per cui continuo a rimanere scettico, soprattutto per l'approccio VLIW adottato.

[LMCH]

Originariamente inviato da cdimauro

OK, ma come il tizio del thread diceva, non c'erano montati nemmeno i dischi, e aveva soltanto 16GB di memoria installati. Quindi non penso che il consumo fosse dovuto al sistema stracarico di roba, ma al sistema quasi vuoto.

E' un peccato non avere altri dati per poter capire quanto incida realmente la CPU sul consumo.

Nel thread a cui ti riferivi si parlava del consumo del sistema completo:
http://amigaworld.net/modules/newbb/...orum=33#737012

Non dei core, non della mainboard, ma del sistema completo.
Anche con "solo" 16GB di ram installata e nessun disco montato hai un sacco di roba oltre i core (tipo due alimentatori capaci di reggere il sistema in configurazione massima e che supportano l'hot-swap, da soli nella pura e semplice parte switching si mangiano almeno un 8% circa del consumo totale).

Originariamente inviato da cdimauro

Anch'io mi riferivo esclusivamente all'emulazione delle singole istruzioni, peraltro soltanto in user-space (negli 80186 e 65C02 non esiste il concetto di kernel-space: è tutto user ).

Purtroppo al momento non ho sotto mano il codice dei miei emulatori, ma appena lo recupero posto qualche spezzone, così sarà facile capire quali dipendenze ci sono in gioco e perché non posso essere eliminate riordinando il codice.

Ricorda che presupponendo che il codice binario venga eseguito su un S.O. "completo" e con processore che supporta la separazione tra user-space e kernel-space, paradossalmente l'emulazione lato user-mode diventa molto più semplice.
Niente ISR, niente istruzioni che su un 80186 o su un 6502 permettono di manipolare porte di I/O ed altra roba che sarebbero normalmente vietata in user-space, ecc.

Originariamente inviato da cdimauro

Un'ISA come x86 ha pochi registri, ma li sfrutta parecchio, per cui si fa ampio uso di tecniche di register-renaming nelle microimplementazioni. Tutto ciò può facilmente venire implementato da un'ISA VLIW che ha parecchi registri a disposizione e può sfruttarli proprio per il renaming tracciando opportunamente il loro utilizzo.

Ma in quel modo si carica di molto più lavoro il decoder misto hardware/software dell'architettura VLIW "con set d'istruzioni esterno non-VLIW".
Mentre invece con più registri (ma non troppi) visibili al compilatore è esso a svolgere il grosso dell'ottimizzazione e quindi la decodifica verso istruzioni VLIW è più semplice ed efficiente.

Per questo il set d'istruzioni ha ancora una discreta influenza sulle prestazioni ottenibili.

Originariamente inviato da cdimauro

Last but not least, già il primo Crusoe aveva una cache L2 con linee di ben 128 byte = ben 1024 bit. Probabilmente è questo che ha frenato il clock, causa problematiche di clock skew.

La cache L2 è due gerarchie di memoria al di sotto dei registri interni, quindi le ragioni per scegliere una certa dimensione non sono gli stessi dei registri interni.

La dimensione delle linee di cache L2 ed L3 viene cambiata di generazione in generazione in base all'ampiezza dei bus verso la ram e della frequenza massima di lavoro della cpu e della ram.

Attualmente negli x86 di Intel è stabile sui 64byte.
Il motivo principale dell'attuale "standardizzazione" a 64byte è legato alla tecnologia dei moduli di ram.
Le DDR hanno un canale che trasferisce 64bit per fronte (8byte), ma danno il massimo di prestazioni quando sono in burst mode, ovvero trasferiscono 4 gruppi di 8 byte consecutivamente (32byte totali).

A questo punto considera che la configurazione comune è avere DUE canali DDR e questo spiega la "standardizzazione" attuale su linee da 64byte.

Ma ad esempio in passato gli Itanium mcKinley avevano una L2 line size di 128byte ed i Pentium 4 avevano una L2 line size di 64byte ma con un opzione per leggere/scrivere due cache line consecutive (nel caso fossero stati abbinati ad un northbridge con memory controller con più di due canali o che supportasse una tipologia di ram con una banda di I/O più elevata).

[cdimauro]

Originariamente inviato da LMCH

Ricorda che presupponendo che il codice binario venga eseguito su un S.O. "completo" e con processore che supporta la separazione tra user-space e kernel-space, paradossalmente l'emulazione lato user-mode diventa molto più semplice.
Niente ISR,

Che problema ti porta dover gestire gli interrupt in user-space? Dovrebbe pure essere più semplice (niente registro di stato da aggiornare con la nuova modalità d'esecuzione).

niente istruzioni che su un 80186 o su un 6502 permettono di manipolare porte di I/O ed altra roba che sarebbero normalmente vietata in user-space, ecc.

Il 6502 ha tutto memory-mapped: niente porte di I/O.

Ma posso dirti che con l'80186 era una grandissima comodità il fatto che le periferiche fossero mappate quasi tutte nelle porte di I/O. In questo modo intercettare le scritture e letture alle varie periferiche era di gran lunga più efficente rispetto a fare la stessa cosa su un sistema che è interamente memory-mapped. Questo perché le porte sono di meno, e con una piccola jump-table riuscivo a gestire il tutto. Ma soprattutto per le letture e scritture non dovevo assolutamente mettermi lì a controllare se per caso l'indirizzo da leggere/scrivere andava a toccare una certa zona di memoria; puoi immaginare quanto lento possa essere tutto ciò, e quanto incida sulle prestazioni.

All'epoca mi ero dedicato esclusivamente all'emulazione della scheda grafica CGA, per cui l'emulazione era molto veloce proprio perché tutti i suoi registri erano mappati su porte di I/O e il suo framebuffer era mappato su 32K di memoria ma non c'erano cose strane da controllare (bastava leggere e scrivere).
EGA e VGA, invece, mi avrebbero costretto a effettuare il classico controllo per vedere se l'indirizzo di memoria rientrava fra $A0000 e $AFFFF, in quanto la memoria mappata per il framebuffer faceva uso di una sorta di bank switching per gestire la grafica a bitplane (il mode 13 a 256 colori, invece, era perfetto: 320x200 e accesso a singolo byte).

Emulare un sistema memory-mapped è un bagno di sangue a livello prestazionale...

Ma in quel modo si carica di molto più lavoro il decoder misto hardware/software dell'architettura VLIW "con set d'istruzioni esterno non-VLIW".
Mentre invece con più registri (ma non troppi) visibili al compilatore è esso a svolgere il grosso dell'ottimizzazione e quindi la decodifica verso istruzioni VLIW è più semplice ed efficiente.

Per questo il set d'istruzioni ha ancora una discreta influenza sulle prestazioni ottenibili.

Sì, me ne rendo conto, ma senza implementare nemmeno il register renaming perdi i vantaggi di intercettare i cambiamenti d'uso di un registro e generare codice ottimizzato. Tra l'altro anche RISC come PowerPC, se non ricordo male, usano il register renaming per migliorare un po' le prestazioni.

A questo punto se è difficile tenere traccia del register renaming, sarà relativamente difficile gestire anche le dipendenze delle istruzioni, che ha problematiche simili da risolvere.

Ricadiamo sempre sullo stesso punto: spostare sul software ciò che puoi fare in hardware rimane una pessima idea per l'impatto negativo che ha sulle prestazioni, visto che non si può ottimizzare il codice più di tanto.

La cache L2 è due gerarchie di memoria al di sotto dei registri interni, quindi le ragioni per scegliere una certa dimensione non sono gli stessi dei registri interni.

Vero, ma con la cache L2 non ti devi comunque interfacciare tramite la cache L1? Se trasferisci la stessa quantità di dati per ciclo di clock, anche la L1 avrà gli stessi problemi di clock skew, e così via anche per il resto dell'architettura.

Al solito, sai che questo non è il mio campo: le mie sono soltanto osservazioni da esterno alla materia.

La dimensione delle linee di cache L2 ed L3 viene cambiata di generazione in generazione in base all'ampiezza dei bus verso la ram e della frequenza massima di lavoro della cpu e della ram.

Attualmente negli x86 di Intel è stabile sui 64byte.
Il motivo principale dell'attuale "standardizzazione" a 64byte è legato alla tecnologia dei moduli di ram.
Le DDR hanno un canale che trasferisce 64bit per fronte (8byte), ma danno il massimo di prestazioni quando sono in burst mode, ovvero trasferiscono 4 gruppi di 8 byte consecutivamente (32byte totali).

A questo punto considera che la configurazione comune è avere DUE canali DDR e questo spiega la "standardizzazione" attuale su linee da 64byte.

E con le DDR4 che stanno arrivando i dati raddoppieranno.

Ma ad esempio in passato gli Itanium mcKinley avevano una L2 line size di 128byte ed i Pentium 4 avevano una L2 line size di 64byte ma con un opzione per leggere/scrivere due cache line consecutive (nel caso fossero stati abbinati ad un northbridge con memory controller con più di due canali o che supportasse una tipologia di ram con una banda di I/O più elevata).

Entrambi avevano l'esigenza di poter riempire velocemente le loro cache. Il primo quella del codice a causa dell'elevata dimensione dei suoi bundle e della scarsa densità di codice. Il secondo per la piccolissima cache dati L1 (era più orientato a macinare numeri grazie a clock elevato e SSE).

Comunque bene o male oggi tutti i sistemi hanno un'interfaccia con la memoria simile, perché poter contare su una banda elevata è diventata un'esigenza da soddisfare necessariamente, specialmente avendo una GPU integrata che va sfamata e ha parecchia fame di banda.

Secondo te tutto ciò non incide nel famigerato clock skew di cui abbiamo parlato? Voglio dire: le problematiche del memory controller si dovrebbero riversare sulla prima cache che incontra, ad esempio la L3, da questa alla L2, e alla L1. Non so che impatto potrebbe avere, poi, riguardo all'interfacciamento coi registri.

[LMCH]

Originariamente inviato da cdimauro

Il 6502 ha tutto memory-mapped: niente porte di I/O.

Emulare un sistema memory-mapped è un bagno di sangue a livello prestazionale...

Solo se le aree di memoria corrispondenti a registri di I/O, memoria video, ecc.
sono accessibili in user-mode (o non esiste differenziazione tra user-mode e kernel-mode).

Originariamente inviato da cdimauro

Sì, me ne rendo conto, ma senza implementare nemmeno il register renaming perdi i vantaggi di intercettare i cambiamenti d'uso di un registro e generare codice ottimizzato. Tra l'altro anche RISC come PowerPC, se non ricordo male, usano il register renaming per migliorare un po' le prestazioni.

E' un corso e ricorso storico, nel senso che a fasi alterne si pensa di poter eseguire in software (ahead-of-time e/o just-in-time) parte delle operazioni in precedenza non possibili o gestite in modo più rudimentale dall'hardware, poi con più gate disponibili ecc. ecc. si ritorna ad implementare in hardware una versione più evoluta di quello che si faceva prima, poi i gate aumentano ancora e sembra più conveniente aumentare le unita di esecuzione e ri-spostare a livello software certe cose, ecc. ecc.

L'esecuzione in-order oppure out-of-order sono scollegate concettualmente dalle architetture RISC,CISC, SIMD o MIMD che siano, ma il momento in cui conviene passare ad una delle due o ritornare all'altra dipende dalle tecnologie di implementazione disponibili e dall'architettura.

Nulla ad esempio vieta di realizzare una cpu VLIW con esecuzione out-of-order
(VLIW è un caso particolare di architettura MIMD), solo che di solito ci si aspetta che in un architettura VLIW sia il compilatore (ahead-of-time oppure just-in-time) a risequenziare il codice in modo da non rendere necessario o sufficientemente conveniente aggiugere il supporto per esecuzione out-of-order.
Inoltre se il set d'istruzioni "visibile al programmatore" non è vincolato ad un architettura VLIW, quando il ritorno in termini di costro/prestazioni di tale approccio non è più conveniente, diventa più facile passare ad altre architetture che usano lo stesso set d'istruzioni invece che avere un VLIW "out-of-order".

Mentre invece per i RISC ,grazie alle maggiori ottimizzazioni gestibili dal compilatore, solo dopo un certo punto è diventato conveniente aggiungere il supporto per il renaming ed esecuzione out-of-order e visto che avevano un loro set d'istruzioni, non si è parlato di "abbandono" dei RISC ma semplicemente di loro implementazione out-of-order, ecc.

[cdimauro]

Originariamente inviato da LMCH

Solo se le aree di memoria corrispondenti a registri di I/O, memoria video, ecc.
sono accessibili in user-mode (o non esiste differenziazione tra user-mode e kernel-mode).

Esattamente. Ed è, purtroppo, quello che capita spesso con un emulatore.

Tornando all'emulazione di software per i POWER, se ci si limita esclusivamente al caso che hai esposto, le prestazioni saranno buone.

Nulla ad esempio vieta di realizzare una cpu VLIW con esecuzione out-of-order
(VLIW è un caso particolare di architettura MIMD), solo che di solito ci si aspetta che in un architettura VLIW sia il compilatore (ahead-of-time oppure just-in-time) a risequenziare il codice in modo da non rendere necessario o sufficientemente conveniente aggiugere il supporto per esecuzione out-of-order.
Inoltre se il set d'istruzioni "visibile al programmatore" non è vincolato ad un architettura VLIW, quando il ritorno in termini di costro/prestazioni di tale approccio non è più conveniente, diventa più facile passare ad altre architetture che usano lo stesso set d'istruzioni invece che avere un VLIW "out-of-order".

Esattamente. Se devi realizzare un VLIW OoO la cui codifica delle istruzioni nel bundle non è compatta, ma ad esempio ognuna occupa "casualmente" 32-bit, ti ritrovi sostanzialmente con un RISC.

Io da un VLIW mi aspetto che sia in-order (riguardo alle istruzioni contenute nel bundle) e di trarre vantaggio dalla lunghezza del bundle per ottimizzare la codifica delle istruzioni.

Mentre invece per i RISC ,grazie alle maggiori ottimizzazioni gestibili dal compilatore, solo dopo un certo punto è diventato conveniente aggiungere il supporto per il renaming ed esecuzione out-of-order e visto che avevano un loro set d'istruzioni, non si è parlato di "abbandono" dei RISC ma semplicemente di loro implementazione out-of-order, ecc.

Idem per i CISC.

[LMCH]

Originariamente inviato da cdimauro

Idem per i CISC.

Ma con molti più problemi.
Non a caso ultimi "CISC" ancora in circolazione ed in evoluzione sono gli x86.

[cdimauro]

Sicuramente. C'erano pure luminari che avevano predetto che i CISC non avrebbero potuto avere una pipeline (immagino si riferissero a una superpipeline).

Intel col Pentium e Motorola col 68060 li smentirono. E prima ancora 80486 e 68040 avevano agguantato i RISC con prestazioni eccezionali su singola pipeline.

Purtroppo Motorola decise di mollare i CISC e buttarsi nell'impresa PowerPC, che però, a conti fatti, non so quanto le sia convenuto, visto come sono messi questi processori.

E' vero che oggi rimane soltanto Intel in grado di competere a tutti i livelli con un'architettura CISC. Fortunatamente. Ma anche i RISC si stanno sempre più focalizzando verso una sola architettura: ARM. Ne resteranno soltanto due.