Perché abbiamo CPU con tutti i core alle stesse velocità e non combinazioni di velocità diverse?

In generale, se si acquista un nuovo computer, è possibile determinare quale processore acquistare in base al carico di lavoro previsto. Le prestazioni nei giochi tendono a essere determinate dalla velocità single core, mentre le applicazioni come l'editing video sono determinate dal numero di core.

In termini di ciò che è disponibile sul mercato, tutte le CPU sembrano avere circa la stessa velocità con le differenze principali che sono più thread o più core.

Per esempio:

• Intel Core i5-7600K, frequenza di base 3,80 GHz, 4 core, 4 thread
• Intel Core i7-7700K, frequenza di base 4,20 GHz, 4 core, 8 thread
• AMD Ryzen 5 1600X, frequenza base 3,60 GHz, 6 core, 12 thread
• AMD Ryzen 7 1800X, frequenza base 3,60 GHz, 8 core, 16 thread

Quindi perché vediamo questo schema di aumentare i core con tutti i core che hanno la stessa velocità di clock?

Perché non abbiamo varianti con diverse velocità di clock? Ad esempio, due core "grandi" e molti core piccoli.

Per esempio, invece di, per esempio, quattro core a 4.0 GHz (ovvero 4x4 GHz ~ massimo 16 GHz), che dire di una CPU con due core che funzionano a dire 4.0 GHz e dire quattro core che funzionano a 2 GHz (ovvero 2x4.0 GHz + 4x2,0 GHz ~ 16 GHz massimo). La seconda opzione non sarebbe altrettanto efficace nei carichi di lavoro a thread singolo, ma potenzialmente migliore nei carichi di lavoro a thread multipli?

Faccio questa domanda come un punto generale, non specificamente su quelle CPU che ho elencato sopra o su uno specifico carico di lavoro specifico. Sono solo curioso di sapere perché lo schema è così com'è.

Questo è noto come multiprocessing eterogeneo ( HMP ) ed è ampiamente adottato dai dispositivi mobili. Nei dispositivi basati su ARM che implementano big.LITTLE , il processore contiene core con diversi profili di prestazioni e potenza, ad esempio alcuni core funzionano velocemente ma assorbono molta energia (architettura più veloce e / o clock più alti) mentre altri sono efficienti dal punto di vista energetico ma lenti ( architettura più lenta e / o orologi inferiori). Ciò è utile perché il consumo di energia tende ad aumentare in modo sproporzionato quando si aumentano le prestazioni una volta superato un determinato punto. L'idea qui è quella di ottenere prestazioni quando ne hai bisogno e durata della batteria quando non lo fai.

Sulle piattaforme desktop, il consumo di energia è molto meno problematico, quindi non è veramente necessario. La maggior parte delle applicazioni prevede che ciascun core abbia caratteristiche prestazionali simili e i processi di pianificazione per i sistemi HMP sono molto più complessi della pianificazione per i sistemi SMP tradizionali. (Windows 10 ha tecnicamente supporto per HMP, ma è principalmente destinato a dispositivi mobili che utilizzano ARM big.LITTLE.)

Inoltre, la maggior parte dei processori desktop e laptop oggi non sono limitati termicamente o elettricamente al punto in cui alcuni core devono funzionare più velocemente di altri anche per brevi scoppi. Abbiamo praticamente colpito un muro con la velocità con cui possiamo realizzare singoli core , quindi la sostituzione di alcuni core con quelli più lenti non consentirà ai core rimanenti di funzionare più velocemente.

Mentre ci sono alcuni processori desktop che hanno uno o due core in grado di funzionare più velocemente degli altri, questa funzionalità è attualmente limitata a determinati processori Intel di fascia alta (come Turbo Boost Max Technology 3.0) e comporta solo un leggero miglioramento delle prestazioni per quei core che possono funzionare più velocemente.

Mentre è certamente possibile progettare un processore x86 tradizionale con core grandi e veloci e core più piccoli e più lenti per l'ottimizzazione di carichi di lavoro con thread pesanti, ciò aggiungerebbe una notevole complessità al design del processore e le applicazioni difficilmente lo supporteranno correttamente.

