Episodio 124 – la CPU

Episodio 124 – la CPU

 
 
00:00 / 17:09
 
1X
 

Il centro principe dedicato ai calcoli all’interno di un computer. Adesso ci sono periferiche che viaggiano molto più forti, ma un computer senza un CPU non può funzionare.

Pillole di Bit è un podcast indipendente realizzato da Francesco Tucci, se vuoi contribuire alla realizzazione puoi usare Paypal, Satispay, Patreon e il vecchio IBAN (contattami per chiedermelo).
Se vuoi metterti con contatto con me puoi scegliere tra diverse piattaforme:
Telegram (un gruppo dove discutere degli argomenti del podcast)
Twitter (il social che amo di più)
La mail (se mi vuoi scrivere in modo diretto e vuoi avere più spazio per il tuo messaggio)

Rispondo sempre

Se questo podcast ti piace, parlane con un amico e faglielo ascoltare!
Realizzo altri due podcast, provate a dar loro una chance: GeekCookies e A Torino


Ciao a tutti e bentornati all’ascolto di Pillole di Bit, questa è la puntata 124 e io sono, come sempre, Francesco.

Questa è la quarta parte di una mini serie all’interno del podcast dove ho intenzione di affrontare l’architettura e il funzionamento dei calcolatori.
Le puntate precedenti sono le seguenti: 117, 119 e 123, se non le avete ascoltate vi consiglio di recuperarle prima di ascoltare questa.
Siamo arrivati al cuore pulsante del computer, la CPU, che sta per Central Processing Unit, o più comunemente detto processore.
Con gli anni la centralità della CPU è cambiata tantissimo all’interno di un computer.
Se partiamo dall’epoca dell’8086, una delle prime CPU di Intel sulla cui architettura, attenzione, si basano le attuali CPU di ultime generazione i3, i5, i7 e così via, il processore era l’unico chip dedicato all’elaborazione dei dati all’interno di un computer.
Con il tempo si sono affiancati sistema di calcolo specifici e molto più potenti, il primo di questi è stato il coprocessore matematico che era specifico per effettuare calcoli in virgola mobile ed era indispensabile per far funzionare determinati software come i CAD.
Ma questa è storia antica.
Dal 486, in alcune versioni, il coprocessore matematico era compreso nel processore, da quel momento se ne è persa traccia ed è stato poi sempre integrato nella CPU, un po’ come l’ABS nelle auto, adesso la si compra e non ci si chiede se c’è, perché c’è su tutte.
Il secondo aiuto, estremamente più potete, è statà la scheda video 3D.
I calcoli per la grafica tridimensionale sono molto complessi e devono essere fatti sempre più in fretta e ce ne sono sempre di più, perché i poligoni a schermo sono sempre più numerosi, in modo da far sembrare la grafica sempre più realistica.
Qualcuno potrebbe porre una domanda molto banale:
Ma perché se le schede video sono diventate così potenti, le CPU restano al palo?
Per due motivi.
Il primo è che le CPU sono general purpose, cioè devono saper fare un po’ tutto. Le schede grafiche invece sono specializzate su poche cose e le fanno in modo molto veloce.
Immaginate di chiamare il tuttofare che sistema le cose a casa, gli chiedete di mettere una mensola e lui arriva con un piccolo trapano, una livella a mano e una matita. Fa il lavoro bene, ma ci mette un po’ di tempo e magari vi chiede una mano.
Se chiamate uno che di mestiere monta solo mensole lui arriva con la livella laser, un kit con i trapani che bucano e avvitano 3 tasselli insieme e in meno di 5 minuti la mensola è montata perfetta.
Tornando al calcolatore, la CPU deve saper fare un po’ di tutto, la scheda video deve saper fare solo i calcoli matematici per la grafica tridimensionale.
Il secondo motivo è per una questione di retro compatibilità. Gli attuali processori Intel sono compatibili con i primi 8086 per un sacco di funzioni, i programmi antichi, compilati per i vecchi calcolatori, in qualche modo funzionano ancora sugli attuali, senza dover fare troppe magie. Questa cosa è una specie di palla al piede che rallenta la possibilità evolutiva, in un qualche modo.
Ne parliamo quando affronteremo la compilazione, un po’ più in là in questa puntata.
La scheda video invece espone solo le API, chiamate software per chiedere alla scheda di fare calcoli. Questo permette all’hardware di cambiare architettura, basta non cambiare la funzionalità delle API.
Così è più facile evolvere, senza dubbio.
Ma perché la CPU ha questi limiti?
Il discorso potrebbe apparire complesso, cerco di affrontarlo in modo semplice, sorvolando su alcuni dettagli.
Se ancora non è chiaro scrivetemi, se sono troppo semplicisitico, i tecnici più esperti mi perdoneranno, almeno spero.

