Non capisco perché i produttori di CPU producano chip multi-core. Il ridimensionamento di più core è orribile, questo è altamente specifico dell'applicazione e sono sicuro che puoi indicare un certo programma o codice che funziona alla grande su molti core, ma il più delle volte il ridimensionamento è spazzatura. È uno spreco di spazio in silicio e uno spreco di energia.

I giochi, ad esempio, non usano quasi mai più di quattro core. Le simulazioni scientifiche e ingegneristiche come Ansys o Fluent hanno un prezzo in base al numero di core su cui è in esecuzione il PC, quindi paghi di più perché hai più core, ma il vantaggio di più core diventa davvero scarso oltre 16 core, ma hai questi 64 core stazioni di lavoro ... è uno spreco di denaro ed energia. È meglio acquistare un riscaldatore da 1500 W per l'inverno, molto più economico.

Perché non fanno una CPU con un solo core?

Penso che se realizzassero un equivalente a un core di una CPU a otto core, un core avrebbe un aumento dell'800% dell'IPC, in modo da ottenere le massime prestazioni in tutti i programmi, non solo quelli ottimizzati per più core. Più IPC aumenta le prestazioni ovunque, è un modo affidabile e semplice per aumentare le prestazioni. I core multipli aumentano le prestazioni solo in un numero limitato di programmi e il ridimensionamento è orribile e inaffidabile.

Il problema sta nel presupposto che i produttori di CPU possono semplicemente aggiungere più transistor per rendere un singolo core della CPU più potente senza conseguenze.

Per fare di più una CPU, devi pianificare cosa comporta fare di più. Ci sono davvero tre opzioni:

1. Fai funzionare il core con una frequenza di clock più alta - Il problema è che stiamo già colpendo i limiti di ciò che possiamo fare.

   Il consumo di energia e quindi la dissipazione termica aumenta con la frequenza: se si raddoppia la frequenza, si raddoppia nominalmente la dissipazione di potenza. Se aumenti la tensione la tua dissipazione di potenza aumenta con il quadrato della tensione.

   Le interconnessioni e i transistor hanno anche ritardi di propagazione dovuti alla natura non ideale del mondo. Non puoi semplicemente aumentare il numero di transistor e aspettarti di essere in grado di funzionare alla stessa frequenza di clock.

   Siamo inoltre limitati da hardware esterno, principalmente RAM. Per rendere più veloce la CPU, è necessario aumentare la larghezza di banda della memoria, eseguendola più velocemente o aumentando la larghezza del bus dati.

2. Aggiungi istruzioni più complesse - Invece di correre più velocemente, possiamo aggiungere un set di istruzioni più ricco - attività comuni come la crittografia ecc. Possono essere indurite nel silicio. Invece di prendere molti cicli di clock per calcolare nel software, abbiamo invece l'accellerazione hardware.

   Questo è già stato fatto sui processori Complex Instruction Set (CISC). Guarda cose come SSE2, SSE3. Un singolo core della CPU oggi è molto più potente di un core della CPU anche solo 10 anni fa, anche se eseguito alla stessa frequenza di clock.

   Il problema è che, quando si aggiungono istruzioni più complicate, si aggiunge più complessità e si ingrandisce il chip. Di conseguenza la CPU diventa più lenta : le frequenze di clock raggiungibili diminuiscono con l'aumentare dei ritardi di propagazione.

   Queste istruzioni complesse inoltre non ti aiutano con compiti semplici. Non è possibile rafforzare ogni possibile caso di utilizzo, quindi inevitabilmente grandi parti del software in esecuzione non trarranno vantaggio dalle nuove istruzioni e, di fatto, saranno danneggiate dalla conseguente riduzione della frequenza di clock.

   È inoltre possibile aumentare le larghezze del bus dati per elaborare più dati contemporaneamente, tuttavia, ciò aumenta la CPU e si ottiene un compromesso tra il throughput ottenuto tramite bus dati più grandi e il calo della frequenza di clock. Se hai solo piccoli dati (es. Numeri interi a 32 bit), avere una CPU a 256 bit non ti aiuta davvero.

