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

[enrico franchi]

2016-05-27 13:54 GMT+01:00 Roberto Polli :

> Con un broker ;)
>
> https://en.wikipedia.org/wiki/Software_transactional_memory
>

Dai, sfortunatamente non puo' funzionare. Cioe', STM funziona. Non funziona
per questo use-case. Tanto per dirne una, ci sono seri problemi su come
infilare quasi qualunque tipo di I/O in sto modello. Tu qui ti troveresti a
volere fare girare Python arbitrario dentro transazioni.

Che voglio dire... ci stiamo arrivando. O meglio, Armin Rigo ci sta
arrivando... ed e' tipo in completa avanguardia (ovvero, quelli che ci
hanno provato prima hanno fallito per vari motivi).


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 27 maggio 2016 15:51, alessandro medici <
alexxandro.med...@gmail.com> ha scritto:

>
> Il giorno 27 maggio 2016 14:54, Roberto Polli  ha
> scritto:
>
>> Il 27 maggio 2016 14:41, enrico franchi  ha
>> scritto:
>> > Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?
>>
>> Con un broker ;)
>>
>> https://en.wikipedia.org/wiki/Software_transactional_memory
>>
>> @alessandro.medici se vuoi sperimentare, l'affare STM pare croccante,
>> io ovviamente so solo che esiste ;)
>
>
ecco, senza cercarlo:

http://pypy.readthedocs.io/en/latest/stm.html

Alex.
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 27 maggio 2016 14:54, Roberto Polli  ha
scritto:

> Il 27 maggio 2016 14:41, enrico franchi  ha
> scritto:
> > Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?
>
> Con un broker ;)
>
> https://en.wikipedia.org/wiki/Software_transactional_memory
>
> @alessandro.medici se vuoi sperimentare, l'affare STM pare croccante,
> io ovviamente so solo che esiste ;)
>

La pagina che ho appena passato nella mail precedente lo richiama, alla fine
di una serie di ottime ed interessanti osservazioni. Sul fatto che sia
croccante
non dubito.
Sul fatto che le mie ferie siano limitate, meno ancora :-(

Alex.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 27 maggio 2016 14:41, enrico franchi 
ha scritto:

>
>
> 2016-05-25 18:02 GMT+01:00 alessandro medici 
> :
>
>>
>>>
> Perche' scusa... se sai fare una libreria che ti consente di avere oggetti
> condivisi fra processi *senza* bisogno di lock, allora direi che sai anche
> fare una libreria che ti consente di condividere oggetti fra thread *senza*
> bisogno di lock.
> E a questo punto hai finito, hai vinto. Hai ucciso il GIL.
>

Magari. Sto solo cercando un modo che mi permetta di lavorare più
comodamente.
Se e come e quanto sarà possibile, vedrò.
E giuro sulla mia tessera di Giovane Marmotta che, quando tornerò dai bagni
rossi
relazionerò sul mio più che probabilmente certo fallimento :-)

ps:
http://python-notes.curiousefficiency.org/en/latest/python3/multicore_python.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Roberto Polli]

Il 27 maggio 2016 14:41, enrico franchi  ha scritto:
> Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?

Con un broker ;)

https://en.wikipedia.org/wiki/Software_transactional_memory

@alessandro.medici se vuoi sperimentare, l'affare STM pare croccante,
io ovviamente so solo che esiste ;)

Pax,
R.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2016-05-27 13:41 GMT+01:00 enrico franchi :

> Ok... sto barando. Potresti avere questo oggetto "magico" nell'area
> condivisa e poi passarti oggettini che sono solo riferimenti a
> quell'oggetto (ma che a loro volta non sono condivisi).
>

Ah, ça va sans dire, questo oggetto sarebbe eterno. Non ci puoi fare sopra
reference counting. Non puoi sapere chi lo sta usando. Vuole dire che nasce
e dura... finche' tutta la pagina non viene deallocata.

Che magari finche' e' *un* oggetto puoi anche permetterlo. Ma non mi e'
chiara quale sarebbe l'utilita'.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2016-05-25 18:02 GMT+01:00 alessandro medici :

>
>>
>> Scusa... parliamoci chiaro. Diciamo che hai scritto un allocatore che
>> lavora su un chunk di memoria condivisa.
>> Che vuole anche dire condivisa fra piu' processi (se no non e'
>> particolarmente interessante).
>>
>> Mi spieghi come hai intenzione di fare si che tutto questo non si rompa
>> male *senza* usare lock?
>>
>
> Scrivendoci sopra solo quando NON ho altri processi che ci lavorano.
>

Scusa, e come fai a sapere che gli altri processi *non* ci lavorano?



> Per esempio lanciando
> gli altri processi dopo averci scritto sopra, ed ovviamente non parlo
> di allocare nello heap di python (faccio riferimento al primo esempio
> nella pagina).
>

Quindi stiamo parlando di un oggetto che scrivi in questa area condivisa
(qui c'e' un solo processo).
Poi crei altri processi, che pero' non possono fare *nulla* con
quell'oggetto. Perche'? Perche' anche semplicemente fare f(obj) ha effetto
sul reference counting.
Ma anche o = obj.

Quindi gli altri processi non possono manco referenziare sto oggetto; non
lo possono vedere.

Ok... sto barando. Potresti avere questo oggetto "magico" nell'area
condivisa e poi passarti oggettini che sono solo riferimenti a
quell'oggetto (ma che a loro volta non sono condivisi).

Il problema sarebbe che non hai la semantica di Python (e.g., non puoi
aggiungere, togliere un attributo...). Sarebbe un oggetto puramente
immutabile. Immutabilissimo.
E allora quale e' il vantaggio di averlo cacciato in memoria condivisa?
Puoi fare cose piu' semplici.

