Multithreading: qual è il punto di più thread rispetto ai core?

Ho pensato che il punto di un computer multi-core fosse che poteva eseguire più thread contemporaneamente. In tal caso, se hai una macchina quad-core, qual è il punto di avere più di 4 thread in esecuzione alla volta? Non si sarebbero semplicemente rubati del tempo (risorse CPU) l'uno dall'altro?

La risposta ruota attorno allo scopo dei thread, che è il parallelismo: eseguire diverse linee separate di esecuzione contemporaneamente. In un sistema 'ideale', avresti un thread in esecuzione per core: nessuna interruzione. In realtà non è così. Anche se hai quattro core e quattro thread di lavoro, il tuo processo e i thread verranno costantemente scambiati per altri processi e thread. Se stai eseguendo un sistema operativo moderno, ogni processo ha almeno un thread e molti ne hanno di più. Tutti questi processi sono in esecuzione contemporaneamente. Probabilmente hai centinaia di thread in esecuzione sul tuo computer in questo momento. Non avrai mai una situazione in cui un thread viene eseguito senza che il tempo venga "rubato" da esso. (Beh, potresti farlo se funziona in tempo reale, se si utilizza un sistema operativo in tempo reale o, anche su Windows, utilizzare una priorità di thread in tempo reale. Ma è raro.)

Con questo come sfondo, la risposta: Sì, più di quattro thread su una vera macchina a quattro core possono darti una situazione in cui "rubano tempo gli uni agli altri", ma solo se ogni singolo thread ha bisogno del 100% di CPU . Se un thread non funziona al 100% (come potrebbe non essere un thread dell'interfaccia utente o un thread che sta eseguendo una piccola quantità di lavoro o in attesa di qualcos'altro), un altro thread in fase di pianificazione è in realtà una buona situazione.

In realtà è più complicato di così:

• E se avessi cinque pezzi di lavoro che tutti devono essere eseguiti contemporaneamente? Ha più senso eseguirle tutte in una volta, piuttosto che eseguirle quattro e poi eseguire la quinta in seguito.

• È raro che un thread abbia realmente bisogno del 100% di CPU. Nel momento in cui utilizza l'I / O del disco o della rete, ad esempio, potrebbe passare del tempo in attesa di fare nulla di utile. Questa è una situazione molto comune.

• Se hai del lavoro che deve essere eseguito, un meccanismo comune è usare un threadpool. Potrebbe sembrare sensato avere lo stesso numero di thread dei core, ma il pool di thread .Net ha fino a 250 thread disponibili per processore . Non sono sicuro del motivo per cui lo fanno, ma la mia ipotesi è che abbia a che fare con la dimensione delle attività che vengono assegnate per l'esecuzione sui thread.

Quindi: rubare il tempo non è una brutta cosa (e non è nemmeno un vero furto: è come dovrebbe funzionare il sistema.) Scrivi i tuoi programmi multithread in base al tipo di lavoro che faranno i thread, che potrebbe non essere CPU -limite. Scopri il numero di thread necessari in base alla profilazione e alla misurazione. Potresti trovare più utile pensare in termini di attività o lavori, piuttosto che thread: scrivere oggetti di lavoro e assegnarli a un pool da eseguire. Infine, a meno che il tuo programma non sia veramente critico per le prestazioni, non preoccuparti troppo :)

Solo perché esiste un thread non significa sempre che è in esecuzione attivamente. Molte applicazioni di thread coinvolgono alcuni thread che vanno in modalità di sospensione fino a quando non è il momento per loro di fare qualcosa, ad esempio l'input dell'utente che attiva i thread per riattivarsi, eseguire alcune elaborazioni e tornare in modalità di sospensione.

In sostanza, i thread sono attività individuali che possono operare indipendentemente l'una dall'altra, senza che sia necessario essere consapevoli dell'avanzamento di un'altra attività. È del tutto possibile avere più di questi di quanto tu abbia la capacità di correre contemporaneamente; sono ancora utili per comodità anche se a volte devono aspettare in fila uno dietro l'altro.

Il punto è che, nonostante non si ottenga una vera accelerazione quando il conteggio dei thread supera il conteggio dei core, è possibile utilizzare i thread per districare pezzi di logica che non dovrebbero essere interdipendenti.

