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