E non puoi nemmeno avere cose tipo il creatore modifica. Perche'? Perche'
dovresti garantire che tutte le modifiche sono atomiche. Ora, siccome non
hai lock, non puoi "rendere atomica dal punto di vista di chi legge".
Puoi *solo* usare cose atomiche per davvero. Tipo, non puoi facilmente
avere un dizionario Python... in Python molte operazioni sui dizionari sono
atomiche, perche' hai il GIL. Ma in questo caso... il GIL non ce lo hai.
Quindi

Quindi per fare qualcosa di vagamente utile dovresti risolvere gli stessi
problemi che devono risolvere quelli che vogliono levare il GIL.

Perche' scusa... se sai fare una libreria che ti consente di avere oggetti
condivisi fra processi *senza* bisogno di lock, allora direi che sai anche
fare una libreria che ti consente di condividere oggetti fra thread *senza*
bisogno di lock.
E a questo punto hai finito, hai vinto. Hai ucciso il GIL.


>
-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Roberto Polli]

Entrata a gamba tesa ;)

- Enrico Franchi ha ((quasi) sempre) ragione;
- multithreading è un bordello in-testabile;
- pthread_mutex_lock() finisce per diventare CPU bound, cosa che è male;
- un race nei lock() finisce solitamente male, e capita magari dopo
qualche mese;

A suo tempo, scrivendo un software in C:
- mi salvai usando posix message queues implementate da Linux;
- il gioco funge magicamente da circa 6 anni in un ambiente abbastanza critico.

Di recente ho usato multiprocessing e mp.Queue per un software io-bound:

  - funziona senza problemi;
  - il codice è molto leggibile;
  - ogni componente è separato e facilmente testabile;
  - eventuali parti shmem sono gestite dalla PSL che è ben testata e mantenuta;

Implementare il tuo multithread | multiprocess con shared memory è un
ottimo modo per interiorizzare il tutto.
Non è vietato o sbagliato: è più complesso da gestire e (imho) non
scala orizzontalmente.


Pax,
R.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 25 maggio 2016 18:25, enrico franchi 
ha scritto:

>
>
> 2016-05-25 17:07 GMT+01:00 alessandro medici 
> :
>
>>
>>> Come al solito, passeggiare per la libreria porta spesso a dei bei
>> risultati:
>>  https://docs.python.org/3.5/c-api/memory.html
>> spiega anche bene come si potrebbe fare.
>>
>>
> A me sembra proprio di no.
>
> Scusa... parliamoci chiaro. Diciamo che hai scritto un allocatore che
> lavora su un chunk di memoria condivisa.
> Che vuole anche dire condivisa fra piu' processi (se no non e'
> particolarmente interessante).
>
> Mi spieghi come hai intenzione di fare si che tutto questo non si rompa
> male *senza* usare lock?
>

Scrivendoci sopra solo quando NON ho altri processi che ci lavorano. Per
esempio lanciando
gli altri processi dopo averci scritto sopra, ed ovviamente non parlo
di allocare nello heap di python (faccio riferimento al primo esempio nella
pagina).
Mi rendo conto che è un lock logico ma funzionerebbe lo stesso.
Ci proverò e saprò dire come va.


>> Sembrerebbe anche qui:
>>
>> https://docs.python.org/3.5/library/multiprocessing.html#module-multiprocessing.sharedctypes
>>
>> Che era, in effetti, quel che cercavo.
>>
>
> Io continuo a credere che tu stia ficcandoti da solo in un bagno di sangue.
> Perche' sei convinto che la memoria condivisa ti *serva*?
>
>

mi cito: per vedere l'effetto che fa :-)

Nel senso che adesso NON ne ho bisogno, ma voglio provarlo per vedere SE
come e quando, prima o poi, mi converrebbe usarlo.

E grazie a tutti per le dritte ed i suggerimenti impliciti ed espliciti.

>
>

>

>> Di passaggio vedo che pickle è usato solo per Queue in code FIFO ma che
>> la Pipe sottostante non la usa.
>>
>
> Si, e' corretto. Il motivo e' che la pipe "astrae meno" e ti da
> fondamentalmente un'interfaccia a "byte".
> E apre tutto il problema di come separare i messaggi, cosa considerare un
> messaggio... nota che le pipe non sono multi reader/multi writer (a meno
> che non aggiungi tu sincronizzazione... che vuole dire che di fatto ti
> re-implementi le Queue -- nota che per vari motivi le Queue di mp hanno
> *anche* un thread per darti la semantica attesa).
>

Non ci pensavo proprio :-)

>
>  Io personalmente quello che spesso e' fare completamente a mano. Non
> trovo le pipe di mp particolarmente utili. In molti casi un socket unix
> domain a datagrammi e' proprio la cosa che vuoi, per dire.
>

Di nuovo grazie per la dritta: non ci avevo proprio pensato.

Alex
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2016-05-25 17:07 GMT+01:00 alessandro medici :

>
>> Come al solito, passeggiare per la libreria porta spesso a dei bei
> risultati:
>  https://docs.python.org/3.5/c-api/memory.html
> spiega anche bene come si potrebbe fare.
>
>
A me sembra proprio di no.

Scusa... parliamoci chiaro. Diciamo che hai scritto un allocatore che
lavora su un chunk di memoria condivisa.
Che vuole anche dire condivisa fra piu' processi (se no non e'
particolarmente interessante).