3. Rendi la CPU più parallela - Invece di provare a fare una cosa più velocemente, invece fai più cose contemporaneamente. Se l'attività che si sta eseguendo si presta ad operare su più cose alla volta, allora si desidera una singola CPU in grado di eseguire più calcoli per istruzione (Single Instruction Multiple Data (SIMD)) o avere più CPU che possono eseguire ciascuna una calcolo.

   Questo è uno dei driver chiave per le CPU multi-core. Se hai più programmi in esecuzione o puoi dividere il tuo singolo programma in più attività, avere più core della CPU ti consente di fare più cose contemporaneamente.

   Poiché i singoli core della CPU sono blocchi effettivamente separati (blocco delle cache e delle interfacce di memoria), ogni singolo core è più piccolo del singolo core monolitico equivalente. Poiché il core è più compatto, i ritardi di propagazione si riducono e ogni core può essere eseguito più velocemente.

   Se un singolo programma può trarre vantaggio dall'avere più core, ciò dipende interamente da ciò che quel programma sta facendo e da come è stato scritto.

Oltre alle altre risposte, c'è un altro elemento: i rendimenti dei chip . Un moderno processore ha diversi miliardi di transistor al suo interno, ognuno di questi transistor deve funzionare perfettamente affinché l'intero chip funzioni correttamente.

Realizzando processori multi-core, è possibile partizionare in modo pulito gruppi di transistor. Se esiste un difetto in uno dei core, è possibile disabilitare quel core e vendere il chip a un prezzo ridotto in base al numero di core funzionanti. Allo stesso modo, è anche possibile assemblare i sistemi dai componenti validati come in un sistema SMP.

Praticamente per ogni CPU acquistata, la vita è diventata un modello premium di fascia alta per quella linea di processori. Ciò che si ottiene dipende da quali parti di quel chip funzionano in modo errato e disabilitato. Intel non produce processori i3: sono tutti i7 difettosi, con tutte le funzionalità che separano le linee di prodotti disabilitate perché non hanno superato i test. Tuttavia, le porzioni che funzionano ancora sono ancora utili e possono essere vendute per molto più economiche. Qualcosa di peggio diventa bigiotteria portachiavi.

E i difetti non sono rari. Creare perfettamente quei miliardi di transistor non è un compito facile. Se non hai l'opportunità di utilizzare selettivamente porzioni di un determinato chip, il prezzo del risultato aumenterà, molto velocemente.

Con un solo processore über, la produzione è tutto o niente, con conseguente processo molto più dispendioso. Per alcuni dispositivi, come i sensori di immagine per scopi scientifici o militari, dove è necessario un sensore enorme e tutto deve funzionare, i costi di tali dispositivi sono così enormi che solo i budget a livello statale possono permetterseli.

Dipendenza dai dati

È abbastanza facile aggiungere più istruzioni per clock rendendo un chip "più ampio" - questo è stato l'approccio "SIMD". Il problema è che questo non aiuta la maggior parte dei casi d'uso.

Esistono circa due tipi di carico di lavoro, indipendenti e dipendenti. Un esempio di carico di lavoro indipendente potrebbe essere "dati due sequenze di numeri A1, A2, A3 ... e B1, B2, ... ecc., Calcola (A1 + B1) e (A2 + B2) ecc." Questo tipo di carico di lavoro è visibile in computer grafica, elaborazione audio, apprendimento automatico e così via. Molto di questo è stato dato alle GPU, che sono progettate appositamente per gestirlo.

Un carico di lavoro dipendente potrebbe essere "Dato A, aggiungi 5 ad esso e cerca quello in una tabella. Prendi il risultato e aggiungi 16 ad esso. Cerca quello in una tabella diversa."

Il vantaggio del carico di lavoro indipendente è che può essere suddiviso in molte parti diverse, quindi più transistor aiutano a farlo. Per i carichi di lavoro dipendenti, questo non aiuta affatto: più transistor possono solo rallentarlo . Se devi ottenere un valore dalla memoria, è un disastro per la velocità. Un segnale deve essere inviato attraverso la scheda madre, viaggiando a velocità ridotta, la DRAM deve caricare una riga e attendere il risultato, quindi rispedirlo indietro. Questo richiede decine di nanosecondi. Quindi, dopo aver fatto un semplice calcolo, devi inviare il prossimo.

Gestione energetica

