Perché non ci sono microprocessori a 256 o 512 bit?

In un microprocessore a 8 bit il suo bus dati è composto da 8 linee dati. In un microprocessore a 16 bit il suo bus dati è composto da 16 linee dati e così via.

Perché non esiste né un microprocessore a 256 bit né un microprocessore a 512 bit? Perché non aumentano semplicemente il numero delle linee dati e creano un microprocessore a 256 bit o un microprocessore a 512 bit?

Qual è l'ostacolo che impedisce la creazione di un microprocessore a 256 bit o un microprocessore a 512 bit?

Pensaci. Cosa pensi esattamente di essere un processore "256 bit"? Cosa rende in primo luogo il bit-ness di un processore?

Penso che se non vengono fatte ulteriori qualifiche, il bit-ness di un processore si riferisce alla sua larghezza ALU. Questa è la larghezza del numero binario che può gestire nativamente in una singola operazione. Un processore "32 bit" può quindi operare direttamente su valori larghi fino a 32 bit in singole istruzioni. Il tuo processore a 256 bit conterrebbe quindi un ALU molto grande in grado di aggiungere, sottrarre, ORing, ANDing, ecc., Numeri a 256 bit in singole operazioni. Perché lo vuoi? Quale problema rende la ALU grande e costosa la pena avere e pagare, anche per quei casi in cui il processore conta solo 100 iterazioni di un ciclo e simili?

Il punto è che devi pagare per l'ampio ALU se lo usi molto o solo una piccola parte delle sue capacità. Per giustificare un ALU a 256 bit, dovresti trovare un problema abbastanza importante che può davvero trarre vantaggio dalla manipolazione delle parole a 256 bit in singole istruzioni. Anche se probabilmente puoi escogitare alcuni esempi, non ci sono abbastanza di questi problemi che fanno pensare ai produttori che avranno mai un ritorno sugli investimenti significativi richiesti per produrre un simile chip. Se ci sono problemi di nicchia ma importanti (ben finanziati) che possono davvero beneficiare di un ampio ALU, allora vedremmo processori altamente mirati molto costosi per quell'applicazione. Il loro prezzo, tuttavia, impedirebbe un ampio utilizzo al di fuori dell'applicazione ristretta per cui è stato progettato. Per esempio, se 256 bit rendessero possibili alcune applicazioni di crittografia per i militari, probabilmente emergerebbero processori specializzati a 256 bit che costano dai 100 ai 1000 dollari ciascuno. Non metteresti uno di questi in un tostapane, un alimentatore o persino un'auto però.

Dovrei anche essere chiaro che l'ampio ALU non solo rende ALU più costoso, ma anche altre parti del chip. Un ALU largo 256 bit significa anche che ci devono essere percorsi dati ampi 256 bit. Solo questo richiederebbe molta area di silicio. Questi dati devono provenire da qualche parte e andare da qualche parte, quindi dovrebbero essere necessari registri, cache, altra memoria, ecc., Affinché l'ampia ALU possa essere utilizzata in modo efficace.

Un altro punto è che puoi eseguire qualsiasi aritmetica di larghezza su qualsiasi processore di larghezza. È possibile aggiungere una parola di memoria a 32 bit in un'altra parola di memoria a 32 bit su un PIC 18 in 8 istruzioni, mentre è possibile farlo sulla stessa architettura ridimensionata a 32 bit in sole 2 istruzioni. Il punto è che una stretta ALU non ti impedisce di eseguire calcoli ampi, ma solo che i calcoli ampi richiederanno più tempo. È quindi una questione di velocità, non di capacità. Se guardi lo spettro di applicazioni che devono usare particolari numeri di larghezza, vedrai che pochissime richiedono parole a 256 bit. La spesa per accelerare solo quelle poche applicazioni con hardware che non aiuterà le altre non vale la pena e non fa un buon investimento per lo sviluppo del prodotto.

Bene, non conosco 256 o 512 bit, ma ho sentito parlare di un processore a 1024 bit (non riesco a trovarlo in questo momento). La parola è VLIW , per parole di istruzioni molto lunghe . Quindi questo è il bus di istruzioni, non la larghezza del bus di dati. I vantaggi sono che è possibile implementare il parallelismo a livello di istruzione (ILP) su larga scala.

Il mio primo incontro con ILP deve essere stato 20 anni fa con Motorola DSP, che aveva le istruzioni per eseguire un MAC (Moltiplica e ACcumulate) durante lo spostamento dei dati da e verso la memoria, in modo da poter eseguire un nuovo MAC sulla prossima istruzione, senza sprecare tempo tra due MAC per lo spostamento dei dati.
Oggi ci sono anche controller per scopi generici che offrono questa opzione. VLIW lo applica su una scala molto più elevata.

