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 _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