I nuclei di riserva vengono spenti per la maggior parte del tempo. In effetti, su un sacco di processori, non è possibile eseguire tutti i core per tutto il tempo senza che la cosa prenda fuoco, quindi il sistema li spegne o li esegue il downclock per te.

Riscrivere il software è l'unico modo in avanti

L'hardware non può convertire automaticamente carichi di lavoro dipendenti in carichi di lavoro indipendenti. Nemmeno il software. Ma un programmatore che è pronto a ridisegnare il proprio sistema per trarre vantaggio da molti core potrebbe proprio.

Tornando indietro nel tempo, i processori non erano in grado di funzionare così velocemente. Di conseguenza, se si desidera eseguire una maggiore elaborazione, sono necessari più processori. Questo potrebbe essere con un coprocessore matematico o potrebbe essere semplicemente con più dello stesso processore. Il miglior esempio di questo è l'Inmos Transputer degli anni '80, che è stato specificamente progettato per l'elaborazione massicciamente parallela con più processori collegati insieme. L'intero concetto dipendeva dal presupposto che non esistesse un modo migliore per aumentare la potenza di elaborazione che aggiungere processori.

Il problema è che il presupposto era (temporaneamente) errato. È inoltre possibile ottenere una maggiore potenza di elaborazione facendo eseguire un numero maggiore di calcoli a un processore. Intel e AMD hanno trovato modi per aumentare la velocità di clock e, come dici tu, è molto più semplice mantenere tutto su un processore. Il risultato fu che fino alla metà degli anni 2000, il veloce processore single-core possedeva il mercato. Inmos morì nei primi anni '90 e tutta la loro esperienza morì con loro.

I bei tempi dovevano finire però. Una volta che la velocità di clock è salita a GHz non c'era davvero spazio per andare oltre. E indietro siamo andati di nuovo a più core. Se davvero non riesci ad andare più veloce, la risposta è più core. Come dici tu, però, non è sempre facile usare quei core in modo efficace. In questi giorni stiamo molto meglio, ma siamo ancora lontani dal renderlo facile come ha fatto il Transputer.

Naturalmente ci sono anche altre opzioni di miglioramento: potresti invece essere più efficiente. SIMD e set di istruzioni simili ottengono una maggiore elaborazione per lo stesso numero di tick di clock. DDR porta i tuoi dati dentro e fuori dal processore più velocemente. Tutto aiuta. Ma quando si tratta di elaborazione, torniamo agli anni '80 e di nuovo più core.

Buona domanda, o almeno una con una risposta interessante. Parte di questa risposta rappresenta un mondo in cui le CPU possono scalare in modo efficiente in larghezza anziché con più core separati. I modelli di licenza / prezzo sarebbero diversi!

Il resto spiega perché non possono. Sommario:

• Il costo di più core si avvicina a linearmente
• Il costo dell'ampliamento della scala della pipeline superscalare di 1 core ~ ​​quadraticamente ~ Questo è fattibile con una forza bruta sufficiente, fino a un certo punto. Le prestazioni a thread singolo sono molto importanti per l'uso interattivo (la latenza end-to-end è importante, non solo la velocità effettiva), quindi le attuali CPU high-end di fascia alta pagano quel prezzo. ad es. Skylake (4 in larghezza), Ryzen (5 o 6 in larghezza) e Apple A12 (7 in larghezza per i core più grandi, 3 in larghezza per i core a basso consumo energetico)
• Gravi decrementi dell'IPC si riducono semplicemente allargando la pipeline oltre 3 o 4, anche con l'esecuzione fuori servizio per trovare l' ILP . I fallimenti delle filiali e quelli della cache sono difficili e bloccano ancora l'intera pipeline.

