2011-01-28 21 views
16

Un commento a another of my questions dice che posso eseguire simultaneamente "tanti" thread, una nozione che ho visto altrove.Quanti thread posso eseguire contemporaneamente?

Come novizio del threading, come è possibile determinare il numero massimo di thread da utilizzare? O è questa una domanda "quanto è lunga una stringa"? Da cosa dipende? Configurazione hardware o cosa?

(VB in MS Visual Studio con .Net 3.5, se quello che conta)


Aggiornamento: è qualcuno a conoscenza di s/w strumento che potrebbe suggerire un numero di thread (o attività), o dovrei semplicemente scrivere codice mio che continua a provare numeri diversi fino a quando non si riduce il throughput?


[Upperdate] Quasi sette anni dopo & ora abbiamo a software recommendations site, così ho asked se v'è uno strumento per aiutare con questo.

+2

Cosa fanno i fili? –

+1

+1 buona domanda. Ognuno di loro fa una chiamata SOAP per trasmettere dati di soem e aspetta che ritorni – Mawg

+1

Tranne, ovviamente, che il "ritorno" è asincrono, quindi non stanno davvero aspettando. Altri thread possono essere eseguiti non appena la richiesta SOAP (chiamata fcuntion) viene inviata su HTTP – Mawg

risposta

9

Dipende dall'hardware poiché non si utilizza (probabilmente) un computer teorico ma un hardware fisico, quindi si dispone di risorse limitate.

Leggi: Does Windows have a limit of 2000 threads per process?

Inoltre, anche se è possibile eseguire 5000+ discussioni, a seconda dell'hardware, che potrebbe funzionare molto più lento di un programma equivalente 10 thread. Penso che dovresti dare un'occhiata allo thread pooling.

+1

+1 Grazie. Questo mi dà qualcosa da guardare e iniziare a cercare di capire. Sei a conoscenza di uno strumento s/w che potrebbe suggerire un numero di thread? – Mawg

+2

Immagino che usare un thread per core della CPU sia una scelta sensata, ma in realtà dipende dal problema che stai cercando di risolvere. – Trinidad

+1

+1 Con uno per core sarà difficile simulare centinaia di dispositivi – Mawg

2

Dipende molto dalla macchina - CPU e memoria sono i principali fattori limitanti (anche se i limiti del sistema operativo possono entrare in esso).

Per quanto riguarda .NET, entra in gioco anche la configurazione thread pool.

+0

+1 Grazie per il feedback – Mawg

8

In genere, il numero di thread che l'esecuzione è realmente concomitante è determinato dal numero di CPU e core CPU (inclusa l'hyper threading). Ciò significa che in qualsiasi momento il numero di thread in esecuzione (nel sistema operativo) è uguale al numero di "core".

Quanti thread è possibile eseguire contemporaneamente nell'app dipende da un numero elevato di fattori. Il numero migliore (laico) è il numero di core sulla macchina, ma ovviamente è come fingere che nessuno (nessun'altra applicazione) esista altrimenti :).

Francamente, direi molto più studio su multi-threading in .NET/Windows perché si tende a fare più "danno" che bene quando non si ha una comprensione veramente solida. .NET ha il concetto di un pool di thread e devi sapere come funziona oltre a Windows.

In .NET 3.5/4.0 si dovrebbe cercare Task (Task Parallel Library) poiché la libreria svolge un lavoro molto migliore di determinare quanti thread (se non del tutto) generare. Con il TPL il threadpool ottiene una revisione importante ed è molto più intelligente sulla generazione di thread e sul furto di attività, ecc. Ma in genere si lavora con Task e non thread.

Si tratta di un settore complesso e, di conseguenza, il framework .NET ha introdotto le attività in modo da programmatori astratte di fili e permettendo quindi il runtime di essere intelligenti su questo mentre il programmatore solo dire quello che vuole e non tanto su come farlo.

+1

+1 Yup, temo che potrei fare più danni che bene. Vedrò anche i compiti, grazie – Mawg

+2

È utile, trovo, distinguere tra i termini "concorrenza" e "parallelismo" (cioè ciò che hai definito "concomitante"). – skaffman

+0

+1 buon punto, grazie – Mawg

7

Ogni thread consuma più memoria (stack kernel, blocco ambiente thread, thread-local, stack ....).AFAIK non ci sono limiti espliciti in Windows, quindi il vincolo sarà la memoria (probabilmente lo stack per ogni thread).

In discussioni Linux sono più simili processi (con memoria condivisa) e il gioco è costretto da:

cat /proc/sys/kernel/threads-max 
+0

+ tahnks per le informazioni – Mawg

+0

Risposta straordinaria, +1 per il suggerimento della riga di comando – ShellFish

0

ero in grado di eseguire 4 thread contemporaneamente sul mio attuale vecchio CPU (2005) Utilizzo di CPU di EVGA masterizzatore prima che il cicalino della CPU suonasse spento (programmato nel menu BIOS) Significato per colpire oltre 90 * c. Tieni presente che stiamo parlando di thread di dati che funzionano tutti contemporaneamente. un buon esempio sarebbe avere più programmi aperti contemporaneamente. Ma nel complesso dipende davvero quanto sia buona la tua CPU con il multitasking. (in altre parole può gestire molti thread attivi) Un modo sicuro per testare è scaricare "ocscanner (per EVGA)" e "CPU Thermometer" utilizzare il masterizzatore della CPU all'interno dello scanner OC Durante il test, assicurarsi che la temperatura non superi 90 * c (o qualsiasi temperatura in cui ti senti sicuro) e guarda il tuo numero attuale di thread che hai lanciato ha gettato la tua CPU. iniziare con 2 thread, attendere 3-5 minuti mentre si guarda la temperatura della CPU, aggiungere un altro thread, ripetere. (NON SPINGERE LA TUA FORTUNA !!!) (NON TENTARE SE IL TERMOMETRO DELLA CPU NON PU D RILEVARE LA TUA TEMPERATURA !!!)

3

Una buona regola empirica quando si eseguono attività intensive è eseguire lo stesso numero del core fisico contare.

Sì, è possibile eseguire più attività, ma attendono risorse (o thread in un pool di thread) e la propria casella, indipendentemente dalle dimensioni, non è in grado di allocare tutte le risorse core della cpu il 100% del tempo a una discussione dovuta allo sfondo/altri processi. Pertanto, più attività esegui, più threadi vengono generati, in quanto superano i possibili thread simultanei (1 per core), maggiore sarà la gestione delle risorse, l'accodamento e lo swapping.

Un test che abbiamo fatto dove lavoro ora utilizzando un modello virale per avviare attività aggiuntive trovato che era ottimale vicino al conteggio della CPU come un tappo. Le attività avviate con un rapporto uno a uno con il numero di core fisico sono state eseguite a circa 1 minuto per attività da completare. Impostato al doppio del conteggio della CPU, il tempo di attività è passato da una media di 1 minuto a circa 5 minuti di tempo medio per il completamento. Diventa geometricamente più lento più attività avviate dopo il core count.

Ad esempio, se si dispone di 8 core fisici, 8 attività (e l'utilizzo di TPL, essenzialmente 8 thread simultanei nel processo attivo) dovrebbero essere i più veloci. C'è il tuo thread o processo principale che crea le altre attività, e altri processi in background, ma se la scatola è abbastanza isolata per il tuo sfruttamento delle risorse, queste saranno abbastanza ridotte.

Il lato positivo della programmazione del limite di attività basato sul conteggio dei nuclei mentre si masticano le attività da una coda o da un elenco, quindi quando si distribuisce l'applicazione su riquadri di dimensioni diverse, si regola automaticamente.

Per determinare questo livello di codice, usiamo

var CoreCount = System.Environment.ProcessorCount/2;

Perché dividere per due, vi chiederete? Perché quasi tutti i processori moderni usano core logici o hyperthreading. Dovresti trovare con i tuoi test che se usi il conteggio logico, la tua velocità complessiva per compito, e quindi l'intero processo, diminuirà in modo significativo. I nuclei fisici sono la chiave. Non abbiamo potuto vedere un modo rapido per trovare fisico vs logico, ma una rapida panoramica delle nostre scatole ha rilevato che questo è sempre vero. YMMV, ma potrebbe essere abbastanza veloce.

1

Dalla mia esperienza personale, quando si utilizzano i thread una buona regola empirica per aumentare le prestazioni dei processi legati alla CPU è utilizzare un numero uguale di thread come core, tranne nel caso di un sistema hyper-thread nel quale caso si dovrebbe usa il doppio dei core. L'altra regola empirica che può essere conclusa è per i processi associati I/O.Questa regola consente di quadruplicare i thread numerici per core, tranne che per il caso di un sistema hyper-threaded, quindi è possibile quadruplicare il numero di thread per core.

+0

Lolx - quando ho postato per la prima volta, non esisteva una CPU multi-core :-) Grazie per il consiglio +1 – Mawg

Problemi correlati