$^{20}$$\infty$

Ulteriori letture
VLIW Architecture

Il "testimone" di un microprocessore è generalmente definito in termini di dimensioni dei registri di uso generale. La dimensione determina quanti numeri un processore può gestire in modo nativo e quanta memoria può accedere. I numeri a 64 bit sono sufficienti per quasi tutti gli algoritmi e la quantità di memoria indirizzabile (16 milioni di terabyte) è sufficiente per un bel po 'di tempo a venire. Semplicemente non c'è alcun vantaggio nell'aumentare la dimensione dei registri di uso generale. D'altro canto, l'area delle unità logiche aritmetiche (ALU) utilizzata per eseguire operazioni sulle scale dei registri con il quadrato della quantità di bit. Una ALU a 256 bit sarebbe 16 volte più grande e significativamente più lenta.

D'altro canto, è opportuno ampliare il processore per consentire di eseguire contemporaneamente più piccole operazioni. In effetti i processori Intel Sandy Bridge e Ivy Bridge fanno proprio questo, hanno registri SIMD a 256 bit e possono eseguire due operazioni aritmetiche e un'operazione di memoria per ciclo su di essi. Quindi si potrebbe giustificare chiamarli processori a 256 bit, o addirittura a 768 bit, se si fosse un subdolo marketer che voleva piegare termini usati regolarmente.

In primo luogo, la dimensione in bit di un processore è generalmente determinata dall'architettura astratta visibile al programmatore del linguaggio macchina, non da dettagli di implementazione come la dimensione del bus dati.

Ad esempio, il Motorola 68000 è un processore a 32 bit. Dispone di registri dati a 32 bit e registri indirizzi a 32 bit. Ora, la prima versione di quella famiglia architettonica espone solo 24 bit di linee di indirizzo. Inoltre, esistono varianti che hanno solo un bus dati a 8 bit (quindi le operazioni di memoria a 32 bit vengono eseguite dal processore come cicli di accesso multipli).

Ora, per quanto riguarda la domanda, perché non passare a 256 e 512. I processori "nativamente" manipolano diversi tipi di tipi di dati, quindi è utile esaminare cosa significano individualmente 256 o 512 bit per ciascuno di questi tipi di dati. Abbiamo numeri interi, puntatori e tipi a virgola mobile.

1. Numeri interi: i programmi ottengono molti chilometri da numeri interi a 32 e 64 bit. Se 64 bit è una limitazione, la soluzione è avere interi bignum implementati dal software. I linguaggi di alto livello possono implementare tipi interi in modo tale che le operazioni si spostino senza problemi tra "fixnums" e "bignums". Ovviamente prendi un colpo di scena con i bignum, ma devi tenerlo presente nel quadro generale: quante operazioni in un programma sono operazioni bignum. I numeri a 256 o 512 bit non eliminano la necessità di bignum, aumentano solo il margine di testa prima che dobbiamo passare ai bignum. Se vuoi manipolare le chiavi pubbliche a 2048 bit, gli interi a 512 bit non lo faranno (ma un bignum con cifre a 512 bit potrebbe essere veloce).