• Non hai menzionato la frequenza, solo IPC, ma anche la frequenza di ridimensionamento è difficile. Una frequenza più alta richiede una tensione più elevata, quindi le scale di potenza con frequenza a cubetti : ^1dalla frequenza direttamente e ^2dalla tensione. (Il condensatore immagazzina bilance di energia con V ^ 2 e la maggior parte della potenza dinamica oltre la corrente di dispersione proviene dalla carica di pompaggio nei carichi capacitivi di cancelli FET + fili.)

  Prestazioni = frequenza volte IPC. (All'interno della stessa architettura. WIDE SIMD consente di eseguire lo stesso lavoro con meno istruzioni e alcuni ISA sono più densi di altri, ad esempio MIPS spesso richiede più istruzioni per eseguire lo stesso lavoro di x86 o AArch64.)

I costi sono in area die (costo di produzione) e / o potenza (che limita indirettamente la frequenza perché il raffreddamento è difficile). Inoltre, ridurre la potenza e le prestazioni per Watt è un obiettivo in sé, soprattutto per dispositivi mobili (batteria) e server (densità di potenza / costi di raffreddamento / costi di elettricità).

Prima che il multi-core per socket fosse una cosa, avevi sistemi multi-socket per casi d'uso di fascia alta in cui volevi più throughput di quanto fosse ottenibile con una singola CPU che potesse essere prodotta, quindi quelli erano gli unici sistemi SMP. (Server, workstation di fascia alta).

Se un singolo core potesse scalare in modo efficiente come desiderato, avremmo sistemi con 1 core fisico per socket e SMT (ad esempio HyperThreading) per consentire loro di agire come più core logici. I desktop / laptop tipici avrebbero solo 1 core fisico e non avremmo difficoltà a parallelizzare cose che non si ridimensionano linearmente con più core. per esempiomake -j4 per sfruttare server multi-socket e / o nascondere la latenza I / O su un desktop. (O forse proveremmo ancora a parallelizzare molto se la larghezza della pipeline si ridimensionasse facilmente ma IPC no, quindi dovevamo usare più thread SMT.) Il kernel del tuo sistema operativo avrebbe comunque bisogno di funzionare su tutti i core logici, a meno che la CPU presenta SMT al sistema operativo era molto diverso, quindi sarebbero ancora necessari algoritmi di programmazione parallela e blocco.

Donald Knuth ha detto in un'intervista del 2008

Potrei anche infiammare un po 'la mia infelicità personale con l'attuale tendenza verso l'architettura multicore. Per me, sembra più o meno che i progettisti hardware abbiano esaurito le idee e che stiano cercando di passare la colpa per la futura fine della Legge di Moore agli scrittori di software dandoci macchine che funzionano più velocemente solo su alcuni parametri chiave!

Sì, se potessimo avere miracolose CPU single-core con un throughput 8x su programmi reali , probabilmente le useremmo comunque. Con i sistemi a doppia presa solo quando valeva la pena pagare molto di più per una maggiore produttività (non prestazioni a thread singolo).

Più CPU riduce i costi di cambio di contesto quando sono in esecuzione più programmi (lasciandoli funzionare realmente in parallelo invece di passare rapidamente da uno all'altro); il multitasking preventivo che interrompe l'enorme macchinario fuori servizio che una tale CPU richiederebbe probabilmente farebbe ancora più male di quanto non faccia ora.

Fisicamente sarebbe single core (per una semplice gerarchia di cache senza interconnessioni tra core) ma supporterebbe SMT (ad esempio HyperThreading di Intel) in modo che il software potesse usarlo come 8 core logici che competono dinamicamente per le risorse di throughput. O quando solo 1 thread è in esecuzione / non bloccato, otterrà il massimo beneficio.

Quindi useresti più thread quando ciò è effettivamente più semplice / naturale (ad esempio processi separati in esecuzione contemporaneamente) o per problemi facilmente parallelizzabili con catene di dipendenze che impedirebbero di massimizzare l'IPC di questa bestia.

Ma sfortunatamente è auspicabile pensare da parte di Knuth che le CPU multi-core smetteranno mai di essere una cosa a questo punto.

Ridimensionamento delle prestazioni a thread singolo

Penso che se realizzassero un equivalente a 1 core di una CPU a 8 core, un core avrebbe un aumento dell'800% dell'IPC in modo da ottenere le massime prestazioni in tutti i programmi, non solo quelli ottimizzati per più core.

Sì è vero. Se fosse possibile costruire una tale CPU , sarebbe davvero sorprendente. Ma penso che sia letteralmente impossibile nello stesso processo di fabbricazione dei semiconduttori (ovvero la stessa qualità / efficienza dei transistor). Certamente non è possibile con lo stesso budget di potenza e la stessa area di una CPU a 8 core, anche se risparmieresti logica per incollare i core insieme e non avresti bisogno di tanto spazio per le cache private per core.

Anche se permetti aumenti di frequenza (dato che il vero criterio è lavorare al secondo, non lavorare per clock), rendere anche una CPU 2 volte più veloce sarebbe una sfida enorme.

Se fosse possibile in qualsiasi luogo vicino alla stessa potenza e allo stesso budget di area (quindi costo di produzione) costruire una tale CPU, sì, i fornitori di CPU le avrebbero già costruite in quel modo.

Vedi i moderni microprocessori Una guida di 90 minuti!

Nello specifico, più core o core più ampi? sezione, affinché il background necessario per comprendere questa risposta; inizia in modo semplice con il funzionamento delle CPU con pipeline in ordine, quindi superscalare (istruzioni multiple per clock). Spiega quindi come abbiamo colpito il power-wall proprio attorno all'era P4, portando alla fine del facile ridimensionamento della frequenza, lasciando principalmente solo IPC e facendo più lavoro per istruzione (ad es. SIMD) come percorso, anche con transistor più piccoli.

L'ampliamento di una pipeline (istruzioni massime per orologio) in genere riduce i costi in termini di larghezza al quadrato . Tale costo viene misurato nell'area dello stampo e / o della potenza, per un più ampio controllo delle dipendenze in parallelo (rilevamento dei pericoli) e un più ampio programmatore fuori servizio per trovare le istruzioni pronte per l'esecuzione. E più porte di lettura / scrittura sul file di registro e cache se si desidera eseguire istruzioni diverse da nop. Soprattutto se hai istruzioni a 3 input come FMA o add-with-carry (2 registri + flag).

Ci sono anche rendimenti IPC decrescenti per ampliare le CPU ; la maggior parte dei carichi di lavoro ha ILP (parallelismo a livello di istruzione) limitato su piccola scala / a corto raggio per lo sfruttamento delle CPU, quindi allargare il core non aumenta l'IPC (istruzioni per clock) se l'IPC è già limitato a meno della larghezza del core per catene di dipendenze, filiali mancate, cache mancate o altre bancarelle. Sicuramente otterresti un aumento di velocità in alcuni loop non srotolati con iterazioni indipendenti, ma non è quello che la maggior parte del codice trascorre la maggior parte del suo tempo a fare. Le istruzioni di confronto / ramo costituiscono il 20% del mix di istruzioni nel codice "tipico", IIRC. (Penso di aver letto numeri dal 15 al 25% per vari set di dati.)

Inoltre, una mancanza di cache che blocca tutte le istruzioni dipendenti (e quindi tutto una volta raggiunta la capacità ROB) costa di più per una CPU più ampia. (Il costo opportunità di lasciare inattive più unità di esecuzione; più potenziale lavoro da non svolgere.) O un ramo mancante provoca allo stesso modo una bolla.

Per ottenere 8 volte l'IPC, avremmo bisogno almeno di un miglioramento di 8 volte nell'accuratezza della previsione delle succursali e nelle percentuali di hit della cache . Ma le percentuali di hit della cache non si adattano bene con la capacità della cache oltre un certo punto per la maggior parte dei carichi di lavoro. E il prefetching HW è intelligente, ma non può essere così intelligente. E a 8 volte l'IPC, i predittori di filiali devono produrre 8 volte il numero di previsioni per ciclo, oltre a renderle più accurate.

Le attuali tecniche per la realizzazione di CPU con esecuzione fuori servizio possono trovare ILP solo su brevi intervalli . Ad esempio, la dimensione ROB di Skylake è 224 Uops di dominio fuso, lo scheduler per Uops non eseguiti è di 97 dominio non fuso. Vedere Comprensione dell'impatto di lfence su un loop con due lunghe catene di dipendenze, per aumentare le lunghezze in un caso in cui la dimensione dello scheduler è il fattore limitante nell'estrazione di ILP da 2 lunghe catene di istruzioni, se diventano troppo lunghe. E / o vedi questa risposta più generale e introduttiva ).

Quindi trovare ILP tra due lunghi loop separati non è qualcosa che possiamo fare con l'hardware. La ricompilazione binaria dinamica per la fusione di loop potrebbe essere possibile in alcuni casi, ma è difficile e non qualcosa che le CPU possono davvero fare a meno che non seguano la rotta Transmeta Crusoe. (strato di emulazione x86 sopra un diverso ISA interno; in tal caso VLIW). Ma i moderni modelli x86 standard con cache uop e potenti decodificatori non sono facili da battere per la maggior parte del codice.

E al di fuori di x86, tutti gli ISA ancora in uso sono relativamente facili da decodificare, quindi non c'è motivazione per la ricompilazione dinamica oltre alle ottimizzazioni a lunga distanza. TL: DR: sperando in compilatori magici che possano esporre più ILP all'hardware non ha funzionato per Itanium IA-64 , ed è improbabile che funzioni per una CPU super-wide per qualsiasi ISA esistente con un modello seriale di esecuzione.

Se avessi una CPU super-wide, vorresti sicuramente supportarla SMT in modo da poterla nutrire con il lavoro da eseguire eseguendo più thread a basso ILP.

Poiché Skylake è attualmente largo 4 uops (e raggiunge un reale IPC da 2 a 3 uops per clock, o anche più vicino a 4 nel codice ad alta velocità effettiva), un'ipotetica CPU 8x più ampia sarebbe larga 32!

Essere in grado di ritagliarlo in 8 o 16 CPU logiche che condividono in modo dinamico quelle risorse di esecuzione sarebbe fantastico: i thread non bloccati ottengono tutta la larghezza di banda del front-end e il throughput del back-end.

Ma con 8 core separati, quando un thread si blocca non c'è nient'altro da mantenere alimentate le unità di esecuzione; gli altri thread non ne beneficiano.

L'esecuzione è spesso esplosiva: si blocca in attesa di un mancato caricamento della cache, quindi una volta che arrivano molte istruzioni in parallelo possono usare quel risultato. Con una CPU super-wide, l'esplosione può andare più veloce e può davvero aiutare con SMT.

Ma non possiamo avere magiche CPU super-wide

Quindi, per ottenere il rendimento, dobbiamo invece esporre il parallelismo all'hardware sotto forma di parallelismo a livello di thread . Generalmente i compilatori non sono bravi a sapere quando / come usare i thread, tranne che per casi semplici come loop molto grandi. (OpenMP o gcc's -ftree-parallelize-loops). Ci vuole ancora intelligenza umana per rielaborare il codice per fare in modo efficiente un lavoro utile fatto in parallelo, perché la comunicazione tra thread è costosa, così come l'avvio del thread.