Mi spieghi come hai intenzione di fare si che tutto questo non si rompa
male *senza* usare lock?
Che ok... alcune cose possono essere fatte con CAS (tipo i reference
counters); ma, come dicevo, CAS funziona bene quando hai poche scritture e
tante letture. Mentre qui hai un numero relativamente bilanciato delle due
cose. E comunque questo vorrebbe dire anche cambiare l'implementazione di
Object (IIRC non usa roba CAS). Ma le altre?





> >> In Go puoi usare i channel, ma anche qui alla fine usi la memoria
>> >> condivisa, solo che la sincronizzazione è gestita dal runtime.
>> >> Ma sempre in Go, spesso la soluzione più semplice e suggerita in
>> >> mailing list, è quella di usare un mutex.
>> >
>> >
>> > Funziona davvero (in C) per riscrivere spesso, ma inutile se quel che ti
>> > serve (in Python) è lavorare su
>> > troppi dati eguali che cambiano ogni tanto :-(  e vanno riletti spesso.
>>
>
> Sembrerebbe anche qui:
>
> https://docs.python.org/3.5/library/multiprocessing.html#module-multiprocessing.sharedctypes
>
> Che era, in effetti, quel che cercavo.
>

Io continuo a credere che tu stia ficcandoti da solo in un bagno di sangue.
Perche' sei convinto che la memoria condivisa ti *serva*?


>
> Di passaggio vedo che pickle è usato solo per Queue in code FIFO ma che
> la Pipe sottostante non la usa.
>

Si, e' corretto. Il motivo e' che la pipe "astrae meno" e ti da
fondamentalmente un'interfaccia a "byte".
E apre tutto il problema di come separare i messaggi, cosa considerare un
messaggio... nota che le pipe non sono multi reader/multi writer (a meno
che non aggiungi tu sincronizzazione... che vuole dire che di fatto ti
re-implementi le Queue -- nota che per vari motivi le Queue di mp hanno
*anche* un thread per darti la semantica attesa).

 Io personalmente quello che spesso e' fare completamente a mano. Non trovo
le pipe di mp particolarmente utili. In molti casi un socket unix domain a
datagrammi e' proprio la cosa che vuoi, per dire.

Ma insomma... c'e' un po' da capire cosa ti serve, ma in generale non e'
complicato da implementare.



> Ok, appena ho un po' di tempo libero mi ci metto a giocare per vedere
> l'effetto che fa :-)
>
>

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

>
>
> >>
> >> Quando parlo di memoria condivisa intendo a dettaglio implementativo,
> >> magari nascosto sotto l'astrazione di una libreria o di un linguaggio.
> >> Ad esempio in Rust alla fine *usi* memoria condivisa, ma il linguaggio
> >> ti permette di ragionare senza pensare a sincronizzazioni esplicite.
> >
> >
> > Concordo.
> >
> > Occorrebbe che il linguaggio potesse chiamare dal sistema, ed ottenere,
> > un area condivisa da vari processi. Ed è proprio questo che mi
> piacerebbe.
> >
>
> Vedi shmget e mmap:
> https://trac.nginx.org/nginx/browser/nginx/src/os/unix/ngx_shmem.c
>
> Ma come ti ha già scritto Enrico, l'accesso diretto ad un area di
> memoria non è banale in Python, a meno di non usare tipi primitivi a
> dimensione fissa.
>
>
Come al solito, passeggiare per la libreria porta spesso a dei bei
risultati:
 https://docs.python.org/3.5/c-api/memory.html
spiega anche bene come si potrebbe fare.


>>
> >> In Go puoi usare i channel, ma anche qui alla fine usi la memoria
> >> condivisa, solo che la sincronizzazione è gestita dal runtime.
> >> Ma sempre in Go, spesso la soluzione più semplice e suggerita in
> >> mailing list, è quella di usare un mutex.
> >
> >
> > Funziona davvero (in C) per riscrivere spesso, ma inutile se quel che ti
> > serve (in Python) è lavorare su
> > troppi dati eguali che cambiano ogni tanto :-(  e vanno riletti spesso.
>

Sembrerebbe anche qui:
https://docs.python.org/3.5/library/multiprocessing.html#module-multiprocessing.sharedctypes

Che era, in effetti, quel che cercavo.

Di passaggio vedo che pickle è usato solo per Queue in code FIFO ma che
la Pipe sottostante non la usa.

Ok, appena ho un po' di tempo libero mi ci metto a giocare per vedere
l'effetto che fa :-)

Alex
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Manlio Perillo]

2016-05-25 1:43 GMT+02:00 alessandro medici :
>
>
>>
>>
>> Quando parlo di memoria condivisa intendo a dettaglio implementativo,
>> magari nascosto sotto l'astrazione di una libreria o di un linguaggio.
>> Ad esempio in Rust alla fine *usi* memoria condivisa, ma il linguaggio
>> ti permette di ragionare senza pensare a sincronizzazioni esplicite.
>
>
> Concordo.
>
> Occorrebbe che il linguaggio potesse chiamare dal sistema, ed ottenere,
> un area condivisa da vari processi. Ed è proprio questo che mi piacerebbe.
>

Vedi shmget e mmap:
https://trac.nginx.org/nginx/browser/nginx/src/os/unix/ngx_shmem.c

Ma come ti ha già scritto Enrico, l'accesso diretto ad un area di
memoria non è banale in Python, a meno di non usare tipi primitivi a
dimensione fissa.

>>
>> In Go puoi usare i channel, ma anche qui alla fine usi la memoria
>> condivisa, solo che la sincronizzazione è gestita dal runtime.
>> Ma sempre in Go, spesso la soluzione più semplice e suggerita in
>> mailing list, è quella di usare un mutex.
>
>
> Funziona davvero (in C) per riscrivere spesso, ma inutile se quel che ti
> serve (in Python) è lavorare su
> troppi dati eguali che cambiano ogni tanto :-(  e vanno riletti spesso.

Inutile? Sei davvero sicuro?

Il mutex è inutile solo se i dati, una volta creati, sono imutabili.
Ma non mi sembra il tuo caso.
Per un pattern di accesso con uno o pochi scrittori e molti lettori,
hanno inventato apposta il:
https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

>
> Quando parlo di memoria condivisa intendo a dettaglio implementativo,
> magari nascosto sotto l'astrazione di una libreria o di un linguaggio.
> Ad esempio in Rust alla fine *usi* memoria condivisa, ma il linguaggio
> ti permette di ragionare senza pensare a sincronizzazioni esplicite.
>

Concordo.

Occorrebbe che il linguaggio potesse chiamare dal sistema, ed ottenere,
un area condivisa da vari processi. Ed è proprio questo che mi piacerebbe.


> In Go puoi usare i channel, ma anche qui alla fine usi la memoria
> condivisa, solo che la sincronizzazione è gestita dal runtime.
> Ma sempre in Go, spesso la soluzione più semplice e suggerita in
> mailing list, è quella di usare un mutex.
>

Funziona davvero (in C) per riscrivere spesso, ma inutile se quel che ti
serve (in Python) è lavorare su
troppi dati eguali che cambiano ogni tanto :-(  e vanno riletti spesso.

>
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Manlio Perillo]

2016-05-24 15:00 GMT+02:00 enrico franchi :
>
> [...]
>> Perchè tutti i linguaggi (o meglio le loro implementazioni) attuali
>> che conosco, tranne Erlang (ed Haskell, come caso speciale), usano
>> memoria condivisa, anche se offrono supporto per il message passing
>> (tramite channel).
>
>
> Ma non e' questione di linguaggio: e' questione di applicazione. Il
> linguaggio diventa rilevante solo quando non ti lascia altra scelta.
>
>>
>> Quindi software normale scritto in questi linguaggi usa memoria condivisa.
>
>
> Mah... diciamo che non sono d'accordo. *Puoi* usare memoria condivisa.
> Certo. Questo non vuole dire che sia considerata una best practice farlo.
> Anzi.
>
> E mi sembra un trend dell'industria in un circolo virtuoso con quelli che
> fanno linguaggi e librerie. *Oggi* prova a presentare un design document
> fatto tutto a botte di synchronized e vediamo come va a finire (certo, se
> chi fa la review e' rimasto a come si faceva software negli anni '90 c'e'
> anche caso che passi...).
>

Quando parlo di memoria condivisa intendo a dettaglio implementativo,
magari nascosto sotto l'astrazione di una libreria o di un linguaggio.
Ad esempio in Rust alla fine *usi* memoria condivisa, ma il linguaggio
ti permette di ragionare senza pensare a sincronizzazioni esplicite.

In Go puoi usare i channel, ma anche qui alla fine usi la memoria
condivisa, solo che la sincronizzazione è gestita dal runtime.
Ma sempre in Go, spesso la soluzione più semplice e suggerita in
mailing list, è quella di usare un mutex.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

Il 24 mag 2016 3:02 PM, "enrico franchi"  ha
scritto:

> Ah, ok. Beh, allora vai in seg fault alla velocita' della luce,
sperabilmente prima di avere corrotto dati.

Se ci vai alla velocità della luce, per definizione ci arrivi prima. Non
serve sperare.

Ciao.
Marco.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2016-05-23 0:13 GMT+01:00 Manlio Perillo :

> > Nel 2016 praticamente tutti
> > quelli che hanno architettura a memoria condivisa le stanno migrando, a
> > parte in determinati casi specifici (e.g., embedded, kernel,
> possibilmente
> > roba come pipeline audio e video, dove hai veramente tanti dati e
> copiarli
> > diventa fastidioso).
> >
>
> A chi ti riferisci con "tutti"?
>


Il fatto che un linguaggio supporti la feature, non vuole dire che la devi
usare nella tua architettura.

Perfino in Java, che tradizionalmente era molto orientato nella direzione
della memoria condivisa, quasi tutti i nuovi pezzi di concorrenza sono
fatti per una strategia diversa.

Che so... pensa agli stream... Ma basta progettare in modo sensato cose
usando gli executor e ancora una volta *non* avrai stato non locale.




>
> Perchè tutti i linguaggi (o meglio le loro implementazioni) attuali
> che conosco, tranne Erlang (ed Haskell, come caso speciale), usano
> memoria condivisa, anche se offrono supporto per il message passing
> (tramite channel).
>

Ma non e' questione di linguaggio: e' questione di applicazione. Il
linguaggio diventa rilevante solo quando non ti lascia altra scelta.


> Quindi software normale scritto in questi linguaggi usa memoria condivisa.
>

Mah... diciamo che non sono d'accordo. *Puoi* usare memoria condivisa.
Certo. Questo non vuole dire che sia considerata una best practice farlo.
Anzi.

E mi sembra un trend dell'industria in un circolo virtuoso con quelli che
fanno linguaggi e librerie. *Oggi* prova a presentare un design document
fatto tutto a botte di synchronized e vediamo come va a finire (certo, se
chi fa la review e' rimasto a come si faceva software negli anni '90 c'e'
anche caso che passi...).




-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2016-05-23 10:29 GMT+01:00 alessandro medici :

>
>> E capisci anche che praticamente *tutte* le operazioni su questi oggetti
>> devono essere protette da un lock. Perche'? Beh... perche' se siamo in
>> memoria condivisa vuole dire che piu' processi possono accedervi (o
>> meglio... se li ho messi in memoria condivisa e' perche' voglio accederci
>> da piu' processi).
>>
>> Ecco... come ne usciamo? Abbiamo due soluzioni:
>> 1. mettiamo un lock poco granulare sull'area di memoria
>> 2. mettiamo lock granulari sugli oggetti
>>
>
> Non mi sono spiegato: non si metterebbe NESSUN lock per l'accesso a
> quest'area. Sarebbero affari del programma quando come e perché lavorarci
> sopra.
>

Ah, ok. Beh, allora vai in seg fault alla velocita' della luce,
sperabilmente prima di avere corrotto dati.




-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

>
>
> E capisci anche che praticamente *tutte* le operazioni su questi oggetti
> devono essere protette da un lock. Perche'? Beh... perche' se siamo in
> memoria condivisa vuole dire che piu' processi possono accedervi (o
> meglio... se li ho messi in memoria condivisa e' perche' voglio accederci
> da piu' processi).
>
> Ecco... come ne usciamo? Abbiamo due soluzioni:
> 1. mettiamo un lock poco granulare sull'area di memoria
> 2. mettiamo lock granulari sugli oggetti
>

Non mi sono spiegato: non si metterebbe NESSUN lock per l'accesso a
quest'area. Sarebbero affari del programma quando come e perché lavorarci
sopra.

Per il resto, e' un oggetto che riserva molte sorprese, e non del tipo
> divertente.
>
> Se hai un problema I/O bound guardati cose come gevent, tornado, il
> vecchio twisted o il nuovo asyncio.
>

concordo per asyncio, se del caso.


> Se hai un problema CPU bound... boh, fai offload a chi puoi. Numpy in
> certi casi. Se no a volte con un po' di attenzione si possono fare cose
> belline con multiprocessing. Poi per dire l'ultima volta che lo ho messo in
> produzione mi sono scritto a mano tutte le primitive di comunicazione fra
> processi, perche' le implementazioni di default di multiprocessing non
> facevano per me (semantica, + tirano su thread, + sono lente... etc etc
> etc). Questo non vuole dire che per te non andranno bene: probabilmente se
> sono ancora li, vuole dire che vanno bene per la maggior parte delle
> persone.
>

concordo anche qui.  In effetti stavo proprio pensando a casi specifici.
Proverò.

Alex
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Manlio Perillo]

2016-05-23 0:56 GMT+02:00 enrico franchi :
>
>
> 2016-05-21 13:24 GMT+01:00 alessandro medici :
>>
> [...]
>>
>> Il ragionamento che fai fila, però... Mettiamola così: mi piacerebbe che
>> esistesse
>> un'opzione tale che permettesse di definire una variabile in uno spazio
>> condiviso ed
>> accessibile direttamente dai singoli processi. Starebbe poi a me gestirla.
>> E sicuramente
>> in molti casi sarebbe più veloce che impacchettare e spacchettare in giro
>> dati che, magari,
>> servono solo in lettura. Poi, se voglio darmi da solo la zappa sui piedi,
>> sono affari miei, in
>> pura logica Python :-)
>
>
> Si beh... come dire. Ora io capisco che a te piacerebbe questa feature. Io
> posso dirti che *credi* che ti piacerebbe. Nel 2016 praticamente tutti
> quelli che hanno architettura a memoria condivisa le stanno migrando, a
> parte in determinati casi specifici (e.g., embedded, kernel, possibilmente
> roba come pipeline audio e video, dove hai veramente tanti dati e copiarli
> diventa fastidioso).
>

