[Python] GIL e fork - multiprocesso -

[Alessandro Agosto]

Il giorno 11 maggio 2010 19.16, Manlio Perillo <manlio_perillo a libero.it> ha
scritto:

> Ciao
>
Ciao Manlio!

> La traduzione non è corretta.
> Meglio "limitato dalla CPU", o qualcosa di simile.
>

 Ti ringrazio, ci speravo che intervenissi per proporre una traduzione
appropriata :)

Il codice che hai postato usa il threading nel modo sbagliato, perchè le
> due funzioni sono chiamate in modo sequenziale.
>
 Beh devo ammettere che non ho mai usato il multithreading prima in python,
e quell'esempio l'ho preso tal e quale a quel documento di cui sopra che
parla del GIL. Ti ringrazio della segnalazione, in effetti trattandosi di
multithreading, sebbene l'abbia usato solo in C/C++, mi sembrava strano come
applicazione, ma del resto python ha sempre qualcosa di nuovo da insegnarmi,
e per questo lo trovo infinitamente attraente (per quanto possa esserlo un
linguaggio di programmazione, vedi: intrigante, attrae la mia curiosità,
NdT)

>
> Prima aspetti che il primo thread finisce, e quindi esegui il secondo.
>
> Uhm, adesso comunque mi hai chiarito proprio le idee, ho provato a togliere
i join, a preparare i due threads insieme e quindi eseguirli
contemporaneamente ma senza la join, per terminare il programma su Mac devo
premere un tasto, altrimenti non mi restituisce il terminale, ma niente di
chè, solo benchmarking.

> > 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.
>
Perfetto, infatti mi ricordo che già mi consigliasti come metodo per scalare
con python (qualche tempo fà) in alternativa ai thread, l'uso di più
processi. Dato che voglio provare a non assillare chi utilizza questo o quel
programma vorrei appunto provare a creare processi alla nginx, in base al
numero di workers specificati in un file di configurazione. Ma prima voglio
imparare bene come e cosa è python.

>
> > 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
>
Beh la versione sequenziale mi sembra dipenda esclusivamente dalla potenza
dei processori ed evidentemente i tuoi battono i miei p4 (eheh) in potenza
di calcolo :p
Interessante invece la versione coi threads che dimostra appunto come
anzichè migliorare la situazione la peggiori, anche se nel caso di pochi
secondi.

Trovo grandiose le prestazioni dei processi, alla faccia di chi li critica
in favore dei thread (almeno con python). Ha quasi dimezzato le prestazioni
del calcolo sequenziale e praticamente la metà di quelli che usano i
threads.


> La versione con i threads "corretta" (senza i due join) ha praticamente
> gli stessi tempi di quella postata da te.
>

A me addirittura, come ho detto, non libera il terminale automaticamente,
comunque senza i due join con un solo processore attivo mi pare (adesso non
ricordo esattamente) mi sembra avesse qualche secondo in meno, ma forse
complice il lancio contemporaneo dei due threads.

> Uso un Intel(R) Core(TM)2 CPU T7200  @ 2.00GHz
>
> Bel procio.

>
> Ciao  Manlio
>
Ciao, grazie per il bench. Come saprai il tuo interesse è sempre ben gradito
:)

Buona notte.

-- 
Alessandro A.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: http://lists.python.it/pipermail/python/attachments/20100512/6aa9afd8/attachment.htm