TLP è un parallelismo a grana grossa, a differenza dell'ILP a grana fine all'interno di un singolo thread di esecuzione che HW può sfruttare.

Le CPU mirate a carichi di lavoro interattivi (come Intel / AMD x86 e core di fascia alta Apple / ARM AArch64) contribuiscono sicuramente a ridurre i rendimenti del ridimensionamento IPC, perché le prestazioni a thread singolo sono ancora così preziose quando la latenza è importante, non solo la produttività per problemi fortemente paralleli.

Essere in grado di eseguire 8 copie di un gioco in parallelo a 15 fps ciascuno è molto meno prezioso di essere in grado di eseguire una copia a 45 fps. I venditori di CPU lo sanno, ed è per questo che le moderne CPU usano l'esecuzione fuori servizio anche se costa una notevole potenza e un'area di stampo. (Ma le GPU non lo fanno perché il loro carico di lavoro è già enormemente parallelo).

L'hardware Xeon Phi a molti core di Intel (Knight's Landing / Knight's Mill) è un interessante punto di mezzo: esecuzione fuori servizio molto limitata e SMT per mantenere i core a 2 larghezze alimentati con le istruzioni SIMD AVX512 per ridurre i numeri. I core si basano sull'architettura Silvermont a bassa potenza di Intel. (Dirigente fuori servizio ma con una piccola finestra di riordino, molto più piccola della grande famiglia Sandybridge. E una pipeline più stretta.)