A chi ti riferisci con "tutti"?

Perchè tutti i linguaggi (o meglio le loro implementazioni) attuali
che conosco, tranne Erlang (ed Haskell, come caso speciale), usano
memoria condivisa, anche se offrono supporto per il message passing
(tramite channel).

Quindi software normale scritto in questi linguaggi usa memoria condivisa.

> [...]


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2016-05-21 13:24 GMT+01:00 alessandro medici :

>
>
> Il giorno 21 maggio 2016 12:51, enrico franchi 
> ha scritto:
>
>>
>>
>> 2016-05-20 13:59 GMT+01:00 alessandro medici > >:
>>
>>>
>>> - "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.
>>>
>>
>> Non e' questione di ignoranza, basta rifletterci. Allora...
>> multi-*processing*.
>> Diciamo che e' sano assumere che siano piu' processi, ok? Quindi piu'
>> processi hanno spazi di indirizzamento separati (visto che sono appunto
>> processi multipli). Quindi... cosa se ne fa un processo di un puntatore a
>> uno spazio di indirizzamento a cui non ha accesso? Diciamo nulla? Ah... ma
>> c'e' la memoria condivisa... ecco, ora riflettiamo anche su questa cosa.
>> Quando tu scrivi
>>
>> foo = Bar()
>>
>> tu stai dicendo a Python di creare un oggetto. Bene. Non gli stai dicendo
>> dove crearlo. Il che vuole dire che non e' in memoria condivisa.
>> L'alternativa sarebbe immaginare che Python ficcasse *tutto quanto* in
>> memoria condivisa...
>>
>
> Già. Ho passato buona parte di ieri a guardarmi proprio il funzionamento
> del Manager
> dei processi. Ed ho lasciato a metà quello sul funzionamento di pickle.
>

