IPC e frequenza di clock della CPU: come confrontare correttamente i processori per l'hosting

IPC della CPU: istruzioni per ciclo di clock

IPC della CPU sta per "Instructions per Cycle", ovvero istruzioni per ciclo di clock. Per un intervallo di misurazione definito, solitamente si divide il numero di istruzioni macchina completate per il numero di cicli della CPU conteggiati nello stesso intervallo. Un IPC pari a 2 significa, in questo contesto, una media di due istruzioni completate per ogni ciclo conteggiato.

Il valore è un Caratteristica della versione, non è un indicatore fisso valido per tutte le operazioni eseguite da un processore. Lo stesso sistema può raggiungere un IPC diverso in un calcolo con dati facilmente disponibili rispetto a una query su un database, che spesso deve attendere i dati provenienti dalla memoria principale. Anche il set di dati specifico e la sezione di programma considerata influenzano il risultato.

Una cache mantiene i dati utilizzati di frequente a portata di mano della CPU. Se invece un core deve attendere accessi alla memoria più lenti, le unità di esecuzione possono rimanere temporaneamente inattive. Allo stesso modo, le dipendenze tra le istruzioni e i rami nel flusso di esecuzione del programma influenzano la quantità di lavoro che può essere eseguita contemporaneamente. Un IPC basso è quindi motivo di ulteriori approfondimenti, ma non costituisce ancora una diagnosi definitiva.

Inoltre, un’istruzione macchina non è un’unità standardizzata che corrisponde a una richiesta web completata. Il compilatore, il set di istruzioni e la vettorizzazione possono far sì che programmi diversi richiedano un numero diverso di istruzioni per lo stesso compito. Un IPC più elevato, di per sé, non garantisce quindi né un tempo di risposta più breve né un maggior numero di richieste al secondo.

Per poter effettuare un confronto, è fondamentale sapere a quale applicazione e a quale intervallo di misura si riferisce quel valore. Un valore IPC privo di queste informazioni non permette di stabilire se i sistemi svolgano effettivamente lo stesso lavoro. Ulteriori nozioni di base sull’interazione tra frequenza di clock, core e gerarchia della memoria sono disponibili nell’articolo dedicato a Architettura della CPU nell'hosting.

Capire la frequenza di clock del server e il boost

La frequenza di clock indica il numero di cicli che una CPU esegue al secondo. Un gigahertz, abbreviato in GHz, corrisponde a un miliardo di cicli al secondo. Di per sé, questo valore non indica quante istruzioni un programma esegue in questi cicli né quanto lavoro utile riesca a svolgere.

Nelle schede tecniche si trova spesso una Frequenza di base e un boost massimo. La frequenza di base funge da valore di riferimento; il boost indica una frequenza più elevata raggiungibile in condizioni adeguate. Entrambe le indicazioni non sostituiscono l’osservazione della frequenza effettivamente raggiunta durante l’utilizzo concreto e in presenza del rispettivo carico.

Un esempio è l’AMD EPYC 9655: per questo modello, AMD dichiara 96 core, 192 thread, una frequenza di base di 2,6 GHz e un boost massimo fino a 4,5 GHz. Questi valori descrivono le caratteristiche tecniche e le specifiche di frequenza del processore. Non rappresentano né un IPC misurato né una prova di una determinata produttività di hosting.

Per la serie EPYC 9005, AMD definisce il boost massimo come frequenza massima che un singolo core può raggiungere in condizioni normali di funzionamento del server. I 4,5 GHz del 9655 non garantiscono quindi che tutti i 96 core mantengano questa frequenza in modo continuativo. I limiti di potenza e temperatura influenzano il comportamento sotto carico.

Per un’operazione singola di breve durata può essere rilevante una frequenza temporaneamente più elevata; in caso di carico parallelo prolungato, invece, è interessante valutare la potenza fornita dal sistema per l’intera durata dell’operazione. Altri modelli della serie presentano frequenze e numero di core diversi. Un confronto basato esclusivamente sul valore più alto in GHz non terrebbe conto di queste differenze e dell’applicazione concreta.

Nuclei, thread e CPU virtuali

In termini semplici, un processo è un’istanza di programma in esecuzione. Al suo interno, uno o più thread eseguono delle istruzioni. Un core fisico della CPU dispone dell’hardware necessario per eseguire tale attività; a seconda del processore, i sistemi operativi riconoscono uno o più thread logici della CPU per ogni core. I thread logici dello stesso core condividono parti del suo hardware.

