[Python] Decorated Concurrency - Python multiprocessing made really really easy
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 Sani Strap ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy
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
Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy
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
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
[Python] Linguaggi strani
Eccone un'altro http://www.lauradhamilton.com/tutorial-getting-started-with-mumps Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] anche questo è carino assai :-)
http://mathamy.com/python-wats-mutable-default-arguments.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
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
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
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
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
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
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] anche questo è carino assai :-)
Ne spiego il perché: Da quando ho trovato questo suggerimento non ho mai usato quanto suggerisce, ma in futuro, quando mi troverò di nuovo in un caso in cui ho migliaia di chiamate a funzione e spesso in cicli di centinaia in cui cambia solo un parametro, potrebbe essere una soluzione simpatica per alleggerire il codice e, con poca spesa, velocizzarlo un poco. 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
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
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
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
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
[Python] EuroPython 2016
Ciao pythonisti ! Spammo questo super evento di luglio. Per chi volesse esserci i biglietti sono ancora regular e lo saranno ancora fino alla fine del mese probabilmente ! Un sacco di talks interessanti e super keynotes ! Siamo riusciti a far venire qualcuno direttamente dal Ligo project e anche da Disney ! Cercate di esserci altrimenti mi tocca giocare a biliardino solo con Valerio ed Ernesto ! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Decorated Concurrency - Python multiprocessing made really really easy
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