Il mio consiglio e' di lasciare perdere quella parte di multiprocessing (a
dire il vero... io suggerirei di pensarci sopra 80 volte prima di fare roba
vera con multiprocessing -- poi ne parliamo --.

Non vuoi usare qualcosa che sia scomodo e bug prone come la memoria
condivisa, ma con le performance del message passing (anzi, sinceramente,
con le performance da fanalino di coda del message passing, visto che altre
implementazioni di concetti simili sono molto piu' efficienti).


> Il ragionamento che fai fila, però... Mettiamola così: mi piacerebbe che
> esistesse
> un'opzione tale che permettesse di definire una variabile in uno spazio
> condiviso ed
> accessibile direttamente dai singoli processi. Starebbe poi a me gestirla.
> E sicuramente
> in molti casi sarebbe più veloce che impacchettare e spacchettare in giro
> dati che, magari,
> servono solo in lettura. Poi, se voglio darmi da solo la zappa sui piedi,
> sono affari miei, in
> pura logica Python :-)
>

Si beh... come dire. Ora io capisco che a te piacerebbe questa feature. Io
posso dirti che *credi* che ti piacerebbe. Nel 2016 praticamente tutti
quelli che hanno architettura a memoria condivisa le stanno migrando, a
parte in determinati casi specifici (e.g., embedded, kernel, possibilmente
roba come pipeline audio e video, dove hai veramente tanti dati e copiarli
diventa fastidioso).