Un'operazione che presenta una fase fortemente seriale non può distribuire questa parte a piacimento su più core. In questo caso, ciò che conta è la velocità con cui il thread esecutivo porta a termine il lavoro concreto. Le richieste web indipendenti, invece, possono spesso essere elaborate in parallelo: in tal caso, i core aggiuntivi disponibili possono contribuire alla produttività complessiva, a condizione che non vi siano altre risorse limitanti.

Il numero di thread logici non è da equiparare al numero di core fisici indipendenti. L'EPYC 9655, ad esempio, ha 96 core fisici e 192 thread secondo il produttore. I 192 thread non comportano né un raddoppio delle prestazioni rispetto a 96 thread, né una determinata velocità di elaborazione per un server web.

Nel caso di un server virtuale, il provider fornisce al sistema operativo ospite vCPU Pronto. Una vCPU non è automaticamente un core fisico utilizzabile in modo esclusivo: la sua assegnazione all’hardware dell’host può variare a seconda dell’offerta, e il tempo di elaborazione può essere condiviso con altri ospiti o limitato da soglie prestabilite.

Domanda da porre prima di scegliere, in merito alla disponibilità concreta delle risorse: il tempo di CPU è garantito o viene condiviso? Esistono limiti di prestazioni permanenti e come vengono assegnate le vCPU? Un numero elevato di vCPU aiuta un'applicazione parallela solo nella misura in cui sia effettivamente disponibile tempo di calcolo sufficiente; per una sezione seriale, non sostituisce un'esecuzione veloce su un thread.

Calcolo congiunto di IPC e frequenza di clock

L'IPC e la frequenza di clock descrivono aspetti diversi delle prestazioni della CPU. Per un intervallo di misurazione opportunamente definito, è possibile correlare approssimativamente il loro effetto: Istruzioni al secondo corrispondono all'IPC moltiplicato per i cicli effettivi della CPU al secondo. L'IPC si riferisce alle istruzioni completate e ai cicli conteggiati nello stesso intervallo.

Esempio di calcolo illustrativo, non si tratta di una misurazione: ipotizzando un valore costante di 2,0 istruzioni per ciclo e una frequenza di 3,0 GHz, si ottiene matematicamente un risultato di 6,0 miliardi di istruzioni al secondo. Anche un IPC di 1,5 a 4,0 GHz porta a 6,0 miliardi. In questo esempio, quindi, la frequenza di clock più elevata compensa l’IPC più basso nel calcolo.

Tuttavia, il fatto che i numeri di istruzioni siano uguali non significa che entrambi i sistemi elaborino lo stesso numero di richieste web. Per lo stesso compito, i programmi possono richiedere un numero diverso di istruzioni a seconda del compilatore, del set di istruzioni e dei comandi utilizzati. Un’istruzione non rappresenta quindi una quantità uniforme di lavoro svolto dall’applicazione.

Anche il tempo di risposta di un sito web non è direttamente deducibile dal prodotto. Un thread può attendere dati dal supporto di memorizzazione o una risposta di rete; nel frattempo, la sua frequenza di istruzioni non spiega l'intero tempo trascorso. Nel caso di una macchina virtuale, si aggiunge il fatto che essa non riceve necessariamente tempo di CPU in ogni momento.

Per poter effettuare un confronto, è quindi necessario poter identificare quale codice e quale periodo di tempo siano stati presi in considerazione. La formula aiuta a classificare l'esecuzione attiva; per la scelta dell'hosting sono inoltre necessari i compiti completati e i relativi tempi di risposta nell'ambito di un profilo di richiesta comparabile.

Classificare la scheda tecnica e gli indicatori chiave

Una scheda tecnica fornisce indicazioni utili per la scelta di una CPU per l'hosting. Tuttavia, i dati riportati rispondono a domande diverse: l'IPC descrive un comportamento nel rispettivo intervallo di misurazione, mentre i dati relativi alla frequenza e al numero di core specificano le caratteristiche di un modello di processore. Solo in combinazione con l'applicazione questi dati diventano criteri di confronto utilizzabili.

L’EPYC 9655 illustra come tali specifiche siano correlate: secondo AMD, il modello dispone di 96 core e 192 thread, una frequenza di base di 2,6 GHz e un boost massimo fino a 4,5 GHz. I 4,5 GHz non rappresentano una frequenza garantita per tutti i core sotto carico continuo né una velocità effettiva misurata.

Una classifica basata sulla frequenza massima in GHz non terrebbe conto della quantità di lavoro che i diversi processori riescono a svolgere per ciclo e per attività. Una classifica basata sul numero di core, invece, non tiene conto del fatto che non tutte le applicazioni sono in grado di distribuire il proprio carico di lavoro in modo ugualmente efficiente in parallelo. Entrambi questi dati sono punti di partenza, non valutazioni definitive delle prestazioni.