A proposito, tutto questo è ortogonale al SIMD. Fare sempre più lavoro per istruzione aiuta sempre, se è possibile per il tuo problema.

Modelli di prezzo

I modelli di prezzo del software sono basati sull'attuale panorama dell'hardware.

I modelli di licenza per core sono diventati più diffusi (e rilevanti anche per i desktop single-socket) con l'avvento delle CPU multi-core. Prima di ciò, era rilevante solo per server e grandi workstation.

Se il software non necessitasse di più core per funzionare alla massima velocità, non ci sarebbe davvero un modo per venderlo a un prezzo inferiore a persone che non ne trarranno grandi benefici perché lo eseguono su una CPU più debole. A meno che forse l'ecosistema software / hardware non abbia evoluto i controlli su "canali SMT" che consentono di configurare una larghezza massima di esecuzione per il codice in esecuzione su quel core logico. (Ancora una volta immaginando un mondo in cui le CPU si ridimensionano in larghezza della pipeline anziché più core separati.)

Fammi disegnare un'analogia:

Se hai una scimmia che digita su una macchina da scrivere e vuoi che la digitazione venga eseguita di più, puoi dare alla scimmia caffè, scrivere lezioni e forse fare minacce per farlo funzionare più velocemente, ma arriva un punto in cui la scimmia farà scrivere alla massima capacità.