Detto questo, sarebbe una feature assolutamente complicatissima da
implementare e che costringerebbe a fare andare tutto come una lumaca e/o a
rompere completamente l'astrazione di Python.

1. Python non ha il concetto di "area di memoria". Costruisci un oggetto.
Python ci pensa. Qui tu dovresti in qualche modo dire a Python che un certo
oggetto deve essere in un'area di memoria condivisa.

2. Come lo facciamo? O lo facciamo in modo implicito (che e' ancora meno
banale) oppure inventiamo qualcosa tipo... boh

Foo.shared(...)

che ha la stessa semantica di un normale Foo(...) ma mette le cose in
memoria condivisa.

Bene: nell'esatto istante in cui tu scrivi quella cosa, vuole dire che un
bel po' di roba viene schiaffata in memoria condivisa. Per esempio
l'oggetto classe Foo deve finirci. Ma non solo... ci deve finire qualunque
oggetto nell'MRO di Foo. E stiamo cominciando a tirarci dietro parecchia
roba.

Pero' aspetta... magari io avevo da qualche parte una roba come:

class Foo(object):
def __init__(self):
self.bar = Bar()

Ecco, l'oggetto che stiamo assegnando a self.bar deve pure finire anche lui
in questa memoria condivisa. Lui, la sua classe e tutti i suoi antenati e
tutti gli oggetti che entrano a fare parte dell'istanza (e cosi'
ricorsivamente).

Ora... capisci che e' un bel po' di roba.

E capisci anche che praticamente *tutte* le operazioni su questi oggetti
devono essere protette da un lock. Perche'? Beh... perche' se siamo in
memoria condivisa vuole dire che piu' processi possono accedervi (o
meglio... se li ho messi in memoria condivisa e' perche' voglio accederci
da piu' processi).

Ecco... come ne usciamo? Abbiamo due soluzioni:
1. mettiamo un lock poco granulare sull'area di memoria
2. mettiamo lock granulari sugli oggetti

Bene... in un caso stiamo replicando, di fatto, i problemi del GIL anche a
multi-processing. Nell'altro invece stiamo facendo la cosa che tutti quelli
che hanno provato a togliere il GIL ci hanno detto essere lenta. In pratica
abbiamo perso in partenza. E nota che la cosa e' drammatica: ogni volta che
passi un oggetto ad una funzione (o che ritorni) devi agire sul 

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

[alessandro medici]

Il giorno 21 maggio 2016 12:51, enrico franchi 
ha scritto:

>
>
> 2016-05-20 13:59 GMT+01:00 alessandro medici 
> :
>
>>
>> - "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.
>>
>
> Non e' questione di ignoranza, basta rifletterci. Allora...
> multi-*processing*.
> Diciamo che e' sano assumere che siano piu' processi, ok? Quindi piu'
> processi hanno spazi di indirizzamento separati (visto che sono appunto
> processi multipli). Quindi... cosa se ne fa un processo di un puntatore a
> uno spazio di indirizzamento a cui non ha accesso? Diciamo nulla? Ah... ma
> c'e' la memoria condivisa... ecco, ora riflettiamo anche su questa cosa.
> Quando tu scrivi
>
> foo = Bar()
>
> tu stai dicendo a Python di creare un oggetto. Bene. Non gli stai dicendo
> dove crearlo. Il che vuole dire che non e' in memoria condivisa.
> L'alternativa sarebbe immaginare che Python ficcasse *tutto quanto* in
> memoria condivisa...
>

Già. Ho passato buona parte di ieri a guardarmi proprio il funzionamento
del Manager
dei processi. Ed ho lasciato a metà quello sul funzionamento di pickle.
Il ragionamento che fai fila, però... Mettiamola così: mi piacerebbe che
esistesse
un'opzione tale che permettesse di definire una variabile in uno spazio
condiviso ed
accessibile direttamente dai singoli processi. Starebbe poi a me gestirla.
E sicuramente
in molti casi sarebbe più veloce che impacchettare e spacchettare in giro
dati che, magari,
servono solo in lettura. Poi, se voglio darmi da solo la zappa sui piedi,
sono affari miei, in
pura logica Python :-)
Questo al di là della gestione bufferizzata dei dati elaborati da pickle e
dalle sue piccole
(tutto sommato) limitazioni.