Quando si tratta di offerte, presta quindi attenzione a Variante del modello e su quali risorse siano effettivamente utilizzabili. Per un confronto attendibile, occorre inoltre un profilo di carico adeguato e risultati ottenuti con software e configurazioni comparabili. Le specifiche dei diversi modelli non dovrebbero essere confuse con un valore massimo ipotizzato per l'intera famiglia di prodotti.

Scegliere la CPU di hosting in base al profilo di carico

La scelta della CPU più adatta all’hosting dipende dalle attività che il server dovrà svolgere. Un’unica attività di lunga durata presenta requisiti diversi rispetto a numerose richieste web indipendenti. La tabella traduce i profili di carico tipici in un parametro di riferimento prioritario e in una domanda da chiarire prima della scelta.

Nel caso di un’attività singola, le prestazioni del thread che la esegue sono particolarmente importanti quando gran parte del lavoro viene eseguito in modo seriale. Un numero maggiore di core non riduce automaticamente la durata di questa parte. Anche un breve picco di prestazioni non è sufficiente a dimostrare l’efficienza di un’attività di lunga durata: ciò che conta è il tempo di esecuzione misurato nelle condizioni previste.

Molte richieste indipendenti possono invece essere elaborate in parallelo. In questo caso, oltre alle prestazioni per thread, sono importanti il numero di risorse disponibili contemporaneamente e l’andamento dei tempi di risposta all’aumentare del carico. La somma dei valori nominali in GHz non sostituisce un confronto tra Portata complessiva a parità di parallelismo.

In un database con un set di dati di lavoro di grandi dimensioni, gli accessi alla memoria possono rallentare l'esecuzione se i dati necessari non vengono recuperati in modo efficiente dalle cache. Un IPC basso può essere motivo di ulteriori approfondimenti, ma di per sé non dimostra la presenza di un collo di bottiglia nella memoria. Verifica quindi anche le query, il volume dei dati e la configurazione della memoria prima di sostituire la CPU.

Nel caso del VPS, si aggiunge inoltre la Impegno a fornire risorse È fondamentale: una vCPU non corrisponde automaticamente a un core fisico esclusivo. Occorre informarsi sull’assegnazione, sui possibili limiti della CPU e sulla condivisione con altri guest. Solo con queste informazioni è possibile confrontare in modo significativo un test dell’applicazione con un’offerta su un server dedicato.

Pianificare test applicativi comparabili

Un confronto significativo parte dalla tua applicazione, non da un valore isolato della CPU. Imposta per entrambe le offerte di hosting la stessa versione del software, lo stesso set di dati e la stessa configurazione. SPEC definisce la propria applicazione sulla propria infrastruttura come il parametro di riferimento ideale per la scelta del prodotto.

Definisci quindi un Profilo della richiesta, che rifletta il più fedelmente possibile l'utilizzo effettivo: ad esempio, quali pagine o endpoint API vengono richiamati e quante richieste arrivano contemporaneamente. Mantieni il parallelismo e i limiti delle risorse comparabili tra i vari cicli di esecuzione. Se un'offerta prevede limiti diversi, documentali espressamente, invece di attribuire la differenza esclusivamente alla CPU.

Prevedi una fase di riscaldamento, in modo che, ad esempio, l'applicazione sia già avviata e le cache possano riempirsi. Successivamente, eseguire più cicli di durata adeguata aiuta a distinguere le fluttuazioni a breve termine da una differenza ricorrente. Documenta inoltre se durante la misurazione erano in esecuzione altre attività sui sistemi.

Oltre alla produttività, registra anche la Distribuzione dei tempi di risposta e gli errori. Una media più elevata di richieste completate al secondo è di per sé poco utile se le singole richieste rimangono in attesa per molto tempo o falliscono più spesso. Confronta quindi anche i percentili più alti del tempo di risposta a parità di parallelismo.

I risultati SPEC-CPU2017 pubblicati possono fornire ulteriori indicazioni. SPECspeed misura il tempo necessario per eseguire le operazioni, mentre SPECrate misura la produttività; le due metriche non sono direttamente intercambiabili. Confronta i risultati relativi alla stessa metrica e tieni conto della configurazione del sistema e del software. La suite CPU non riflette la rete e l’I/O di un servizio di hosting completo.

Verificare l'IPC e la frequenza durante il funzionamento

