2010-07-31 12 views
9

Alcuni anni fa, nell'ambiente Windows, ho eseguito alcuni test, lasciando che più istanze di calcolo della CPU intensivo + intensivo di accesso alla memoria + I/O accedano all'esecuzione intensiva dell'applicazione. Ho sviluppato 2 versioni: una è in esecuzione in multi-processing, un'altra è in esecuzione in multi-threading.Differenza di prestazione per multi-thread e multi-processo

Ho trovato che le prestazioni sono molto migliori per la multielaborazione. Ho letto da qualche altra parte (ma non riesco a ricordare il sito).

cui si afferma che il motivo è che in multi-threading, stanno "combattendo" per una singola pipeline di memoria e di conduttura I/O, il che rende peggiore è la performance rispetto al multi-processing

Tuttavia, Non riesco più a trovare quell'articolo Mi chiedevo, fino ad oggi, se il basso valesse ancora?

In Windows, avendo il codice di esecuzione dell'algoritmo sotto multi-processing, c'è un'alta probabilità che le prestazioni saranno meglio di multi-threading.

risposta

5

Dipende da quanto i vari thread o processi (userò il termine collettivo "compiti" per entrambi) devono comunicare, soprattutto condividendo la memoria: è facile, economico e veloce per i thread, ma per niente per i processi, quindi, se sta succedendo molto, scommetto che le prestazioni dei processi sono non andando a battere i thread '.

Inoltre, i processi (in particolare su Windows) sono "più pesanti" per iniziare, quindi se si verifica un sacco di "attività avviate", i thread possono facilmente battere i processi in termini di prestazioni.

Successivamente, è possibile avere CPU con "hyperthreading", che possono eseguire (almeno) due thread su un core molto rapidamente - ma non processi (poiché i thread "hyperthreaded" non possono utilizzare spazi di indirizzi distinti) - - ancora un altro caso in cui i thread possono vincere in termini di prestazioni.

Se nessuna di queste considerazioni si applica, allora la gara non dovrebbe essere migliore di un pareggio, comunque.

1

Non sono sicuro di cosa significhi la citazione. È molto vicino alle sciocchezze.

La cosa principale che condividono i thread in-proc è lo spazio degli indirizzi di memoria virtuale.

0

Non credo che sia vero. In generale, un'applicazione multithread verrà eseguita più velocemente della stessa applicazione progettata come più processi in Windows. Esistono vari motivi per cui il test potrebbe essere migliorato nel caso di più processi.

Il primo che salta alla mente è la condivisione errata. Nei test multithreading, i thread potrebbero aver inavvertitamente condiviso le linee della cache. Questo accade quando diversi thread accedono a differenti posizioni di memoria fisicamente vicine (entro pochi byte). Questo fa sì che le due CPU due contendano continuamente sulla stessa linea di cache e questo degrada gravemente le prestazioni. Ciò non può accadere nel caso multi processo perché i processi hanno spazi di indirizzo completamente separati.

+0

Um, solo perché gli spazi degli indirizzi virtuali sono in modalità sandbox non ti dice molto sul loro layout nella memoria fisica. Dipende da quanto sono grandi le richieste VirtualAlloc (o qualsiasi altra cosa) e se i processi/thread stanno eseguendo operazioni di load-store vicino ai limiti di detti blocchi. –

-2

Ho trovato che questo è vero. ma penso che abbia qualcosa a che fare con la programmazione. perché se lo esegui abbastanza a lungo, i multi-processi sono veloci quanto i multi-thread. quel numero è di circa 10 secondi. se l'algoritmo deve essere eseguito per 10 secondi. i multi-processi sono veloci come multi-thread.ma se deve essere eseguito solo per meno di 1 secondo. multi-processi è molto, molto più veloce di multi-thread.