Threads vs Process in .NET

Question

Ho un processo a esecuzione prolungata che legge file di grandi dimensioni e scrive file di riepilogo. Per velocizzare le cose, sto elaborazione di più file contemporaneamente utilizzando normali discussioni vecchie:

ThreadStart ts = new ThreadStart(Work); 
Thread t = new Thread(ts); 
t.Start(); 

Quello che ho trovato è che anche con thread separati lettura di file separate e nessun impuntamento tra di loro e con 4 thread su un 24 -core box, non riesco nemmeno a ottenere fino al 10% sulla CPU o al 10% sull'I/O del disco. Se uso più thread nella mia app, sembra che funzioni ancora più lentamente.

Direi che sto facendo qualcosa di sbagliato, ma dove è curioso è che se avvii l'intero exe una seconda e una terza volta, in realtà processa i file due o tre volte più velocemente. La mia domanda è: perché non posso ottenere 12 thread nella mia app per elaborare i dati e tassare la macchina e 4 thread in 3 istanze della mia app?

Ho profilato l'app e le funzioni più intensive e chiamate più frequentemente sono tutte chiamate di elaborazione delle stringhe.

Answer 1

Provare a utilizzare la libreria Attività da .net 4 (System.Threading.Task). Questa libreria ha ottimizzazioni integrate per un numero diverso di processori.

ho idea di cosa è che si problema, forse perché il frammento di codice non è veramente ben informato

Answer 2

E 'possibile che il problema computing non è CPU bound, ma legato I/O. Non aiuta a indicare che l'I/O del disco è "solo al 10%". Non sono sicuro che questo contatore di prestazioni esista anche.

Il motivo per cui diventa più lento durante l'utilizzo di più thread è perché questi fili sono tutti cercando di raggiungere i rispettivi file allo stesso tempo, mentre il sottosistema del disco sta avendo un momento difficile cercando di soddisfare tutti i diversi thread. Vedete, anche con una tecnologia moderna come SSD in cui il tempo di ricerca è di diversi ordini di grandezza inferiore rispetto ai dischi rigidi tradizionali, c'è ancora una penalità.

Piuttosto, dovresti concludere che il tuo problema è legato al disco e un singolo thread sarà probabilmente il modo più veloce per risolvere il tuo problema.

Si potrebbe sostenere che è possibile utilizzare tecniche asincrone per elaborare un bit che è stato letto, mentre sullo sfondo viene letto il bit successivo, ma penso che in questo caso si noterà un miglioramento minimo delle prestazioni.

Ho avuto un problema simile non molto tempo fa in un piccolo strumento in cui volevo calcolare le firme MD5 di tutti i file sul mio hard disk e ho scoperto che la CPU è troppo veloce rispetto al sistema di storage e io ha ottenuto risultati simili cercando di ottenere più prestazioni utilizzando più thread.

L'utilizzo della libreria parallela attività non ha alleviato questo problema.

Answer 3

Prima di tutto su un box 24 core se si utilizzano solo 4 thread la CPU più che potrebbe mai utilizzare è il 16,7%, quindi in realtà si ottiene il 60% di utilizzo, che è abbastanza buono.

È difficile stabilire se il programma è collegato I/O a questo punto, la mia ipotesi è che lo è. Devi eseguire un profiler sul tuo progetto e vedere quali sezioni di codice il tuo progetto sta spendendo al massimo il tempo. Se è seduto su un'operazione di lettura/scrittura è vincolato all'I/O.

È possibile che si utilizzi una forma di blocco interfilo. Ciò farebbe rallentare il programma man mano che si aggiungono altri thread, e sì, l'esecuzione di un secondo processo lo risolverebbe, ma risolverebbe anche il blocco.

Ciò a cui tutto si riduce è senza informazioni di profilazione, non possiamo dire se l'utilizzo di un secondo processo accelera le cose o rende le cose più lente, abbiamo bisogno di sapere se il programma è sospeso su un'operazione I/O, un blocco operazione, o semplicemente impiegando molto tempo in una funzione che può essere meglio parallelizzata.

Answer 4

Penso che si scopra quale cache di file non è l'ideale nel caso in cui uno proccess scrive i dati in molti file contemporaneamente. La cache dei file dovrebbe sincronizzarsi sul disco quando il numero di cache della pagina sporca supera una soglia. Sembra che gli autori concorrenti in una sola volta raggiungano una soglia di hit più veloce dello scrittore a thread singolo. È possibile leggere la lettura sulla cache del file system qui File Cache Performance and Tuning