Il giorno ven, 20/05/2016 alle 11.56 +0200, Marco Beri ha scritto: > 2016-05-20 11:46 GMT+02:00 Marco Beri <marcob...@gmail.com>: > > 2016-05-20 11:39 GMT+02:00 Strap <l...@strap.it>: > > > Ciao a tutti, > > > per curiosità, ma soprattutto per vedere l'effetto che fa :-P, > > > condivido con > > > voi il seguente link: https://www.peterbe.com/plog/deco > > Bello! Certo che tre sleep(5) in parallelo vanno bene. > > Vedo meno bene tre loop che fanno robe cpu intensive :-) > > > Ho parlato troppo presto... Poi nel resto dell'articolo fa degli > esempi molto più fighi! >
Beh, l'obiezione non era insensata... https://www.peterbe.com/plog/time-to-do-concurrent-cpu-bound-work menziona un calo di efficienza (ovviamente in termini di tempo di calcolo totale) notevole. Le due cose che _non_ menziona, e che credo possano essere rilevanti, sono: - il suo Macbook Pro ha (credo) 4 core fisici: se ne vede 8 è grazie all'hyperthreading, che però è meno effettivo (vado a braccio su cose lette qua e là) se tutti i processi "fanno la stessa cosa" (ma è curioso che comunque da 2 a 3 e da 3 a 4 processi un calo netto ci sia già) - "multiprocessing" implica (a meno di eccezioni notevoli) "pickle di tutto" (Per la cronaca: ci infila un paio di panzane, tipo che il secondo grafico dimostri "The individual work withing each process is not generally slowed down much", e che la curva blu sia "reverse logarithmic") Mi stupisce peraltro un po' che pydron, la libreria a cui i creatori di deco dicono di ispirarsi, sia stata pensata per l'astrofisica... perché per quel che riguarda le applicazioni scientifiche (o più precisamente, ovunque ci sia un array numpy), dask ( http://dask.pydata.org ) mi sembra la salvezza (finora per quel che mi riguarda ci ho fatto solo prove molto semplici, ma mi sembra che batta ad occhi chiusi un approccio standard con multiprocessing o un suo wrapper). Pietro _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