Anche in un'applicazione moderatamente complessa, usando un singolo thread prova a fare tutto in modo rapido facendo hash del 'flusso' del tuo codice. Il singolo thread trascorre la maggior parte del tempo a scrutarlo, verificandolo, chiamando condizionalmente le routine in base alle esigenze e diventa difficile vedere altro che una massa di minuzie.

Contrastalo con il caso in cui puoi dedicare thread alle attività in modo tale che, guardando ogni singolo thread, puoi vedere cosa sta facendo quel thread. Ad esempio, un thread potrebbe bloccare l'attesa dell'input da un socket, analizzare il flusso in messaggi, filtrare i messaggi e quando arriva un messaggio valido, passarlo a un altro thread di lavoro. Il thread di lavoro può lavorare su input da diverse altre fonti. Il codice per ognuno di questi mostrerà un flusso pulito e mirato, senza dover effettuare controlli espliciti che non c'è altro da fare.

Partizionare il lavoro in questo modo consente alla tua applicazione di fare affidamento sul sistema operativo per pianificare cosa fare successivamente con la cpu, quindi non devi effettuare controlli condizionali espliciti ovunque nell'applicazione su cosa potrebbe bloccare e cosa è pronto per l'elaborazione.

Se un thread è in attesa di una risorsa (come caricare un valore dalla RAM in un registro, I / O del disco, accesso alla rete, avviare un nuovo processo, interrogare un database o attendere l'input dell'utente), il processore può lavorare su un thread diverso e tornare al primo thread una volta che la risorsa è disponibile. Ciò riduce il tempo di inattività della CPU, poiché la CPU può eseguire milioni di operazioni invece di rimanere inattiva.

Considera un thread che deve leggere i dati da un disco rigido. Nel 2014, un tipico core del processore funziona a 2,5 GHz e potrebbe essere in grado di eseguire 4 istruzioni per ciclo. Con un tempo di ciclo di 0,4 ns, il processore può eseguire 10 istruzioni per nanosecondo. Con tempi di ricerca tipici del disco rigido meccanico di circa 10 millisecondi, il processore è in grado di eseguire 100 milioni di istruzioni nel tempo necessario per leggere un valore dal disco rigido. Potrebbero esserci significativi miglioramenti delle prestazioni con dischi rigidi con una piccola cache (buffer da 4 MB) e unità ibride con pochi GB di spazio di archiviazione, poiché la latenza dei dati per letture sequenziali o letture dalla sezione ibrida può essere più veloce di diversi ordini di grandezza.

Un core del processore può passare da un thread all'altro (il costo per mettere in pausa e riprendere un thread è di circa 100 cicli di clock) mentre il primo thread attende un input ad alta latenza (qualcosa di più costoso dei registri (1 clock) e della RAM (5 nanosecondi)) I / O su disco, accesso alla rete (latenza di 250 ms), lettura dei dati da un CD o da un bus lento o da una chiamata al database. Avere più thread che core significa che è possibile svolgere un lavoro utile mentre vengono risolte attività ad alta latenza.

La CPU ha un programmatore di thread che assegna la priorità a ciascun thread e consente a un thread di essere sospeso, quindi riprendersi dopo un tempo prestabilito. È compito del programmatore di thread ridurre il thrashing, che si verificherebbe se ogni thread eseguisse solo 100 istruzioni prima di essere messo nuovamente in sospensione. Il sovraccarico di passare da un thread all'altro ridurrebbe il throughput utile totale del core del processore.

Per questo motivo, potresti voler suddividere il problema in un numero ragionevole di thread. Se si scrivesse codice per eseguire la moltiplicazione della matrice, la creazione di un thread per cella nella matrice di output potrebbe essere eccessiva, mentre un thread per riga o per n righe nella matrice di output potrebbe ridurre i costi generali di creazione, pausa e ripresa dei thread.

Questo è anche il motivo per cui la previsione delle filiali è importante. Se si dispone di un'istruzione if che richiede il caricamento di un valore dalla RAM ma il corpo delle istruzioni if ​​e else utilizza valori già caricati nei registri, il processore può eseguire uno o entrambi i rami prima che la condizione sia stata valutata. Una volta ripristinata la condizione, il processore applicherà il risultato del ramo corrispondente e scarterà l'altro. Eseguire un lavoro potenzialmente inutile qui è probabilmente meglio che passare a un thread diverso, che potrebbe portare a un thrashing.