2. Puntatori: i puntatori più ampi consentono due cose: spazi di indirizzi più ampi e metadati aggiuntivi memorizzati in un puntatore. Gli spazi degli indirizzi sono virtuali in questi giorni e quindi possono crescere anche se i ricordi non crescono. È stato proposto che se si dispone di puntatori a 128 bit, lo spazio degli indirizzi è così vasto che è possibile posizionare tutti i processi di spazio utente di un sistema operativo e il kernel, in punti casuali in un singolo spazio non protetto, e sono improbabili scontrarsi. Invece di creare semplicemente uno spazio di indirizzi più ampio, è possibile utilizzare puntatori più grassi per trasportare bit che non sono bit di indirizzo, ad esempio informazioni sull'oggetto referente (tipo, dimensione e altre informazioni) o informazioni relative alla sicurezza. Probabilmente esiste un "livello di grasso ottimale" per questo tipo di cose, e se dovessi indovinarlo, lo farei comunque con 128 bit. Non Non ha senso andare ai puntatori a 256 bit, non importa 512. I puntatori più grassi hanno uno svantaggio: gonfiano tutte le strutture di dati che contengono puntatori. E, generalmente, vuoi che i puntatori abbiano le stesse dimensioni, altrimenti hai bisogno di complicazioni nell'architettura del set di istruzioni (come segmenti di memoria) per cui hai quindi puntatori completi (descrittore di segmento e offset) o solo puntatori locali (offset all'interno di un segmento compreso) .

3. Tipi in virgola mobile: più bit nei numeri in virgola mobile significano maggiore precisione. Direi che i tipi a virgola mobile beneficiano maggiormente di una rappresentazione più ampia. Un tipo mobile a 256 o 512 bit migliorerà la stabilità del codice numerico e la qualità dei calcoli scientifici che richiedono molte iterazioni e accumulerà errori lungo il percorso. La precisione in virgola mobile non è la stessa della precisione in numeri interi: non possiamo separare il tipo in virgola mobile in intervalli come fixnums contro bignums. Una maggiore precisione in virgola mobile influisce sulla qualità di tutti i numeri inesatti, siano essi prossimi allo zero o di grande entità. Un numero maggiore di bit negli esponenti in virgola mobile può anche estendere notevolmente l'intervallo dei numeri in virgola mobile e molto più rapidamente rispetto all'aggiunta di bit in un intero bignum.

Per questi motivi, sospetto che la tendenza futura predominante sarà un aumento della larghezza dei numeri in virgola mobile dell'hardware, non necessariamente seguita da un aumento della larghezza dei puntatori e dei numeri interi.

Ricorda che i numeri in virgola mobile sono già stati in anticipo rispetto agli altri tipi in passato. Ad esempio, per un certo periodo abbiamo avuto una predominanza di processori a 32 bit che supportano double float IEEE a 64 bit. Questo perché mentre puoi fare molto con puntatori e numeri interi a 32 bit, i float a 32 bit sono molto limitati per qualsiasi lavoro numerico serio.

Una caratteristica molto, molto utile che sarebbe bello vedere emergere nelle rappresentazioni in virgola mobile sarebbe qualche bit di riserva per un tag di tipo. L'implementazione di tipi a virgola mobile in linguaggi dinamici di alto livello (in cui gli oggetti hanno tipo, ma le posizioni di archiviazione contengono valori di qualsiasi tipo) è una lotta perché, mentre i bit di riserva possono essere trovati in puntatori e oggetti simili a numeri interi per mettere parti di un identificando il tag di tipo, questo è difficile da fare con i numeri in virgola mobile. Quindi ciò che spesso accade è che i numeri in virgola mobile vengono allocati in heap. Alcuni schemi rubano bit dalla mantissa, quindi i tipi a virgola mobile in quella lingua perdono precisione rispetto ai galleggianti in altre lingue sulla stessa macchina.

In realtà non ti aiuta a fare nulla di utile. I numeri a 64 bit offrono una precisione sufficiente per quasi tutti gli scopi (i sistemi Intel hanno un virgola mobile a 80 bit), ma le linee extra aumentano i costi e il consumo di energia pur avendo un impatto negativo sulla velocità di clock.

Storicamente le CPU usano il numero minimo di bit che ha senso pratico per lo scopo previsto. Con l'avanzamento della tecnologia sono diventati possibili autobus e ALU più ampi, da cui l'aumento delle dimensioni degli autobus per servire una più ampia applicabilità:

• 4 bit: abbastanza per una cifra, quindi pratico per calcolatori (registratori di cassa in stile BCD), registratori di cassa, ecc. (Che è un'area piuttosto limitata)
• 8 bit: abbastanza per un carattere (ASCII), pratico per i sistemi di elaborazione del testo (che è un'area MOLTO ampia), anche per un suono di bassa qualità
• 16 bit: quando i 16 bit erano popolari gli indirizzi di memoria 2 ^ 16 erano una quantità ragionevole (almeno molto più ragionevole di 2 ^ 8 o 2 ^ 32). 16 bit produce una qualità audio abbastanza accettabile e la maggior parte dei convertitori A / D produce meno di 16 bit di risultato, quindi ha senso calcolare con tali valori in 16 bit
• 32 bit: 32 bit si adatta alla precisione della maggior parte (ma non di tutte) le quantità misurate dall'uomo e, a meno che non si tratti di database di grandi dimensioni, gli indirizzi 2 ^ 32 erano adeguati per la maggior parte degli scopi pratici.
• 64 bit: avere> 2 ^ 32 byte di memoria ora è pratico.
• 128 bit: in questo momento poco vantaggio rispetto a 32, tranne nella crittografia. Quando prevediamo più di 2 ^ 64 byte su un disco rigido? probabilmente non presto.

In realtà, tali processori esistono e sono comuni, a seconda di come si definisce il testimone. Ne stai quasi sicuramente usando uno adesso. Come ha spiegato Olin, non c'è molto da usare per i numeri a 256 bit, ma per quanto riguarda i numeri 4 x 32 bit? E se l'ALU potesse aggiungere 4 coppie di numeri a 32 bit contemporaneamente? Tali ALU (che conosco) furono implementati per la prima volta nei supercomputer vettoriali negli anni '70. La prima volta che ho mai posseduto un computer del genere è stato quando ho avuto uno degli Intel Pentiums con MMX.

Ricordi quei ragazzi?

I chip MMX avevano un'istruzione singola - set di istruzioni Multiple Data ( SIMD ), che consente di aggiungere 1 × 64 bit, 2 × 32 bit, 4 × 16 bit o 8 × 8 bit.

Ma non è niente. Una moderna scheda grafica ha una GPU (che era l'acronimo di Graphics Processing Unit, ma ora sta per General Processing Unit). Si tratta spesso di implementazioni SIMD ampie, in grado di eseguire filiali, carichi e archivi su 128 o 256 bit alla volta. La microarchitettura del prototipo Larrabee di Intel include più di due registri SIMD a 512 bit su ciascuno dei suoi core.

Si noti che SIMD non deve essere confuso con il multi-core. Ogni core di una CPU avrà il suo ampio ALU in grado di sommare un insieme di numeri interi.

Perché non ne abbiamo ancora bisogno.

Normalmente, il testimone (che definirei il numero di bit in un registro) si traduce più o meno direttamente nella quantità di memoria indirizzabile. Questo è ovviamente semplificato, poiché a seconda del processore, potrebbero esserci dei registri con una lunghezza 2 volte maggiore del testimone, oppure esistono tecniche per aggirare quelle limitazioni di memoria (qualcuno là fuori ricorda di aver programmato su finestre a 16 bit?).

"Perché non aumentano semplicemente il numero delle linee dati e creano un 256-bit"

Tutti i processori Intel che si adattano al socket LGA-2011 hanno, infatti, 256 pin di dati, collegandosi a 256 linee di dati sulla scheda madre che portano alla DRAM. Sarei un po 'sorpreso se il computer portatile o desktop più recente che hai usato non avesse almeno 256 linee di dati. Posso chiederti dove hai avuto questa idea sbagliata che "non ... semplicemente aumenta il numero di righe di dati"?

Il datasheet del socket LGA-2011 , sezione 6.1, indica che queste CPU hanno 256 pin di dati e 76 pin di indirizzo (indirizzo di banca + indirizzo di memoria).

perché non esiste un'applicazione che necessiti o abbia la possibilità di rappresentare i dati utilizzando più di 128 bit contemporaneamente.

e sapete, i processori multimediali e le schede grafiche arriveranno molto prima delle CPU della mainboard, solo perché con foto / video ha senso usare così grandi lunghezze di dati da elaborare contemporaneamente.

Un sistema informatico è nel suo significato una macchina informatica, che richiede alcuni input e alcune output. Dobbiamo soddisfare il computer in queste linee, quindi gli sviluppatori hanno raggiunto un punto di riferimento avendo 3 bus, vale a dire bus di indirizzo, bus di dati e bus di controllo. 1) Recupero bus indirizzo / Seleziona un indirizzo specifico nella memoria, per operazioni di lettura / scrittura. 2) Il bus dati recupera quindi i dati Presentare questi dati al / dal processore e dalla memoria per scopi di elaborazione / archiviazione. 3) Il bus di controllo crea un protocollo di controllo dell'interfaccia e chiede al sistema di rispettarlo.

Questi sono necessari per eseguire alcuni calcoli utili per un utente / server / client. In generale, le prestazioni (velocità di completamento dell'attività, meno anomalie, ecc.) Dipendono dalla pulizia dei colli di bottiglia nel sistema. vale a dire se la CPU è in grado di elaborare a una velocità molto più elevata rispetto alla velocità di trasferimento da un'unità disco fisso, il collo della bottiglia si verifica sull'HDD. Allo stesso modo dobbiamo avere una corretta velocità di elaborazione per una particolare velocità dei dati e larghezza del codice.

Fin dall'inizio, a causa di vari motivi come complessità H / W, costo, fabbisogno, algoritmi efficaci e il motivo principale Scopo del mercato sono i principali ostacoli per la produzione della larghezza del bus dati elevato, come indicato dall'host delle domande, ad esempio 256 bit o 512 bit. Questi sono possibili! Ma il requisito non è ancora presente, l'ambito del mercato non è ancora visibile con le esigenze di oggi e l'assenza di supporto software complementare.

Il processore a 256 bit indica la larghezza del bus dati, che un determinato processore è in grado di gestire o che l'ALU può elaborare in un'unica esecuzione. Abbiamo iniziato da 4 bit, quindi da 8,16,32 e attualmente da 64 e persino 128 bit, che sono gli attuali prodotti Market Scope.

Quindi, prima di porre queste domande, devi sempre vedere la domanda del mercato e la sua portata, nella storia è l'unico modo semplice per capire i modi di vita. Se non te lo puoi permettere come puoi acquistarlo? e se non puoi comprarlo, come può produrre il produttore? e se non riesce a produrre, allora non esiste esistenza per quel prodotto !!