[Python] GIL e fork - multiprocesso -
Manlio Perillo
manlio_perillo a libero.it
Mar 11 Maggio 2010 19:16:36 CEST
Alessandro Agosto ha scritto:
> Ciao a tutti,
Ciao
> [...]
>
> "Inside the Python GIL" di David Beazley.
> L'ho quasi letto tutto (mi mancano proprio le ultime tre-quattro pagine)
> e ho voluto ripetere i test.
> Ho riscritto la medesima funzione CPU-bound (non mi viene un equivalente
> italiano, forse "che sfrutta la sola CPU"?)
La traduzione non è corretta.
Meglio "limitato dalla CPU", o qualcosa di simile.
> [1] e l'ho adattata a tre test:
> 1) non posto il sorgente in quanto è un semplice test sequenziale
> "count(100000000); count(100000000)"
> 2) usando il multithreading ed effettivamente si nota la differenza
> (anche a me 2x più lento o peggio) [2]
Il codice che hai postato usa il threading nel modo sbagliato, perchè le
due funzioni sono chiamate in modo sequenziale.
Prima aspetti che il primo thread finisce, e quindi esegui il secondo.
> 3) usando la fork [3]
>
> Ho aggiunto il test per la fork in quanto creando un nuovo processo il
> GIL non dovrebbe dare problemi, giusto?
Si.
> Beh ecco i risultati sul mio P4 3,00GHz:
> 1) sequenziale
> ----------------------
> real 0m35.363s
> user 0m34.831s
> sys 0m0.087s
> ----------------------
> 2) threaded
> ----------------------
> real 1m30.482s
> user 1m25.342s
> sys 0m28.125s
> ----------------------
> 3) forked
> ----------------------
> real 0m52.938s
> user 1m30.927s
> sys 0m0.395s
> ----------------------
>
Io ottengo risultati molto diversi.
La versione sequenziale:
real 0m21.341s
user 0m20.185s
sys 0m0.260s
La versione con threads:
real 0m26.279s
user 0m22.101s
sys 0m5.244s
La versione con i processi:
real 0m13.160s
user 0m10.313s
sys 0m0.056s
La versione con i threads "corretta" (senza i due join) ha praticamente
gli stessi tempi di quella postata da te.
Uso un Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
Ciao Manlio
Maggiori informazioni sulla lista
Python