All’interno, un processore ha una struttura ben specifica, ad esempio, genericamente si può dire che c’è una zona dove sono memorizzate tutte le istruzioni che il processore può fare, una zona dove c’è l’elenco delle istruzioni da eseguire, detto stack, alcune zone di memoria accessibili più o meno velocemente, i registri e la cache di primo e secondo livello.

Istruzioni. Che sono le istruzioni?
Vi ricordate la questione del general purpose o dello specifico? ecco, è questa.
Una CPU generica ha memorizzate al suo interno una serie di istruzioni che può eseguire, come ad esempio

—> prendi questi due numeri, fai la somma e memorizza il risultato
—> sposta questo valore da qui a lì
—> verifica la condizione e se vera vai là

Un esempio facile, o almeno spero
nel linguaggio di programmazione avete scritto qualcosa del tipo
Alla variabile A assegni il numero 10
Alla variabile B assegni il numero 20
Alla variabile C assegni la somma di A e B

Il programma, compilato (della compilazione ne parliamo un’altra volta) e eseguito farà succedere le seguenti cose, sempre molto semplificate

Nello stack di esecuzione del programma vengono inserite delle istruzioni. Ogni cella di memoria dello stack contiene dei bit, quindi ogni istruzione è convertita in un valore binario per venir caricato nello stack

La prima istruzione deve caricare il valore della variabile A dalla sua cella di memoria in RAM a una cella interna, per poterci lavorare più velocemente, diciamo in un registro
La seconda carica il calore della variabile B in un altro registro
La terza fa la somma tra i due registri di cui prima e la mette in un nuovo registro
La quarta istruzione, finalmente, copia il valore dell’ultimo registro nella cella di memoria dedicata alla variabile C

Una cosa importante è capire per ogni operazione quanti cicli di clock servono, ne parlo tra un attimo.

Il trasferimento dati tra la memoria e la CPU viene fatta attraverso un bus di dati, quello che abbiamo visto nelle puntate precedenti. La chiamata essenzialmente dice “ciao memoria, voglio che mi rendi disponibile il valore che hai all’indirizzo di memoria che ti dico io”

Adesso entra in gioco la quantità di bit del sistema. Chi ha la mia età ha vissuto con processori da 8 bit fino agli attuali a 64. Questo cosa vuol dire?
Che il bus della CPU ha quella quantità di canali, 8, 16, 32 o 64.
Questo limita la quantità di indirizzamento e la quantità di dati.
Un processore a 8 bit può manipolare dati a 8 bit alla volta e soprattutto può indirizzare, con una sola chiamata 2 alla ottava indirizzi di celle di memoria, quindi 256, pochini, eh?
Un processore a 32 bit arriva a 4 miliardi e 300 milioni di celle di memoria. Adesso è chiaro perché i sistemi a 32 bit non potevano avere più di 4GB di RAM.
I processori attuali, a 64 bit indirizzano 18 mila miliardi di miliardi di celle di memoria, spazio ce n’è, ma a un certo punto finirà pure quello e uscirà un videogame che avrà bisogno di una CPU a 128 bit.

Quindi quando si scrive un programma, questo viene compilato, con software specifici per ogni CPU e ogni sistema operativo in modo tale che il linguaggio capibile per noi umani sia chiaro per la CPU che sta sotto.

Quello che compilo per WIndows non funziona su altri sistemi operativi.
Quello che compilo per Intel non funzionerà con CPU di altro tipo, come ad esempio le ARM, di cui si parla tanto.

Visto che la compilazione è una procedura a senso unico, perché decompilare per tornare all’esatto codice di partenza è praticamente impossibile, una cosa compilata per una certa CPU dovrà essere ricompilata, avendo quindi il codice sorgente, per un’altra CPU.
Perché questo?
Perché le diverse architetture hanno il set di istruzioni molto diverso tra di loro e hanno la struttura interna tra registri e cache profondamente diversa.

Quindi, in parole semplici, se scaricate la Ubuntu per il PC sarà stata compilata per l’architettura 8086 di Intel, se prendete quella per Raspberry Pi la compilazione è avvenuta per architettura ARM.
Tra di loro non sono scambiabili.

Non so se vi ricordate, qualche anno fa Apple passò dai processori 68000 di Motorola ai processori Intel, per anni ha gestito due versioni del sistema operativo, una per un tipo di processore e l’altro per quello nuovo. Quando ha smesso di supportare l’architettura vecchia, i vecchi Mac non sono stati più aggiornabili.
 