Quindi, se vuoi fare più battitura, devi avere più scimmie.

Per estendere ulteriormente l'analogia, hai bisogno di una macchina da scrivere separata per ogni scimmia (che rappresenta il bus dati di cui ogni core avrà bisogno), hai bisogno di un modo per ottenere banane per ogni scimmia e qualcosa per raccogliere i loro escrementi (analogo alla distribuzione di energia e al calore dissipazione) e hai bisogno di un modo per assicurarti che le scimmie non stiano tutti provando a digitare lo stesso passaggio in Dodicesima notte (analogo a dividere giustamente il carico di lavoro tra i processori). Ma tutto ciò richiede meno lavoro per un guadagno maggiore rispetto al tentativo di ottenere più battiture da una scimmia.

Fai notare che molti software non usano più di (x) core. Ma questa è interamente una limitazione posta dai progettisti di quel software. I PC domestici con più core sono ancora nuovi (ish) e la progettazione di software multi-thread è anche più difficile con le API e le lingue tradizionali.

Il tuo PC non sta eseguendo solo quel programma. Sta facendo un sacco di altre cose che possono essere messe su core meno attivi in ​​modo che il tuo software principale non venga interrotto da loro.

Al momento non è possibile solo aumentare la velocità di un singolo core per raggiungere la velocità effettiva di 8 core. Probabilmente dovrà arrivare più velocità dalla nuova architettura.

Poiché più core sono comunemente disponibili e le API sono progettate con tale presupposto, i programmatori inizieranno comunemente utilizzando più core. Sono in corso sforzi per rendere più semplici i progetti multi-thread. Se ponessi questa domanda tra qualche anno probabilmente diresti "I miei giochi usano comunemente solo 32 core, quindi perché la mia CPU ne ha 256?".

La ragione più convincente dal punto di vista storico è la dissipazione di potenza .

Dopo il Pentium IV, Intel ha cercato di perseguire un processore di nuova generazione chiamato Tejas che avrebbe dovuto funzionare nella gamma da 4 GHz a 12 GHz. Il problema era che correre a quella velocità generava troppo calore per essere praticabile.

Dopo la cancellazione di Tejas, Intel impiegò altri 10-15 anni prima che finalmente i core funzionassero a 4 GHz con livelli di calore accettabili.

Vedere Tejas e Jayhawk .

Intel aveva un altro progetto in parallelo con Tejas che prevedeva l'utilizzo di più core. Quel progetto aveva livelli accettabili di calore, quindi è andata così. Ciò ha permesso loro di aumentare le prestazioni ora piuttosto che aspettare altri 10 anni per i processi di fabbricazione a 10 nm.

Supponendo che i core non siano carenti di risorse, quindi per ottenere lo stesso numero di istruzioni al secondo da un singolo core anziché N core, la velocità di istruzione di quel singolo core dovrebbe essere N volte più veloce. La dissipazione dinamica della potenza di un core della CPU è linearmente proporzionale alla frequenza operativa. È anche proporzionale al quadrato della tensione operativa. Il funzionamento a frequenze più basse consente l'uso di tensioni operative più basse. L'uso di tensioni più basse a frequenze più basse significa che praticamente il calore generato diminuisce con il cubo della frequenza operativa.