Dal momento che ci siamo spostati dai processori single-core ad alta velocità di clock ai processori multi-core, la progettazione dei chip si è concentrata sulla stipatura di più core per die, sul miglioramento della condivisione delle risorse on-chip tra i core, sui migliori algoritmi di previsione dei rami, su un overhead di commutazione dei thread migliore, e una migliore pianificazione dei thread.

La maggior parte delle risposte sopra parla di prestazioni e operazioni simultanee. Ho intenzione di approcciarlo da una prospettiva diversa.

Prendiamo il caso, diciamo, di un semplicistico programma di emulazione terminale. Devi fare le seguenti cose:

• cercare i caratteri in arrivo dal sistema remoto e visualizzarli
• guarda le cose che arrivano dalla tastiera e inviale al sistema remoto

(Gli emulatori di terminali reali fanno di più, incluso potenzialmente l'eco delle cose digitate anche sul display, ma per ora lo passeremo sopra.)

Ora il ciclo per la lettura dal telecomando è semplice, secondo il seguente pseudocodice:

while get-character-from-remote:
    print-to-screen character

Anche il loop per il monitoraggio della tastiera e l'invio è semplice:

while get-character-from-keyboard:
    send-to-remote character

Il problema, tuttavia, è che devi farlo simultaneamente. Il codice ora deve apparire più simile a questo se non hai thread:

loop:
    check-for-remote-character
    if remote-character-is-ready:
        print-to-screen character
    check-for-keyboard-entry
    if keyboard-is-ready:
        send-to-remote character

La logica, anche in questo esempio deliberatamente semplificato che non tiene conto della complessità delle comunicazioni nel mondo reale, è piuttosto offuscata. Con il threading, tuttavia, anche su un singolo core, i due loop pseudocodici possono esistere indipendentemente senza intrecciare la loro logica. Poiché entrambi i thread saranno per lo più associati a I / O, non caricano molto la CPU, anche se, a rigore, sono più dispendiosi di risorse della CPU rispetto al loop integrato.

Ora, ovviamente, l'uso nel mondo reale è più complicato di quanto sopra. Ma la complessità del ciclo integrato aumenta esponenzialmente man mano che si aggiungono ulteriori preoccupazioni all'applicazione. La logica diventa sempre più frammentata e devi iniziare a usare tecniche come macchine a stati, coroutine, ecc. Per rendere le cose gestibili. Gestibile, ma non leggibile. Il threading rende il codice più leggibile.

Quindi perché non dovresti usare il threading?

Bene, se le tue attività sono associate alla CPU anziché agli I / O, il threading rallenta effettivamente il tuo sistema. Le prestazioni ne risentiranno. Molto, in molti casi. ("Thrashing" è un problema comune se si rilasciano troppi thread associati alla CPU. Si finisce per passare più tempo a modificare i thread attivi rispetto a quando si esegue il contenuto dei thread stessi.) Inoltre, uno dei motivi per cui la logica sopra è così semplice è che ho scelto molto deliberatamente un esempio semplicistico (e non realistico). Se volevi fare eco a ciò che è stato digitato sullo schermo, hai un nuovo mondo di sofferenza mentre introduci il blocco delle risorse condivise. Con una sola risorsa condivisa questo non è tanto un problema, ma inizia a diventare un problema sempre più grande poiché hai più risorse da condividere.

Quindi, alla fine, il threading riguarda molte cose. Ad esempio, si tratta di rendere i processi associati agli I / O più reattivi (anche se complessivamente meno efficienti) come alcuni hanno già detto. Si tratta anche di rendere la logica più facile da seguire (ma solo se si minimizza lo stato condiviso). Si tratta di molte cose e devi decidere se i suoi vantaggi superano i suoi svantaggi caso per caso.

Anche se puoi sicuramente usare i thread per velocizzare i calcoli a seconda del tuo hardware, uno dei loro usi principali è quello di fare più di una cosa alla volta per motivi di facilità d'uso.

Ad esempio, se è necessario eseguire alcune elaborazioni in background e rimanere sensibili all'input dell'interfaccia utente, è possibile utilizzare i thread. Senza thread, l'interfaccia utente si bloccherebbe ogni volta che si tenta di eseguire elaborazioni pesanti.

Vedi anche questa domanda correlata: usi pratici per i thread

Non sono assolutamente d'accordo con l'affermazione di @ kyoryu secondo cui il numero ideale è un thread per CPU.

Pensaci in questo modo: perché abbiamo sistemi operativi multi-elaborazione? Per la maggior parte della storia del computer, quasi tutti i computer avevano una CPU. Eppure dagli anni '60 in poi, tutti i computer "reali" avevano sistemi operativi multi-elaborazione (aka multi-tasking).

Esegui più programmi in modo che uno possa essere eseguito mentre altri sono bloccati per cose come IO.

lascia da parte gli argomenti sul fatto che le versioni di Windows prima di NT fossero multi-tasking. Da allora, ogni vero sistema operativo ha avuto il multi-tasking. Alcuni non lo espongono agli utenti, ma è comunque lì, facendo cose come ascoltare la radio del cellulare, parlare con il chip GPS, accettare l'input del mouse, ecc.

Le discussioni sono solo attività un po 'più efficienti. Non esiste alcuna differenza fondamentale tra un'attività, un processo e un thread.

Una CPU è una cosa terribile da perdere, quindi hai un sacco di cose pronte per usarla quando puoi.

Concordo sul fatto che con la maggior parte dei linguaggi procedurali, C, C ++, Java ecc., Scrivere un codice thread-safe adeguato richiede molto lavoro. Con 6 CPU core oggi sul mercato e 16 CPU core non molto lontane, mi aspetto che le persone si allontanino da questi vecchi linguaggi, poiché il multi-threading è sempre più un requisito fondamentale.

Il disaccordo con @kyoryu è solo IMHO, il resto è fatto.

Immagina un server Web che deve soddisfare un numero arbitrario di richieste. È necessario servire le richieste in parallelo perché altrimenti ogni nuova richiesta deve attendere il completamento di tutte le altre richieste (incluso l'invio della risposta su Internet). In questo caso, la maggior parte dei server Web ha un numero di core molto inferiore rispetto al numero di richieste che di solito servono.

Inoltre semplifica lo sviluppatore del server: devi solo scrivere un programma thread che serve una richiesta, non devi pensare di archiviare più richieste, l'ordine in cui le hai servite e così via.

Molti thread si addormenteranno, in attesa di input dell'utente, I / O e altri eventi.

I thread possono aiutare con la reattività nelle applicazioni dell'interfaccia utente. Inoltre, puoi utilizzare i thread per ottenere più lavoro dai tuoi core. Ad esempio, su un singolo core, è possibile avere un thread che esegue IO e un altro che esegue un calcolo. Se fosse a thread singolo, il core potrebbe essenzialmente essere inattivo in attesa del completamento dell'IO. Questo è un esempio di livello piuttosto elevato, ma i thread possono sicuramente essere usati per battere la tua CPU un po 'più difficile.

Un processore, o CPU, è il chip fisico che è collegato al sistema. Un processore può avere più core (un core è la parte del chip in grado di eseguire le istruzioni). Un core può apparire al sistema operativo come processori virtuali multipli se è in grado di eseguire simultaneamente più thread (un thread è una singola sequenza di istruzioni).

Un processo è un altro nome per un'applicazione. In generale, i processi sono indipendenti l'uno dall'altro. Se un processo muore, non provoca anche la morte di un altro processo. È possibile che i processi comunichino o condividano risorse come memoria o I / O.

Ogni processo ha uno spazio e uno stack di indirizzi separati. Un processo può contenere più thread, ognuno in grado di eseguire istruzioni contemporaneamente. Tutti i thread in un processo condividono lo stesso spazio indirizzo, ma ogni thread avrà il proprio stack.

Spero che con queste definizioni e ulteriori ricerche usando questi fondamenti ti aiuterà a capire.

L'uso ideale dei thread è, in effetti, uno per core.

Tuttavia, a meno che non utilizzi esclusivamente IO asincroni / non bloccanti, ci sono buone probabilità che ad un certo punto avrai dei thread bloccati su IO, che non utilizzeranno la tua CPU.

Inoltre, i linguaggi di programmazione tipici rendono in qualche modo difficile utilizzare 1 thread per CPU. I linguaggi progettati in base alla concorrenza (come Erlang) possono semplificare l'uso di thread extra.

Il modo in cui alcune API sono progettate, non hai altra scelta che eseguirle in un thread separato (qualsiasi cosa con operazioni di blocco). Un esempio potrebbero essere le librerie HTTP di Python (AFAIK).

Di solito questo non è un grosso problema (se si tratta di un problema, il sistema operativo o l'API devono essere forniti con una modalità operativa asincrona alternativa, ovvero:) select(2), perché probabilmente significa che il thread verrà sospeso durante l'attesa di I / O completamento. D'altra parte, se qualcosa sta facendo un pesante calcolo, è necessario metterlo in un thread separato che dire, il filo GUI (a meno che non vi piace multiplexing manuale).

So che questa è una domanda super vecchia con molte buone risposte, ma sono qui per sottolineare qualcosa che è importante nell'ambiente attuale:

Se si desidera progettare un'applicazione per il multi-threading, non si dovrebbe progettare per un'impostazione hardware specifica. La tecnologia della CPU sta avanzando abbastanza rapidamente da anni e il numero di core sta aumentando costantemente. Se si progetta deliberatamente l'applicazione in modo tale che utilizzi solo 4 thread, si sta potenzialmente limitando un sistema octa-core (ad esempio). Ora, anche i sistemi a 20 core sono disponibili in commercio, quindi un tale progetto sta sicuramente facendo più danni che benefici.

In risposta alla tua prima congettura: le macchine multi-core possono eseguire simultaneamente più processi, non solo i thread multipli di un singolo processo.

In risposta alla tua prima domanda: il punto di più thread è di solito eseguire simultaneamente più attività all'interno di una sola applicazione. I classici esempi in rete sono un programma di posta elettronica che invia e riceve posta e un server Web che riceve e invia richieste di pagine. (Si noti che è essenzialmente impossibile ridurre un sistema come Windows all'esecuzione di un solo thread o anche solo di un processo. Eseguire il Task Manager di Windows e in genere vedrai un lungo elenco di processi attivi, molti dei quali eseguiranno più thread. )

In risposta alla tua seconda domanda: la maggior parte dei processi / thread non sono associati alla CPU (ovvero, non sono in esecuzione ininterrottamente e senza interruzioni), ma si fermano e attendono frequentemente il completamento dell'I / O. Durante l'attesa, altri processi / thread possono essere eseguiti senza "rubare" dal codice di attesa (anche su un singolo computer core).

Un thread è un'astrazione che ti consente di scrivere codice semplice come una sequenza di operazioni, beatamente inconsapevole del fatto che il codice sia eseguito interlacciato con altro codice, o parcheggiato in attesa di IO, o (forse un po 'più consapevole di) in attesa di altri thread eventi o messaggi.

Il punto è che la stragrande maggioranza dei programmatori non capisce come progettare una macchina a stati. Essere in grado di mettere tutto nel proprio thread libera il programmatore dal dover pensare a come rappresentare in modo efficiente lo stato dei diversi calcoli in corso in modo che possano essere interrotti e poi ripresi.

Ad esempio, considera la compressione video, un'attività molto impegnativa per la CPU. Se stai usando uno strumento gui, probabilmente vuoi che l'interfaccia rimanga reattiva (mostra i progressi, rispondi alle richieste di annullamento, ridimensionamento delle finestre, ecc.). Quindi progettate il vostro software di codifica per elaborare un'unità di grandi dimensioni (uno o più frame) alla volta ed eseguirlo nel proprio thread, separato dall'interfaccia utente.

Naturalmente una volta che ti rendi conto che sarebbe stato bello poter salvare lo stato di codifica in corso in modo da poter chiudere il programma per riavviare o giocare a un gioco affamato di risorse, ti rendi conto che avresti dovuto imparare a progettare macchine a stati dal inizio. O quello, o decidi di progettare un nuovo problema di ibernazione del processo del tuo sistema operativo in modo da poter sospendere e riprendere singole app su disco ...