> il che vorrebbe anche dire che ogni singolo pezzo di dato di Python
> dovrebbe avere qualche lock che lo protegge... altro che GIL: avremmo gia'
> threading granulare [ah, certo, potremmo anche immaginare che schiaffa
> tutto in memoria condivisa e c'e' un GIL su questo... ma allora fare
> multithreading o multiprocessing in Python dovrebbe essere uguale, cosa che
> no ne'].
>

No. Non occorrerebbe per tutto. Ovvio.

>
> Segue che ... no, non possono essere semplici puntatori. "Come" viene
> fatto non puo' essere derivato da principi primi. E si, effettivamente e'
> Pickle.
>
> Per inciso... presente il Manager di multiprocessing (e tutta la parte di
> "memoria condivisa" di multiprocessing)?
> Bene... di condiviso non c'e' nulla. Funziona con scambio di messaggi
> (cioe' piglia gli oggetti, li serializza e li spara in giro). Insomma, e'
> un giocattolino che e' comodo da usare e da ragionarsi come la peggiore
> delle memorie condivise ed e' veloce come il piu' lento dei message
> passing. Un win win... per i linguaggi concorrenti...
>

Già e vediamo se ho capito, allora, e uso come esempio proprio il
programmino nel sito che aggiorna il dizionario:

Lancio da processo padre il processo figlio, al quale vengono passati,
pickled via Manager, i dati
dei parametri, poi quando il figlio arriva al punto dell'aggiornamento del
dizionario il figlio
chiama il Manager che pickla i dati di nuovo, li torno al padre (sotto GIL
e quindi in lista d'attesa
se vi sono altri processi che vogliono fare la stessa cosa) che aggiorna il
dizionario e torna il controllo, sempre via Manager al figlio. Corretto?

Se è così ora affronterei un multiprocesso con le idee molto più chiare sul
cosa, quando, quanto
passare al processo stesso e sull'architettura che darei al soft.

Quindi grazie a tutti quelli che hanno scritto al riguardo: ho avuto le
risposte che cercavo.

:-)

Alex
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2016-05-20 18:48 GMT+01:00 alessandro medici :

> https://www.chrisstucchio.com/blog/2013/why_not_python.html
>
> Forse meglio gli interventi che l'articolo.
>

+1

Il tizio ha ragione su alcuni punti, ma le argomentazioni che porta sono
spesso del tipo ho un martello, quindi e' tutto un chiodo.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2016-05-20 13:59 GMT+01:00 alessandro medici :

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

Non e' questione di ignoranza, basta rifletterci. Allora...
multi-*processing*.
Diciamo che e' sano assumere che siano piu' processi, ok? Quindi piu'
processi hanno spazi di indirizzamento separati (visto che sono appunto
processi multipli). Quindi... cosa se ne fa un processo di un puntatore a
uno spazio di indirizzamento a cui non ha accesso? Diciamo nulla? Ah... ma
c'e' la memoria condivisa... ecco, ora riflettiamo anche su questa cosa.
Quando tu scrivi

foo = Bar()

tu stai dicendo a Python di creare un oggetto. Bene. Non gli stai dicendo
dove crearlo. Il che vuole dire che non e' in memoria condivisa.
L'alternativa sarebbe immaginare che Python ficcasse *tutto quanto* in
memoria condivisa... il che vorrebbe anche dire che ogni singolo pezzo di
dato di Python dovrebbe avere qualche lock che lo protegge... altro che
GIL: avremmo gia' threading granulare [ah, certo, potremmo anche immaginare
che schiaffa tutto in memoria condivisa e c'e' un GIL su questo... ma
allora fare multithreading o multiprocessing in Python dovrebbe essere
uguale, cosa che no ne'].

Segue che ... no, non possono essere semplici puntatori. "Come" viene fatto
non puo' essere derivato da principi primi. E si, effettivamente e' Pickle.

Per inciso... presente il Manager di multiprocessing (e tutta la parte di
"memoria condivisa" di multiprocessing)?
Bene... di condiviso non c'e' nulla. Funziona con scambio di messaggi
(cioe' piglia gli oggetti, li serializza e li spara in giro). Insomma, e'
un giocattolino che e' comodo da usare e da ragionarsi come la peggiore
delle memorie condivise ed e' veloce come il piu' lento dei message
passing. Un win win... per i linguaggi concorrenti...




-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 20 maggio 2016 16:42, Pietro Battiston  ha
scritto:

> Il giorno ven, 20/05/2016 alle 16.26 +0200, alessandro medici ha
> scritto:
> ...
> > Qualche aiuto/commento? Per caso usi pickle per passare copie di
> > dati?
>
> Sorry, mi ero dimenticato di rispondere a questo.
>
> Non è purtroppo una mia scelta quella di usare pickle, ma parte del
> funzionamento di multiprocessing!
> Vedi ad esempio
> http://stackoverflow.com/questions/1816958/cant-pickle-type-instancemet
> hod-when-using-pythons-multiprocessing-pool-ma
> ... (non trovo al momento un riferimento chiaro nella documentazione).
>
...

qualcosina di utile qui, sul perché ed il percome:

https://www.chrisstucchio.com/blog/2013/why_not_python.html

Forse meglio gli interventi che l'articolo.

>
> Pietro
>

alex
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 20 maggio 2016 16:42, Pietro Battiston  ha
scritto:

> Il giorno ven, 20/05/2016 alle 16.26 +0200, alessandro medici ha
> scritto:
> > Il giorno 20 maggio 2016 16:05, Pietro Battiston  > it> ha scritto:
> >
> > >  > >  - "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.
> > Qualche aiuto/commento? Per caso usi pickle per passare copie di
> > dati?
>
> Sorry, mi ero dimenticato di rispondere a questo.
>
> Non è purtroppo una mia scelta quella di usare pickle, ma parte del
> funzionamento di multiprocessing!
> Vedi ad esempio
> http://stackoverflow.com/questions/1816958/cant-pickle-type-instancemet
> hod-when-using-pythons-multiprocessing-pool-ma
> ... (non trovo al momento un riferimento chiaro nella documentazione).


Visto. Ed ho visto anche gli escamotages.

E', al solito, una questione di disegno: se hai bisogno di codice che agisca
veloce: poco da fare. Ma se hai bisogno di codice che re-agisca veloce
(in altre parole puoi lavorare prima sulle precondizioni ed il codice deve
solo esser reattivo ad un caso quasi-previsto) una factory del metodo che
ti serve potrebbe essere una buona soluzione. Capita. In tal caso pickle
potrebbe implementare solo il puntatore alla classe esterna.
(ma da andar a vedere se è vero :-)

Ve ne è un ottimo esempio nell'implementazione di asyncio in 3.4, non ho
avuto occasione di guardare se han cambiato qualcosa in 3.5.

Alex
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Pietro Battiston]

Il giorno ven, 20/05/2016 alle 16.26 +0200, alessandro medici ha
scritto:
> Il giorno 20 maggio 2016 16:05, Pietro Battiston  it> ha scritto:
> 
> >  > >  - "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. 
> Qualche aiuto/commento? Per caso usi pickle per passare copie di
> dati? 

Sorry, mi ero dimenticato di rispondere a questo.

Non è purtroppo una mia scelta quella di usare pickle, ma parte del
funzionamento di multiprocessing!
Vedi ad esempio
http://stackoverflow.com/questions/1816958/cant-pickle-type-instancemet
hod-when-using-pythons-multiprocessing-pool-ma
... (non trovo al momento un riferimento chiaro nella documentazione).

Pietro


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 20 maggio 2016 16:05, Pietro Battiston  ha
scritto:

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

Qualche aiuto/commento? Per caso usi pickle per passare copie di dati?

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

Credo sia dovuto all'uso che fanno di ast. Questo w.e. speravo di avere
il tempo di dare un'occhiata ravvicinata al loro codice, ma è stata una
speranza
invana: mia morosa ha altri problemi :-(

Amen: altra cosa al domani.


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

Raro abbia necessità di calcoli complessi. Molto più spesso è solo gestione
di dati non omogenei. E, praticamente sempre non ho alcuna necessità di
scrivere codice che funzioni veloce, quanto di scrivere veloce del codice
che funzioni.

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

Quella che ti serve al momento!  :-)


> Pietro
>

Alex

ps: sistu Veneto? Io di Padova: www.fsugpadova.org
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

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

[alessandro medici]

Il giorno 20 maggio 2016 15:02, Marco Beri  ha scritto:

> 2016-05-20 14:59 GMT+02:00 alessandro medici 
> :
>>
>> Toh: un fiorire di suggerimenti :-)
>>
>
> Vero. Amo questa lista.
>
> Ciao.
> Marco.
>