Prendi un ipotetico processore con due core Kaby Lake (Core di settima generazione) veloci e otto core Goldmont (Atom) lenti . Avresti un totale di 10 core e carichi di lavoro fortemente threaded ottimizzati per questo tipo di processore potrebbero vedere un guadagno in termini di prestazioni ed efficienza rispetto a un normale processore quad-core Kaby Lake . Tuttavia, i diversi tipi di core hanno livelli di prestazioni notevolmente diversi e i core lenti non supportano nemmeno alcune delle istruzioni supportate dai core veloci, come AVX . (ARM evita questo problema richiedendo che sia i core grandi che quelli PICCOLI supportino le stesse istruzioni.)

Ancora una volta, la maggior parte delle applicazioni multithread basate su Windows presuppone che ogni core abbia lo stesso o quasi lo stesso livello di prestazioni e possa eseguire le stesse istruzioni, quindi è probabile che questo tipo di asimmetria comporti prestazioni tutt'altro che ideali, forse si blocca anche se utilizza istruzioni non supportate dai core lenti. Mentre Intel potrebbe modificare i core lenti per aggiungere il supporto di istruzioni avanzato in modo che tutti i core possano eseguire tutte le istruzioni, ciò non risolverebbe i problemi con il supporto software per processori eterogenei.

Un approccio diverso al design delle applicazioni, più vicino a quello che probabilmente stai pensando nella tua domanda, userebbe la GPU per l'accelerazione di porzioni di applicazioni altamente parallele. Questo può essere fatto usando API come OpenCL e CUDA . Per quanto riguarda una soluzione a chip singolo, AMD promuove il supporto hardware per l'accelerazione della GPU nelle sue APU, che combinano una CPU tradizionale e una GPU integrata ad alte prestazioni sullo stesso chip, come l' architettura di sistema eterogenea , anche se questo non ha visto molto assorbire l'industria al di fuori di alcune applicazioni specializzate.

Quello che stai chiedendo è perché i sistemi attuali utilizzano il multiprocessing simmetrico anziché il multiprocessing asimmetrico .

Il multiprocessing asimmetrico veniva utilizzato ai vecchi tempi, quando un computer era enorme e alloggiava su più unità.

Le moderne CPU sono espresse come un'unica unità, in un unico die, dove è molto più semplice non mischiare CPU di tipi diversi, poiché condividono tutti lo stesso bus e RAM.

C'è anche il vincolo dell'orologio che regola i cicli della CPU e l'accesso alla RAM. Ciò sarà impossibile quando si mischiano CPU di velocità diverse. Esistevano computer sperimentali senza clock ed erano anche piuttosto veloci, ma le complessità dell'hardware moderno imponevano un'architettura più semplice.

Ad esempio, i core Sandy Bridge e Ivy Bridge non possono funzionare a velocità diverse contemporaneamente poiché il bus della cache L3 funziona alla stessa velocità di clock dei core, quindi per evitare problemi di sincronizzazione devono eseguire entrambi a quella velocità o essere parcheggiato / spento (link: Intel Sandy Bridge Architecture Exposed ). (Anche verificato nei commenti qui sotto per Skylake.)

[EDIT] Alcune persone hanno scambiato la mia risposta per dire che è impossibile mescolare CPU. A loro vantaggio, dichiaro: la miscelazione di CPU diverse non va oltre la tecnologia odierna, ma non viene fatta: "perché no" è la domanda. Come spiegato sopra, ciò sarebbe tecnicamente complicato, quindi più costoso e per un guadagno finanziario troppo basso o nullo, quindi non interessa i produttori.

Ecco le risposte ad alcuni commenti qui sotto:

Turbo boost modifica le velocità della CPU in modo che possano essere modificate

Il boost del turbo si ottiene accelerando il tempo e cambiando alcuni moltiplicatori, che è esattamente ciò che le persone fanno durante l'overclocking, tranne che l'hardware lo fa per noi. Il clock è condiviso tra i core sulla stessa CPU, quindi questo accelera in modo uniforme l'intera CPU e tutti i suoi core.