Un esempio estremo di ciò è il cervello umano, che può eseguire l'equivalente di 2 ^ 18 operazioni al secondo usando solo 20 W di potenza. Raggiunge questo obiettivo usando miliardi di neuroni che corrono in parallelo a poche centinaia di Hz.

Inoltre, tieni presente che di solito ci sono centinaia o migliaia di thread in esecuzione contemporaneamente su un PC. Il sistema operativo gestisce l'allocazione del tempo su un core per ciascun thread. Quindi, anche se un singolo programma non sfrutta tutti i core, ne trarrà comunque vantaggio perché gli altri programmi impiegano meno tempo della CPU se vengono eseguiti su un altro core.

Semmai, il mercato ad alte prestazioni si sta spostando verso un'elaborazione più parallela sotto forma di FPGA. Intel ha recentemente acquistato Altera (il secondo più grande produttore FPGA) e ora vende schede con un acceleratore hardware FPGA su di esse. Il software può caricare FPGA con un'immagine in fase di esecuzione utilizzando una chiamata API. La CPU quindi invia i dati all'FPGA e gli consente di svolgere la maggior parte del lavoro. I tipi di applicazioni sono in genere codifica video, AI, rendering, ricerca nel database, ecc.

Solo per completare l'immagine di dove tutto questo sta andando ...

Le reti neurali e l'intelligenza artificiale sono gli argomenti di punta del momento. Uno dei motivi è che è possibile utilizzare in modo efficiente un vasto numero di core semplici in parallelo e quindi estrarre vicino alle massime prestazioni di calcolo. Il requisito è intrinsecamente enormemente parallelo e si associa abbastanza facilmente alla matrice di processori senza molta comunicazione tra i core. Questo è il motivo per cui le GPU sono state la prima tecnologia goto per l'accelerazione dell'IA. In questo momento stiamo vedendo i chip ottimizzati anche meglio delle GPU video per le NN sul mercato. Il passo successivo, o forse finale, è rendere le NN usando tecnologie analogiche come memristor.

E a parte questo, in qualcosa come un PC da gioco ci sono prestazioni molto più grezze nella scheda grafica rispetto alla CPU Intel o AMD multicore

Fondamentalmente, le perdite CMOS sono esponenzialmente (^ 1,5) proporzionali alla frequenza e le prestazioni della CPU parallela sono leggermente inferiori rispetto a quelle lineari proporzionali al numero di CPU.

Pertanto, il rapporto tra potenza di calcolo e dissipazione di potenza viene migliorato per applicazioni multi-CPU a frequenze di clock diverse quando si confrontano la velocità rispetto alla quantità di CPU per una dissipazione di potenza fissa.

È più complesso di così, ma questi sono i fondamenti per cui le CPU parallele sono migliori per Watt in Watt nelle applicazioni dinamiche. Ci saranno sempre delle eccezioni quando ottimizzati per uno scenario.

Non è la dimensione di una CPU più grande che la rende più veloce per le tipiche applicazioni per PC Intel / AMD, ma è la dimensione ridotta dalla risoluzione litografica e la capacità del gate inferiore che riduce la potenza insieme al livello di sotto-soglia e alla tensione del core ridotti.

Il miglioramento non è lineare e non significa che 8 core è 4 volte migliore di 2, ma l'obiettivo se raggiunto è avere una gamma dinamica di elaborazione maggiore con la limitazione della dissipazione di potenza, velocità e tensione per migliorare sia le prestazioni che l'efficienza e la potenza di picco su richiesta senza eccessivo aumento della temperatura.

Per una risposta più scientifica leggi https://www.sciencedirect.com/topics/computer-science/dynamic-power-consumption

I multicore non sono generalmente multiscalari. E i core multiscalari non sono multicore.

Sarebbe una specie di ricerca perfetta di un'architettura multiscalare a diversi megahertz, ma in generale i suoi ponti non sarebbero abilitati dal consumatore, ma costosi, quindi la tendenza è la programmazione multicore a bassa frequenza piuttosto che brevi istruzioni ad alte velocità di clock.

Più core di istruzione sono più economici e più facili da comandare, ed è per questo che è una cattiva idea avere architetture multiscalari in diversi gigahertz.