Torno un attimo alle performace del processore. Prima vi dicevo che le operazioni sono misurate in quanti cicli di click servono per farla.
Cos’è il ciclo di clock?
Avete mai notato che a fianco delle specifiche di ogni CPU c’è l’indicazione di una frequenza? 
Il 386 andava a 33MHz, un attuale i5 di decima generazione viaggia a 4GHz.
Questo vuol dire che c’è un segnale che batte il tempo, un po’ come il metronomo di chi studia musica. Per il 386 batte 33 milioni di volte al secondo, per l’i5 4 miliardi di volte.
Ogni battuta del clock, il processore fa qualcosa, il problema è che determinate operazioni necessitano più di un battito di clock, quindi non tutte le operazioni ci mettono lo stesso tempo, leggere un dato dalla RAM ha bisogno di molti più cicli di clock rispetto che fare una somma tra due valori messi nei registri, giusto per fare un esempio.
L’ottimizzazione delle CPU, oltre che aumentare la frequenza, è nell’abbassare il tempo che serve per ogni istruzione.
Descrivere cosa succede internamente, fidatevi, è un vero casino.

Se volete incasinare ancora di più le cose, ecco che compaiono le CPU con più core, quindi ad ogni ciclo di clock la CPU può fare più cosa diverse, una per ogni core.
La parte complessa, oltre al gestire il flusso di dati tra i singoli core, la memoria, la cache e i registri, è capire come distribuire il lavoro, questo è un mestiere che devono fare i compilatori.
Come funziona la gestione di più core? Posso assegnare un processo a un core e un altro processo al core fratello, ad esempio.
Ma potrei anche decidere che un determinato processo usi tutti i core di una CPU, a questo punto devo eseguire più thread, cioè esecuzioni parallele dello stesso processo. In questo caso si deve stare molto attenti a come vengono gestiti i dati tra i vari thread, per evitare che il thread A aspetti un dato dal thread B, che ne aspetta uno dal thread C. E se il Thread C aspetta da A tutto è bello che piantato. In gergo tecnico si dice starvation, cioè muore di fame.

Un’ultima cosa prima di chiudere questa ennesima puntata lunghissima. E’ importante sapere che il processore non è magico, ma solo molto veloce, quindi fa una e una sola cosa per volte e per core, la sensazione di avere un sistema che fa mille cose contemporaneamente è solo perché il processore fa una cosa per volta per pochi microsecondi. E questa cosa è tutta gestita dal sistema operativo.


I contatti
Vi ricordo, come sempre, che trovate tutte le informazioni e i contatti relativi a questo podcast sul sito pillole di bit con il punto prima dell’IT.
C’è l’intero script della puntata da rileggere e i link utili in modo che possiate usufruirne in maniera comoda. 
Potete contattarmi in un sacco di modi diversi:
l’account twitter @pilloledibit
la mail pilloledibit@gmail.com
il gruppo telegram www.pilloledib.it/telegram    
il canale discord www.pilloledib.it/discord 
Il form sul sito

Rispondo a tutti e sono attivo nei due gruppi di discussione

Se volete partecipare attivamente al podcast, trovate sul sito i link per le donazioni, ci sono molte piattaforme e modalità, scegliete quella che vi piace di più. Se donate almeno 5€ compilate il form con i vostri dati e vi spedisco gli adesivi a casa.

Ringrazio tantissimo chi sta partecipando, chi ha partecipato e chi sta pensando di farlo.

Si può ascoltare il podcast in live mentre lo sto registrando, normalmente la domenica sera alle 21:30, al termine della puntata chi c’è può fare domande e, se lo so, rispondo.
La diretta può essere seguita in più modi, perché le cose semplici io non le faccio mai.
Su Discord e a fine puntata potete intervenire a voce ponendo le domande
Su spreaker, il link è disponibile dalle 21 e c’è la chat per intervenire, la leggo solitamente a fine puntata
Direttamente nella home di pilloledib.it, che non è altro che un player diverso di Spreaker.

Registro altri due podcast, Geekcookies e A Torino, se vi va potete fare un salto anche lì, trovate tutte le informazioni partendo dal mio sito personale www.iltucci.com

Il tip
Nel mondo le CPU in commercio sono centinaia e centinaia, saper leggere tutti i dati di targa quindi non è proprio facile, soprattutto per chi deve decidere cosa comprare, qual è la scelta migliore.
C’è un sito che fa i benchmark delle CPU, quindi le stressa un po’ e riassume le loro prestazioni con un indice numerico, molto più facile da capire.
Quindi se dovete scegliere un PC e uno ha un i5-9768 e l’altro un i5-9534Y (le sigle sono a caso), andate sul sito cpubenchmark.net, cercate i due modelli di CPU e fate il confronto, così sapete subito quale è più potente e se la differenza di spesa ne vale la pena. Il link come al solito è nelle note dell’episodio.

Bene è proprio tutto, non mi resta che salutarvi e darvi appuntamento alla prossima puntata.

Ciao!