Alcuni telefoni hanno più di una CPU con velocità diverse

Tali telefoni in genere hanno uno stack di firmware e software personalizzato associato a ciascuna CPU, più simile a due CPU separate (o come CPU e GPU) e mancano di una singola vista della memoria di sistema. Questa complessità è difficile da programmare e quindi il multiprocessing asimmetrico è stato lasciato nel regno mobile, poiché richiede uno sviluppo software di basso livello vicino all'hardware, che è evitato dal sistema operativo desktop generico. Questo è il motivo per cui tali configurazioni non si trovano nel PC (tranne CPU / GPU se estendiamo abbastanza la definizione).

Il mio server con 2x Xeon E5-2670 v3 (12 core con HT) attualmente ha core a 1,3 GHz, 1,5 GHz, 1,6 GHz, 2,2 GHz, 2,5 GHz, 2,7 GHz, 2,8 GHz, 2,9 GHz e molte altre velocità.

Un core è attivo o inattivo. Tutti i core attivi contemporaneamente funzionano alla stessa frequenza. Quello che stai vedendo è solo un artefatto di tempismo o media. Ho anche notato che Windows non parcheggia un core per molto tempo, ma piuttosto parcheggia / annulla separatamente tutti i core molto più velocemente della frequenza di aggiornamento di Resource Monitor, ma non conosco il motivo di questo comportamento che probabilmente è alla base la precedente osservazione.

I processori Intel Haswell dispongono di regolatori di tensione integrati che consentono tensioni e frequenze individuali per ogni core

I singoli regolatori di tensione differiscono dalla velocità di clock. Non tutti i core sono identici, alcuni sono più veloci. Ai core più veloci viene data una potenza leggermente inferiore, creando lo spazio per aumentare la potenza data ai core più deboli. I regolatori di tensione al cuore saranno impostati il ​​più basso possibile al fine di mantenere l'attuale velocità di clock. L'unità di controllo dell'alimentazione sulla CPU regola le tensioni e sovrascriverà le richieste del sistema operativo ove necessario per i nuclei che differiscono nella qualità. Riepilogo: i singoli regolatori servono per far funzionare economicamente tutti i core alla stessa velocità di clock, non per impostare le velocità dei singoli core

Perché non abbiamo varianti con diverse velocità di clock? vale a dire. 2 core "grandi" e molti core piccoli.

È possibile che il telefono in tasca abbia esattamente questa disposizione: ARM big.LITTLE funziona esattamente come descritto. Non c'è nemmeno solo una differenza di velocità di clock, possono essere tipi di core completamente diversi - in genere, quelli con clock più lento sono persino "più stupidi" (nessuna esecuzione fuori servizio e altre ottimizzazioni della CPU).

È una buona idea essenzialmente per risparmiare la batteria, ma ha i suoi difetti; la contabilità per spostare roba tra diverse CPU è più complicata, la comunicazione con il resto delle periferiche è più complicata e, soprattutto, per usare tali core in modo efficace lo scheduler deve essere estremamente intelligente (e spesso per "indovinare giusto") .

La disposizione ideale è eseguire attività in background non critiche in termini di tempo o attività interattive relativamente piccole sui "piccoli" core e riattivare quelli "grandi" solo per calcoli grandi e lunghi (dove finisce il tempo extra speso sui piccoli core mangiare più batteria) o per attività interattive di medie dimensioni, in cui l'utente avverte pigrizia sui piccoli nuclei.

Tuttavia, lo scheduler ha informazioni limitate sul tipo di lavoro che ciascuna attività può essere in esecuzione e deve ricorrere ad alcune euristiche (o informazioni esterne, come forzare una maschera di affinità su una determinata attività) per decidere dove pianificarle. Se si sbaglia, potresti perdere molto tempo / energia per eseguire un'attività su un core lento e offrire un'esperienza utente negativa o utilizzare i "grandi" core per attività a bassa priorità, e quindi sprecare potenza / rubandoli lontano da compiti che ne avrebbero bisogno.

