[Python] Decorated Concurrency - Python multiprocessing made really really easy

[alessandro medici]

Il giorno 20 maggio 2016 14:12, Pietro Battiston <ml a pietrobattiston.it> ha
scritto:

> Il giorno ven, 20/05/2016 alle 11.56 +0200, Marco Beri ha scritto:
> > 2016-05-20 11:46 GMT+02:00 Marco Beri <marcoberi a gmail.com>:
> > > 2016-05-20 11:39 GMT+02:00 Strap <lab a 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à)
>

mica tanto curioso: anche il sistema vuol dire la sua, e se gli chiedi
tutti i core te li concede 'a singhiozzo'. Già imbattuto, e spesso, nel
caso.


> - "multiprocessing" implica (a meno di eccezioni notevoli) "pickle di
> tutto"
>

? cioè i dati vengono trasmessi via pickle e non via puntatori? Sure?
O invece non ho capito cosa affermi? Sorry per la mia ignoranza, ma
sono anziano e con i capelli MOLTO grigi.

>
> (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")
>

Lo farò girare, ma in ogni caso il primo giudizio è solo soggettivo:
conta poco. Per la seconda curva hai ragione: sembra più che altro
una semplice proporzionalità inversa al numero dei thread fino ai 3.
Oltre, secondo me, si nota l'effetto sistema.

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

Toh: un fiorire di suggerimenti :-) Bene, sarò occupato anche questo w.e.
:-)

Ma in realtà mi piace la semplicità dell'approccio. Il che vale tempo
nello sviluppare. L'unica cosa che non ho davvero capito è quanto sia
thread-safe maneggiare un dizionario in quel modo. Ci giocherò.


> Pietro
>

Alex.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20160520/431b7b82/attachment.html>