[cdimauro]

Originariamente inviato da LMCH

Perche grazie al set d'istruzioni utilizzato aggiungevano (ricorda che lo avevano già fatto) nuove istruzioni e nuovi registri in modo più flessibile.

Le nuove, ma pochissime, istruzioni vettoriali facevano uso dei registri interi.

Il motivo per cui intendevano aggiungere istruzioni SIMD con registri a 128bit era perche con essi avrebbero aggiunto nche il supporto in hardware dei float a 128bit (con "gratis" altre istruzioni SIMD che tornavano utili).

Per cui probabilmente avrebbero esteso i registri dell'FPU a 128-bit, anziché aggiungere un banco di nuovi registri a 128-bit.

Non si erano spinti oltre perche se si esagera con l'ampiezza dei registri si hanno maggiori limitazioni sulla frequenza operativa massima (per tener sotto controllo il clock skew) e su quanti thread si possono eseguire in simultanea.

Il passaggio da SSE (128-bit) ad AVX (256-bit) non ha visto una diminuzione della frequenza massima dei processori (anzi, è leggermente migliorata; ovviamente mi riferisco a parità di processo produttivo utilizzato dalle rispettive famiglie di processori). Per quello da AVX ad AVX-512 (512-bit) si dovrà attendere l'arrivo di Broadwell prima, e Skylake dopo (in modo da confrontare le frequenze a parità di processo produttivo utilizzato) per controllare (ma sono fiducioso che non ci saranno sorprese).

Riguardo al numero di thread, l'unica famiglia di processori x86 che ne adotta 4 per core è Xeon Phi, che ha registri SIMD a 512-bit, ma frequenze ridotte per contenere i consumi. Per cui non si può prendere a campione per analizzare l'impatto della lunghezza dei registri SIMD sul numero di thread.

I progettisti di Alpha privilegiavano il multithreading perchè il software che facevano girare traeva più vantaggio senza dover ricompilare dal multithreading che dalle istruzioni SIMD, inoltre questo permettera di scalare maggiormente di prestazioni senza dover cambiare il set d'istruzioni per accomodare registri SIMD più grandi in mancanza di alternative migliori come attualmente fa Intel.

Inoltre con il multithreading si possono aggiungere ulteriori thread o rimuoverli completamente dall'implementazione mantenendo la retrocompatibilita totale con il software già sviluppato, mentre è più complicato "tornare indietro" se si cambia il set d'istruzioni (e diventa sempre più complicato "andare avanti" aggiungendo nuove istruzioni).

Eppure l'approccio multithreading spinto di EV8 non ha attecchito, e molte famiglie di processori non l'hanno adottato, preferendo, invece, ricorrere all'integrazione di un'unità SIMD. Evidentemente il primo porta molti più problemi rispetto al secondo.

Non si risolve tutto a colpi di registri SIMD sempre più ampi.

I numeri al momento dimostrano che danno una grande mano.

Intel segue una certa strada perche le sono precluse altre opzioni che invece erano disponibili per gli Alpha.

Anche altri produttori di processori non hanno seguito la strada di Alpha, preferendo passare dalla via dell'unità SIMD. E Alpha stesso avrebbe adottato quest'ultima.

Finora aumentare l'ampiezza dei registri SIMD ha dato ragione a Intel, come pure l'assenza di implementazioni multithreading estremamente aggressive da parte di altri vendor (eccetto IBM con POWER8 che dovrebbe essere confrontabile con EV8, se non ricordo male, ma presenta consumi elevatissimi ed è pensato per ambiti molto specializzati).

La microelettronica non è il mio campo, ma a naso direi che quest'ultima soluzione crea decisamente più problemi rispetto alla prima, ed è il motivo per cui sia praticamente scomparsa a favore della prima soluzione.