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

[Pietro Battiston]

Il giorno ven, 20/05/2016 alle 14.59 +0200, alessandro medici ha
scritto:
> Il giorno 20 maggio 2016 14:12, Pietro Battiston
> <ml a pietrobattiston.it> ha scritto:
> > [...]
> > 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.
>  

Vero. Davo per scontato che gli altri processi non stessero facendo "la
stessa cosa"... ma in effetti questi aspetti sono (almeno per me)
complessi.


> >  - "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.

Sì, infatti: il mio commento non era tanto su quel che quella curva
sembri, ma sull'idea che davanti ad una eventuale "reverse logarithmic"
uno debba gridare all'eleganza dell'universo, quando sarebbe più
naturale un'iperbole.

Il dubbio che mi resta davanti a quei grafici è come sia possibile che
passando da 1 a 2, o 3, core si ottenga una riduzione (piccola ma
abbastanza evidente) del work time. Potrà essere dovuto al fatto che i
vari processi fanno esattamente lo stesso lavoro e c'è una qualche
forma di caching intelligente tra core?

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

Concordo. Ma dask è in un certo senso estremamente semplice. Se
soddisfa le tue necessità e le tue necessità coinvolgono un array numpy
grosso, le operazioni che fai saranno praticamente identiche
all'utilizzo di numpy... tranne che saranno distribuite su tutto quel
che ti pare.
(A me poi interessa particolarmente il supporto per le strutture
pandas)

Quello che devo ancora capire è solo quale fetta delle mie necessità
soddisfi!

Pietro