Anch'io ho questa passione fetish. :-)

Per tornare sul tema:
Mi piace anche l'uso che hanno fatto di ast.
Ma perché mai hanno purgato il codice di tutti i commenti?
Mi sa che mi giocherò di più di un w.e. :-(

Alex
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

2016-05-20 14:59 GMT+02:00 alessandro medici :
>
> Toh: un fiorire di suggerimenti :-)
>

Vero. Amo questa lista.

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[alessandro medici]

Il giorno 20 maggio 2016 14:12, Pietro Battiston  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 :
> > > 2016-05-20 11:39 GMT+02:00 Strap :
> > > > 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.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Pietro Battiston]

Il giorno ven, 20/05/2016 alle 14.12 +0200, Pietro Battiston ha
scritto:
> https://www.peterbe.com/plog/time-to-do-concurrent-cpu-bound-work
> [...]
> - "multiprocessing" implica (a meno di eccezioni notevoli) "pickle di
> tutto"
> 

Ehm... OK, questo ovviamente non c'entra nulla con nessuno dei suoi
esempi (è solo il problema con cui mi scontro tipicamente io).

Pietro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Pietro Battiston]

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

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

[alessandro medici]

Assai divertente.

Ma noto che nell'ultimo esempio in https://www.peterbe.com/plog/deco
inserisce
una nuova voce (sicuramente univoca) in un dizionario creato esternamente
(io non
mi ero mai azzardato a farlo in un thread, solo a modificare il valore di
una chiave
già esistente).

Ricordo al riguardo che mi è stato obbiettato che la cosa funzionava solo
per una
specifica implementazione di Python. Non sono abbastanza ferrato per
giudicare
al riguardo. Qualcuno che ne sa qualcosa potrebbe dire la sua: Trovo questo
deco
estremamente interessante per le possibilità che offre di scappare a GIL in
alcuni casi.

Grazie in generale e tia in particolare se qualcuno risponde :-)
​
A
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco De Paoli]

Il giorno 20 maggio 2016 11:56, Marco Beri  ha scritto:

> 2016-05-20 11:46 GMT+02:00 Marco Beri :
>
>> 2016-05-20 11:39 GMT+02:00 Strap :
>>
>>> 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!
>
> Grassie!
>

+1

Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

2016-05-20 11:46 GMT+02:00 Marco Beri :

> 2016-05-20 11:39 GMT+02:00 Strap :
>
>> 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!

Grassie!

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

2016-05-20 11:39 GMT+02:00 Strap :

> 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 :-)

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python