Ci sono dei vantaggi nel limitare il numero di thread concorrenti che eseguono una determinata attività per eguagliare il numero di processori sul sistema host? O meglio semplicemente affidarsi a librerie come .NET ThreadPool per fare la cosa giusta ... anche se ci sono 25 thread concorrenti diversi in un dato momento?Limitazione di thread simultanei pari al numero di processori?
La maggior parte dei thread non ha limiti CPU, finiscono per attendere IO o altri eventi. Se guardi il tuo sistema ora, immagino che tu abbia 100 (se non 1000) thread in esecuzione senza problemi. Con questa misura, probabilmente è meglio lasciare il pool di thread .NET per fare la cosa giusta!
Tuttavia, se i thread fossero tutti vincolati alla CPU (ad esempio qualcosa come ray tracing), sarebbe una buona idea limitare il numero di thread al numero di core, altrimenti è probabile che il cambio di contesto inizi a danneggiare le prestazioni .
Bene, se il collo di bottiglia è SOLO processori, allora potrebbe avere senso, ma questo ignorerebbe tutta la memoria e altri colli di bottiglia i/o, e ci sono buone probabilità che la memoria cache stia causando errori di pagina e altri eventi che rallenterebbero i fili.
Mi fiderei della biblioteca da solo. I thread attendono tutti i tipi di cose e non vuoi che la tua applicazione rallenti perché non può generare un nuovo thread, anche se la maggior parte del resto sta dormendo solo, in attesa di qualche evento o risorsa.
Il threadpool esegue già un buon lavoro. Cerca di limitare il numero di thread in esecuzione al numero di core CPU nella macchina. Quando un thread termina, pianifica immediatamente un altro thread idoneo per l'esecuzione.
Ogni 0,5 secondi, valuta cosa sta succedendo con i thread in esecuzione. Quando i thread sono stati eseguiti troppo a lungo, si presuppone che siano in stallo e consente a un altro thread di iniziare l'esecuzione. Ora avrai più thread in esecuzione rispetto ai core della CPU. Questo può raggiungere il numero massimo di thread consentito, come impostato da ThreadPool.SetMaxThreads().
A partire da .NET 2.0 SP1, il numero massimo predefinito di thread è stato aumentato considerevolmente a 250 volte il numero di core. Non dovresti mai arrivarci. Se lo fai, avresti sprecato circa 2 minuti di tempo in cui era in esecuzione un numero probabilmente non ottimale di thread. Tuttavia, quei thread dovevano essere tutti bloccati per quel lungo, non esattamente un modello di esecuzione tipico per un thread. D'altra parte, se questi thread sono tutti in attesa sullo stesso tipo di risorsa, è probabile che a turno, aggiungendo più thread non è possibile migliorare il throughput.
Per farla breve, il pool di thread funzionerà correttamente se si eseguono thread eseguiti rapidamente (secondi al massimo) e non si bloccano per un lungo periodo di tempo. Probabilmente dovresti considerare di creare i tuoi oggetti Thread quando il tuo codice non corrisponde a quel modello.
Misura la tua applicazione in una varietà di thread: rapporti del processore. Vieni alle conclusioni sulla base di dati rigidi sulla tua applicazione. Non accettare argomenti dai primi principi su quale prestazione si deve ottenere , solo ciò che si ottiene do ottiene problemi.