<br><br><div class="gmail_quote">Il giorno 11 maggio 2010 19.16, Manlio Perillo <span dir="ltr"><<a href="mailto:manlio_perillo@libero.it">manlio_perillo@libero.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Ciao<br></blockquote><div>Ciao Manlio!<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
La traduzione non è corretta.<br>
Meglio "limitato dalla CPU", o qualcosa di simile.<br></blockquote><div> </div><div> Ti ringrazio, ci speravo che intervenissi per proporre una traduzione appropriata :)<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Il codice che hai postato usa il threading nel modo sbagliato, perchè le<br>
due funzioni sono chiamate in modo sequenziale.<br></blockquote><div> 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)</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Prima aspetti che il primo thread finisce, e quindi esegui il secondo.<br>
<div class="im"><br></div></blockquote><div>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. </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> 3) usando la fork [3]<br>
><br>
> Ho aggiunto il test per la fork in quanto creando un nuovo processo il<br>
> GIL non dovrebbe dare problemi, giusto?<br>
<br>
</div>Si.<br></blockquote><div>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.</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> Beh ecco i risultati sul mio P4 3,00GHz:<br>
> 1) sequenziale<br>
> ----------------------<br>
> real 0m35.363s<br>
> user 0m34.831s<br>
> sys 0m0.087s<br>
> ----------------------<br>
> 2) threaded<br>
> ----------------------<br>
> real 1m30.482s<br>
> user 1m25.342s<br>
> sys 0m28.125s<br>
> ----------------------<br>
> 3) forked<br>
> ----------------------<br>
> real 0m52.938s<br>
> user 1m30.927s<br>
> sys 0m0.395s<br>
> ----------------------<br>
><br>
<br>
</div>Io ottengo risultati molto diversi.<br>
<br>
La versione sequenziale:<br>
real 0m21.341s<br>
user 0m20.185s<br>
sys 0m0.260s<br>
<br>
La versione con threads:<br>
real 0m26.279s<br>
user 0m22.101s<br>
sys 0m5.244s<br>
<br>
La versione con i processi:<br>
real 0m13.160s<br>
user 0m10.313s<br>
sys 0m0.056s<br></blockquote><div>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<br>Interessante invece la versione coi threads che dimostra appunto come anzichè migliorare la situazione la peggiori, anche se nel caso di pochi secondi.<br>
<br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
La versione con i threads "corretta" (senza i due join) ha praticamente<br>
gli stessi tempi di quella postata da te.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Uso un Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz<br>
<br></blockquote><div>Bel procio.</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Ciao Manlio<br>
</blockquote><div>Ciao, grazie per il bench. Come saprai il tuo interesse è sempre ben gradito :)<br><br>Buona notte. </div></div><br>-- <br>Alessandro A.<br>