Re: [Python] GIL e fork - multiprocesso -

[Manlio Perillo]

Alessandro Agosto ha scritto:
> 
> 
> Il giorno 11 maggio 2010 19.16, Manlio Perillo  > 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.
> 

Scusa per aver aumentato la tua confusione, ma qui ho scritto una
sciocchezza.

I due thread *non* vengono eseguiti in modo sequenziale, ma in parallelo.

> [...]
> 
> Prima aspetti che il primo thread finisce, e quindi esegui il secondo.
> 
> Uhm, adesso comunque mi hai chiarito proprio le idee, 

Purtroppo temo di averti ulteriormente confuso ;-).

> 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. 

Senza join il thread principale termina prima dei due threads addizionali.
Come viene gestito dipende probabilmente dal OS, ma io l'ho solo testato
su Linux.

> [...]
>
> Trovo grandiose le prestazioni dei processi, alla faccia di chi li
> critica in favore dei thread (almeno con python). 

Il problema è appunto il GIL.
Inoltre il tuo è un bench abbastanza particolare.

Comunque si, di solito è meglio usare i processi, puoi usare anche il
package multiprocessing.

Ma il multithreading in alcuni casi fa bene il suo lavoro, purchè usati
con consapevolezza.
I processi non sono banali da utilizzare, e di solito conviene affidarsi
a qualcosa come multiprocessing, twisted o Qt.


> [...] 

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

Di nulla


Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] unpack requires a string argument of length 8?

[Cynthia Zambrano]

tti 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
> > > --
> > > real0m35.363s
> > > user0m34.831s
> > > sys0m0.087s
> > > --
> > > 2) threaded
> > > --
> > > real1m30.482s
> > > user1m25.342s
> > > sys0m28.125s
> > > --
> > > 3) forked
> > > --
> > > real0m52.938s
> > > user1m30.927s
> > > sys0m0.395s
> > > --
> > >
> >
> > Io ottengo risultati molto diversi.
> >
> > La versione sequenziale:
> > real0m21.341s
> > user0m20.185s
> > sys 0m0.260s
> >
> > La versione con threads:
> > real0m26.279s
> > user0m22.101s
> > sys 0m5.244s
> >
> > La versione con i processi:
> > real0m13.160s
> > user0m10.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.html
>
> --
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
> Fine di Digest di Python, Volume 51, Numero 8
> *
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python