[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