Per creare un proprio ambiente di test Linux, è possibile acquisire con perf le istruzioni e i cicli completati di un programma esistente e verificato. Nell'esempio seguente, testprogramm Un segnaposto: sostituiscilo con il tuo programma di test e, se necessario, con i relativi argomenti. Il comando è un suggerimento di misurazione, non un test già eseguito.

perf stat -e '{instructions,cycles}' -- testprogramm

Le parentesi graffe racchiudono gli eventi in un’unica Gruppo di contatori insieme. Devono essere registrate contemporaneamente, il che può ridurre gli errori causati dal multiplexing a intervalli di tempo. Dividi le istruzioni conteggiate per i cicli conteggiati per ottenere l'IPC per questo intervallo di misurazione; perf può anche restituire direttamente questo valore.

La disponibilità degli eventi e la possibilità di leggerli dipendono dall’hardware, dal kernel, dai permessi e, se del caso, dall’ambiente di virtualizzazione. Un gruppo di eventi non disponibile o che non può essere conteggiato collettivamente non fornisce un confronto attendibile. Non modificare le impostazioni di sicurezza solo per questo esempio.

Anche l'indicazione di una frequenza richiede un contesto: scaling_cur_freq secondo la documentazione del kernel, in molti casi corrisponde allo stato richiesto per ultimo dal driver e non necessariamente alla frequenza hardware effettivamente raggiunta. Il valore, non disponibile ovunque, cpuinfo_cur_freq dovrebbe invece riprodurre la frequenza attuale rilevata a livello hardware. Maggiori informazioni su Governor della CPU sui server di hosting spiega il funzionamento del ridimensionamento della frequenza.

Un valore IPC basso è un indizio che richiede ulteriori approfondimenti, ma non costituisce una diagnosi definitiva. Gli accessi alla memoria possono rallentare l'esecuzione; occorre inoltre verificare quale parte del programma sia stata misurata e se siano presenti altri fattori che potrebbero influire sui risultati. Confronta quindi il valore del contatore con il comportamento dell'applicazione e il suo accesso ai dati.

Individuare il collo di bottiglia e decidere di effettuare l'aggiornamento

Parti da un sintomo concreto: le richieste diventano lente sotto carico, il tasso di errore aumenta o un singolo processo impiega troppo tempo? Annota quando si verifica il problema e quali processi sono in esecuzione contemporaneamente. Solo così sarà possibile verificare se una maggiore potenza della CPU possa effettivamente ridurre il ritardo in questione.

Controlla innanzitutto lo spazio disponibile e quello utilizzato tempo di CPU. Un’attività che richiede un carico di calcolo costante può trarre vantaggio da un’esecuzione più veloce o da un maggiore parallelismo utilizzabile. Tuttavia, un elevato carico di lavoro da solo non spiega né quale codice lo causi, né se il tempo di risposta derivi principalmente da lì. Confronta quindi i risultati con la produttività e i tempi di risposta della stessa fase di carico.

Analizza quindi il fabbisogno di memoria e gli accessi ai dati. Se un database deve accedere frequentemente a dati al di fuori della cache della CPU, potrebbe dover attendere la memoria; un IPC basso può essere un’indicazione in tal senso, ma non ne dimostra la causa. Anche una memoria di lavoro insufficiente, gli accessi ai supporti di memorizzazione o servizi esterni lenti possono influire sul ritardo osservato.

Nel caso di un VPS, la Impegno a fornire risorse Per quanto riguarda la diagnosi: informati sull’assegnazione delle vCPU, sui possibili limiti della CPU e sulla condivisione con altri guest. Un server dedicato offre un’assegnazione diversa delle risorse fisiche, ma anche in questo caso sono l’applicazione, la configurazione e il profilo di carico a determinare il risultato. Confronta le due offerte, se possibile, utilizzando lo stesso test applicativo.

Valuta la possibilità di un upgrade della CPU se le misurazioni indicano un collo di bottiglia a livello di CPU e il nuovo piano tariffario garantisce effettivamente il tempo di elaborazione necessario. Se il ritardo è dovuto prevalentemente alla memoria, al supporto di dati o a un servizio esterno, è più opportuno approfondire l’analisi in quell’ambito. Registra lo stato iniziale, in modo da poter valutare in seguito le modifiche in modo comparabile.

Non interpretare i valori massimi di boost come una frequenza di clock continua garantita per tutti i core, né un valore IPC come una caratteristica universale della CPU. Allo stesso modo, un singolo dato relativo al carico di lavoro non è sufficiente per una diagnosi completa dei colli di bottiglia. La decisione va presa in base al compito specifico e alle risorse effettivamente disponibili, non sulla base di un singolo valore di picco.