Inoltre, su un sistema multiprocessing asimmetrico di solito è più costoso migrare le attività su un core diverso rispetto a un sistema SMP, quindi lo scheduler deve generalmente fare una buona ipotesi iniziale invece di provare a correre su un core libero casuale e spostarsi più tardi.

La scelta Intel qui è invece quella di avere un numero inferiore di core intelligenti e veloci identici, ma con un ridimensionamento di frequenza molto aggressivo. Quando la CPU è occupata, sale rapidamente alla massima velocità di clock, fa il lavoro il più velocemente possibile e quindi la riduce per tornare alla modalità di consumo di energia più bassa. Ciò non comporta un onere particolare per lo scheduler ed evita i cattivi scenari sopra descritti. Ovviamente, anche quando sono in modalità orologio basso, questi core sono "intelligenti", quindi probabilmente consumeranno più dei core "stupidi" big.LITTLE a basso clock.

Le prestazioni nei giochi tendono a essere determinate dalla velocità single core,

In passato (giochi dell'era DOS): corretto.
In questi giorni, non è più vero. Molti giochi moderni sono thread e beneficiano di più core. Alcuni giochi sono già abbastanza contenti di 4 core e quel numero sembra aumentare nel tempo.

mentre le applicazioni come l'editing video sono determinate dal numero di core.

Una specie di vero.

Numero di core * volte velocità dell'efficienza core *.
Se si confronta un singolo core identico con un set di core identici, allora si è per lo più corretti.

In termini di ciò che è disponibile sul mercato, tutte le CPU sembrano avere circa la stessa velocità con le differenze principali che sono più thread o più core. Per esempio:

Intel Core i5 7600k, Freq base 3.80 GHz, 4 core Intel Core i7 7700k, Freq base 4.20 GHz, 4 core, 8 thread AMD Ryzen 1600x, Freq base 3.60 GHz, 6 core, 12 thread AMD Ryzen 1800x, Freq base 3.60 GHz, 8 core, 16 thread

Confrontare architetture diverse è pericoloso, ma ok ...

Quindi perché vediamo questo schema di aumentare i core con tutti i core che hanno la stessa velocità di clock?

In parte perché ci siamo imbattuti in una barriera. L'aumento della velocità di clock implica inoltre una maggiore potenza necessaria e una maggiore generazione di calore. Più calore significava ancora più energia necessaria. Abbiamo provato in questo modo, il risultato è stato l'orribile Pentium 4. Caldo e affamato di potere. Difficile da raffreddare. E nemmeno più veloce del Pentium-M progettato in modo intelligente (un P4 a 3,0 GHz era approssimativamente più veloce di un P-mob a 1,7 GHz).

Da allora, per lo più, abbiamo rinunciato a spingere la velocità di clock e invece costruiamo soluzioni più intelligenti. Parte di ciò consisteva nell'utilizzare più core rispetto alla velocità di clock non elaborata.

Ad esempio, un singolo core da 4 GHz potrebbe assorbire la stessa potenza e generare la stessa quantità di calore di tre core da 2 GHz. Se il tuo software può utilizzare più core, sarà molto più veloce.

Non tutti i software potrebbero farlo, ma in genere i software moderni possono farlo.

Il che in parte risponde al motivo per cui disponiamo di chip con più core e perché vendiamo chip con un numero diverso di core.

Per quanto riguarda la velocità di clock, penso di poter identificare tre punti:

• Le CPU a bassa potenza hanno senso per parecchi casi in cui non è necessaria la velocità pura. Ad esempio controller di dominio, configurazioni NAS, ... Per questi, abbiamo CPU a frequenza inferiore. A volte anche con più core (ad esempio CPU 8x a bassa velocità ha senso per un server Web).
• Per il resto, di solito siamo vicini alla massima frequenza che possiamo fare senza che il nostro progetto attuale diventi troppo caldo. (diciamo da 3 a 4 GHz con i progetti attuali).
• E per di più, facciamo il binning. Non tutte le CPU sono generate allo stesso modo. Alcuni CPU hanno un punteggio scarso o ottengono un punteggio negativo in parte dei loro chip, hanno quelle parti disabilitate e vengono vendute come un prodotto diverso.

L'esempio classico di questo era un chip AMD a 4 core. Se un core è stato rotto, è stato disabilitato e venduto come chip a 3 core. Quando la domanda di questi 3 core era alta, anche alcuni 4 core venivano venduti come versione a 3 core e con il giusto hack del software, si poteva riattivare il 4 ° core.

E questo non avviene solo con il numero di core, ma influisce anche sulla velocità. Alcuni chip funzionano più caldi di altri. Troppo caldo e vendilo come una CPU a bassa velocità (dove una frequenza inferiore significa anche meno calore generato).

E poi c'è produzione e marketing e questo lo rovina ancora di più.

Perché non abbiamo varianti con diverse velocità di clock? vale a dire. 2 core "grandi" e molti core piccoli.

Noi facciamo. Nei luoghi in cui ha senso (ad es. Telefoni cellulari), spesso abbiamo un SoC con una CPU core lenta (bassa potenza) e alcuni core più veloci. Tuttavia, nel tipico PC desktop, ciò non viene fatto. Renderebbe l'installazione molto più complessa, più costosa e non vi è alcuna batteria da scaricare.

Perché non abbiamo varianti con diverse velocità di clock? Ad esempio, due core "grandi" e molti core piccoli.

A meno che non fossimo estremamente preoccupati per il consumo di energia, non avrebbe senso accettare tutti i costi associati a un core aggiuntivo e non ottenere il massimo delle prestazioni da quel core possibile. La massima velocità di clock è determinata in gran parte dal processo di fabbricazione e l'intero chip è realizzato dallo stesso processo. Quindi quale sarebbe il vantaggio di rallentare alcuni core rispetto al processo di fabbricazione supportato?

Abbiamo già dei core che possono rallentare per risparmiare energia. Quale sarebbe il punto di limitare le loro massime prestazioni?

Perché non abbiamo varianti con diverse velocità di clock? Ad esempio, due core "grandi" e molti core piccoli.

Al giorno d'oggi le velocità di clock nominali non significano molto per la maggior parte dei processori più grandi poiché hanno tutti la possibilità di clock su e giù. Stai chiedendo se sono in grado di sincronizzare i diversi core su e giù indipendentemente.

Sono un po 'sorpreso da molte altre risposte. I processori moderni possono e lo fanno. Puoi testarlo, ad esempio, aprendo CPU-Z su uno smartphone: il mio Google Pixel è perfettamente in grado di eseguire core diversi a velocità diverse:

È nominalmente 2,15 Ghz, ma due core sono a 1,593 Ghz e due sono a 1,132 Ghz.

In effetti, dal 2009 le CPU Intel tradizionali hanno avuto la logica di aumentare i singoli core più in alto, mentre erano inferiori a quelli di altri core, consentendo migliori prestazioni single core pur rimanendo all'interno di un budget TDP: http://www.anandtech.com/show/2832/4

I processori Intel più recenti con "Favored Core" (un termine di marketing Intel) hanno ciascun core caratterizzato in fabbrica, con i core più veloci in grado di aumentare ulteriormente: http://www.anandtech.com/show/11550/the-intel -skylakex-review-core-i9-7900x-i7-7820x-e-i7-7800x testato / 7

I chip Bulldozer di AMD ne avevano una versione primitiva: http://www.anandtech.com/show/4955/the-bulldozer-review-amd-fx8150-tested/4

Nuovi chip di AMD Ryzen probabilmente hanno anche questo, anche se non è detto esplicitamente qui: http://www.anandtech.com/show/11170/the-amd-zen-and-ryzen-7-review-a-deep-dive -on-1800x-1700x-e-1700-1711

In un sistema moderno spesso fare avere tutti i core in esecuzione a velocità diverse. Il rallentamento di un core che non viene utilizzato pesantemente riduce il consumo di energia e la produzione termica, il che è buono, e caratteristiche come "turbo boost" consentono a uno o due core di funzionare in modo significativamente più veloce fintanto che gli altri core sono inattivi, e quindi il consumo di energia e la potenza termica dell'intero pacchetto non aumenta troppo. Nel caso di un chip con tale funzione, la velocità che vedi nell'elenco è la velocità più alta che puoi ottenere con tutti i core contemporaneamente. E perché tutti i core dovrebbero avere la stessa velocità massima? Bene, hanno tutti un design identico, sullo stesso chip fisico, disposti con lo stesso processo a semiconduttore, quindi perché dovrebbero essere diversi?

Il motivo per cui tutti i core sono identici è perché ciò rende più semplice per un thread in esecuzione su un core in un punto iniziare a funzionare su un altro core in un altro punto. Come menzionato altrove, esistono chip comunemente usati che non seguono questo principio di core identici, vale a dire le CPU ARM "big.LITTLE". Sebbene nella mia mente la differenza più importante tra i core "grandi" e "piccoli" non sia la velocità di clock (i core "grandi" tendono ad essere più fantasiosi, più ampi, più core speculativi che ottengono più istruzioni per clock a costo di più alto consumo di energia, mentre i "piccoli" core si avvicinano alle radici a singolo problema, in ordine, a bassa potenza di ARM), poiché

E andando oltre nel regno dell'informatica eterogenea, sta diventando comune anche vedere i core "CPU" e "GPU" integrati nello stesso chip. Questi hanno disegni completamente diversi, eseguono diversi set di istruzioni, sono indirizzati in modo diverso e generalmente verranno anche sincronizzati in modo diverso.

Le prestazioni veloci a thread singolo e l'altissima velocità di trasmissione multi-thread sono esattamente ciò che ottieni con una CPU come Xeon E5-2699v4 di Intel .

È un Broadwell a 22 core. La velocità di clock sostenuta è di 2,2 GHz con tutti i core attivi (ad es. Codifica video), ma il turbo max single-core è 3,6 GHz.

Pertanto, durante l'esecuzione di un'attività parallela, utilizza un budget di potenza di 145 W come 22 core da 6,6 W. Ma durante l'esecuzione di un'attività con pochi thread, lo stesso budget di potenza consente a pochi core di turbo fino a 3,6 GHz. (La memoria single-core inferiore e la larghezza di banda della cache L3 in un grande Xeon significano che potrebbe non funzionare così velocemente come un quad-core desktop a 3,6 GHz. Un singolo core in una CPU Intel desktop può usare molto di più larghezza di banda di memoria totale.)

La velocità di clock nominale di 2,2 GHz è così bassa a causa dei limiti termici. Più core ha una CPU, più lentamente devono funzionare quando sono tutti attivi. Questo effetto non è molto grande nelle CPU a 4 e 8 core menzionate nella domanda, perché 8 non sono così tanti core e hanno budget di potenza molto elevati. Anche le CPU desktop appassionate mostrano chiaramente questo effetto: Intel Skylake-X i9-7900X è una parte 10c20t con base 3.3GHz, turbo massimo 4.5GHz . È molto più headroom turbo single-core di i7-6700k (turbo 4.0GHz sostenuto / 4.2GHz senza overclocking).

Il ridimensionamento di frequenza / tensione (DVFS) consente allo stesso core di funzionare su un'ampia gamma della curva prestazioni / efficienza. Vedi anche questa presentazione IDF2015 sulla gestione dell'alimentazione Skylake , con molti dettagli interessanti su ciò che le CPU possono fare in modo efficiente e scambiando le prestazioni contro l'efficienza sia staticamente in fase di progettazione, sia al volo con DVFS.

All'altra estremità dello spettro, le CPU Intel Core-M hanno una frequenza sostenuta molto bassa, come 1,2 GHz a 4,5 W , ma possono turbo fino a 2,9 GHz. Con più core attivi, eseguiranno i loro core a una velocità di clock più efficiente, proprio come i giganteschi Xeon.

Non hai bisogno di un'architettura eterogenea in stile big.LITTLE per ottenere il massimo beneficio. I piccoli core in ARM big.LITTLE sono core in ordine piuttosto scadenti che non sono buoni per il lavoro di calcolo. Il punto è solo di eseguire un'interfaccia utente con una potenza molto bassa. Molti di loro non sarebbero perfetti per la codifica video o altri gravi scricchiolii di numeri. ( @ Lưu Vĩnh Phúc ha trovato alcune discussioni sul perché x86 non ha grandi dimensioni . PICCOLO . Fondamentalmente, spendere silicio extra su un core molto lento a bassissima potenza non varrebbe la pena per il tipico uso desktop / laptop.)

mentre le applicazioni come l'editing video sono determinate dal numero di core. [Non sarebbe meglio 2x 4.0 GHz + 4x 2.0 GHz con carichi di lavoro multi-thread rispetto a 4x 4GHz?]

Questo è il tuo malinteso chiave. Sembra che tu stia pensando che lo stesso numero di tick di clock totali al secondo sia più utile se distribuito su più core. Non è mai così. È più simile

cores * perf_per_core * (scaling efficiency)^cores

( perf_per_corenon è la stessa cosa della velocità di clock, perché un Pentium4 3GHz otterrà molto meno lavoro per ciclo di clock rispetto a uno Skylake 3GHz.)

Ancora più importante, è molto raro che l'efficienza sia 1.0. Alcune attività parallele in modo imbarazzante si adattano in modo quasi lineare (ad es. Compilazione di più file di origine). Ma la codifica video non è così. Per x264, il ridimensionamento è molto buono fino a pochi core, ma peggiora con più core. ad esempio, passare da 1 a 2 core quasi raddoppierà la velocità, ma passare da 32 a 64 core aiuterà molto meno per una tipica codifica 1080p. Il punto in cui i piani di velocità dipendono dalle impostazioni. ( -preset veryslowesegue più analisi su ciascun frame e può tenere occupati più core di -preset fast).

Con molti core molto lenti, le parti a thread singolo di x264 diventerebbero colli di bottiglia. (ad esempio la codifica bitstream CABAC finale. È l'equivalente di gzip di h.264 e non si parallelizza.) Avere alcuni core veloci lo risolverebbe, se il sistema operativo sapesse come programmarlo (o se x264 fissasse i thread appropriati a core veloci).

x265 può sfruttare più core di x264, poiché ha più analisi da fare, e il design WPP di h.265 consente più codifica e decodifica parallelismo. Ma anche per 1080p, a un certo punto esaurisci il parallelismo per sfruttarlo.

Se hai più video da codificare, esegui più video in scala parallela, ad eccezione della concorrenza per risorse condivise come la capacità e la larghezza di banda della cache L3 e la larghezza di banda della memoria. Un numero inferiore di core più veloci potrebbe trarre maggiori benefici dalla stessa quantità di cache L3, dal momento che non avrebbero bisogno di lavorare su così tante diverse parti del problema contemporaneamente.

Mentre è possibile progettare computer con parti diverse in esecuzione a diverse velocità indipendenti, l'arbitrato delle risorse richiede spesso di poter decidere rapidamente quale richiesta servire per prima, il che a sua volta richiede sapere se qualsiasi altra richiesta potrebbe essere arrivata abbastanza presto per ottenere la priorità . Decidere queste cose, il più delle volte , è piuttosto semplice. Qualcosa come un circuito "quiz buzzer" potrebbe essere implementato con un minimo di due transistor. Il problema è che prendere decisioni rapide in modo affidabilenon ambiguo è difficile. L'unico modo pratico per farlo in molti casi è usare una decisione chiamata "sincronizzatore", che può evitare ambiguità ma introduce un ritardo di due cicli. Si potrebbe progettare un controller di memorizzazione nella cache che arbitrerebbe in modo affidabile tra due sistemi con clock separati se si fosse disposti a tollerare un ritardo di due cicli su ogni operazione per determinare chi ha vinto l'arbitrato. Un tale approccio sarebbe tuttavia poco utile se si desidera che una cache risponda immediatamente alle richieste in assenza di contesa, poiché anche le richieste non contestate avrebbero comunque un ritardo di due cicli.

Eseguire tutto da un orologio comune evita la necessità di sincronizzazione, che a sua volta evita un ritardo delle comunicazioni a due cicli ogni volta che è necessario passare informazioni o controllare segnali tra domini di orologio.

I computer desktop lo fanno già.

Hanno (set di) una (e) CPU (e), con 1-72 thread attivi contemporaneamente, e una (serie di) GPU (s), con 16-7168 unità di elaborazione.

La grafica è un esempio di un compito che abbiamo trovato efficiente il lavoro parallelo parallelo. La GPU è ottimizzata per eseguire il tipo di operazioni che vogliamo fare grafica (ma non è limitato a quello).

Questo è un computer con pochi core grandi e molti core piccoli.

In generale, non vale la pena scambiare un core su X FLOPS con tre core su X / 2 FLOPS; ma vale la pena scambiare un core su X FLOPS con cento core su X / 5 FLOPS.

Durante la programmazione per questo, si genera un codice molto diverso per la CPU e per la GPU. Viene svolto molto lavoro per dividere il carico di lavoro, in modo che la GPU ottenga le attività che sono meglio eseguite sulla GPU e che la CPU ottenga le attività che è meglio svolgere sulla CPU.

È probabilmente molto più semplice scrivere codice per una CPU, perché è molto più difficile ottenere un codice estremamente parallelo. Quindi, solo quando il payoff è grande , vale la pena scambiare prestazioni single-core per situazioni multi-core. Le GPU danno un grande profitto se usate correttamente.

Ora, i dispositivi mobili lo fanno per un motivo diverso. Hanno core a bassa potenza che sono significativamente più lenti, ma usano anche significativamente meno energia per unità di calcolo. Ciò consente loro di allungare la durata della batteria molto più a lungo quando non svolgono attività ad alta intensità di CPU. Qui abbiamo un diverso tipo di "grande profitto"; non prestazioni, ma efficienza energetica. Ci vuole ancora molto lavoro da parte del sistema operativo e possibilmente del writer dell'applicazione per farlo funzionare correttamente; ne è valsa la pena solo il grande profitto.

Il motivo per cui i sistemi comuni hanno core alla stessa velocità è un semplice problema di matematica. Tempi di input e output (con ottimizzazioni) basati su un singolo set di costanti (che sono scalabili = moltiplicabili per un numero di unità).

E qualcuno qui ha detto che i dispositivi mobili hanno multi-cpus con velocità diverse. Questo non è vero. Non è un'unità di elaborazione centrale se non è l'unità di elaborazione centrale; indipendentemente da ciò che il produttore dice che è o non è. in quel caso [non una CPU] è solo un "pacchetto di supporto".

Non credo che l'OP capisca l'elettronica di base. Tutti i computer richiedono una cosa per funzionare: un orologio. I cicli di clock generati da un clock interno sono il metronomo per lo spostamento di tutti i dati. Per raggiungere la sincronicità, tutte le operazioni devono essere legate a un orologio comune. Questo vale sia per l'esecuzione interna di dati su un computer isolato sia per intere reti.

Se volessi isolare i core su una CPU eseguendoli a frequenze diverse, potresti sicuramente progettare una tale piattaforma. Tuttavia, richiederebbe la progettazione di una soluzione per scheda madre che leghi ogni singolo core al proprio sottoinsieme isolato di funzionalità della scheda madre. Saresti lasciato con 4 singoli computer invece di un computer quad-core.

In alternativa, come sottolineato da un'altra persona, è possibile aggiungere codice al kernel che regola la frequenza del core su base individuale. Ciò causerà hit sulle prestazioni, tuttavia. Puoi avere velocità o efficienza energetica, ma non puoi avere entrambi.