[Python] threads
Ciao a tutti, premetto che non ho alcuna esperienza con i threads. Ciò nonostante, vorrei iniziare a capire come poterli utilizzare per sfruttare le architetture multicore delle moderne cpu e, quindi, migliorare le prestazione di uno script su cui sto lavorando. In particolare, lo script in questione effettua un parsing di un input file e subito dopo genera una serie di file di dimensioni più piccole. Di seguito, un loop è utilizzato per effettuare alcune operazioni su tutti i file creati. Tali operazioni sono le medesime per ogni file. Mi chiedevo se, utilizzando i threads, fossi in grado di ridurre i tempi di esecuzione del loop, magari indirizzando parte dei file generati a threads indipendenti. Nel caso affermativo, come potrei procedere? Grazie, Ernesto ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] R: NetBeans IDE con Python e Autocomposizione
Pasini Paolo ha scritto: > Ciao , approfitto ancora della tua competenza in NetBeans + Python. > > Sai se esiste un modo di visualizzare nell'editor NetBeans le linee verticali > di indentazione > , cioè per le parti di codice che sono allo stesso livello di indentazione? > ( come ad esempio nella Jpg in allegato , fatto con un altro python editor) > Sinceramente non ho mai avuto la necessità di una funzione simile, mi basta fare un check del sorgente. In ogni caso sono fuori città ora, quando torno a casa ti farò sapere per questa cosa e per l'altro problema. Ciao. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] R: threads
Ciao a tutti , Anche io premetto che non ho alcuna esperienza con i threads , ma Propongo , perché ritengo che sarebbe in generale molto utile per tutti , di sviluppare questa richiesta in modo da creare un oggetto generalizzato. Intendo dire che vedrei bene un Oggetto-Loop , un oggetto generico che 1 . Usa una lista di operazioni(1) generiche ( potrebbe essere una lita di metodi di un oggetto o nomi di funzioni di un modulo) 2 . Usa una lista di "elementi"(2) su cui effettuare tali operazioni ( in questo caso i files ) Quindi l' Oggetto - Loop generalizzato dovrebbe. Loop is - A partire dalla lista 2. Di elementi , per ogni elemento: - Attiva un nuovo task con associate le operazioni da fare e lancialo su elemento i-esimo - next element In questo modo sarà riusabile per set di operazioni generiche e per liste di elementi da elaborare generici ( ovviamente a patto che le operazioni generiche(1) nella lista fornita siano state sviluppate per "manipolare" tipi del tipo "elementi"(2) ) Paolo > -Messaggio originale- > Da: python-boun...@lists.python.it [mailto:python-boun...@lists.python.it] Per > conto di Ernesto > Inviato: martedì 1 dicembre 2009 11.02 > A: Discussioni generali sul linguaggio Python > Oggetto: [Python] threads > > Ciao a tutti, > > premetto che non ho alcuna esperienza con i threads. Ciò nonostante, > vorrei iniziare a capire come poterli utilizzare per sfruttare le > architetture multicore delle moderne cpu e, quindi, migliorare le > prestazione di uno script su cui sto lavorando. In particolare, lo > script in questione effettua un parsing di un input file e subito dopo > genera una serie di file di dimensioni più piccole. Di seguito, un > loop è utilizzato per effettuare alcune operazioni su tutti i file > creati. Tali operazioni sono le medesime per ogni file. Mi chiedevo > se, utilizzando i threads, fossi in grado di ridurre i tempi di > esecuzione del loop, magari indirizzando parte dei file generati a > threads indipendenti. Nel caso affermativo, come potrei procedere? > > Grazie, > > Ernesto > > > ___ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
Ernesto spiffera, alle Tuesday 01 December 2009 circa: > Ciao a tutti, > > premetto che non ho alcuna esperienza con i threads. Ciò nonostante, > vorrei iniziare a capire come poterli utilizzare per sfruttare le > architetture multicore delle moderne cpu e, quindi, migliorare le > prestazione di uno script su cui sto lavorando. [...] > Nel caso affermativo, come potrei procedere? *non* procedere. I thread (in particolare sui multicore) in python evitali. Piuttosto cerca di fare una cosa multiprocesso, se ne hai veramente bisogno. (altrimenti potresti provare stackless-python, ma devi usare una sua sintassi particolare) ciao -- -gaspa- --- https://launchpad.net/~gaspa - - HomePage: http://gaspa.yattaweb.it -- -Il lunedi'dell'arrampicatore: www.lunedi.org - ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] R: threads
> *non* procedere. I thread (in particolare sui multicore ) in python evitali. Come Mai ? Hanno problemi(Bugs?) o non sono progettati per tale uso ? > Piuttosto cerca di fare una cosa multiprocesso, se ne hai veramente Cioè ? Grazie > -Messaggio originale- > Da: python-boun...@lists.python.it [mailto:python-boun...@lists.python.it] Per > conto di Andrea Gasparini > Inviato: martedì 1 dicembre 2009 11.22 > A: python@lists.python.it > Oggetto: Re: [Python] threads > > Ernesto spiffera, alle Tuesday 01 December 2009 circa: > > Ciao a tutti, > > > > premetto che non ho alcuna esperienza con i threads. Ciò nonostante, > > vorrei iniziare a capire come poterli utilizzare per sfruttare le > > architetture multicore delle moderne cpu e, quindi, migliorare le > > prestazione di uno script su cui sto lavorando. > [...] > > Nel caso affermativo, come potrei procedere? > > *non* procedere. I thread (in particolare sui multicore) in python evitali. > Piuttosto cerca di fare una cosa multiprocesso, se ne hai veramente > bisogno. > (altrimenti potresti provare stackless-python, ma devi usare una sua > sintassi particolare) > > ciao > -- > -gaspa- > --- > https://launchpad.net/~gaspa - > - HomePage: http://gaspa.yattaweb.it -- > -Il lunedi'dell'arrampicatore: www.lunedi.org - > ___ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ernesto ha scritto: > Ciao a tutti, > > premetto che non ho alcuna esperienza con i threads. Ciò nonostante, > vorrei iniziare a capire come poterli utilizzare per sfruttare le > architetture multicore delle moderne cpu e, quindi, migliorare le > prestazione di uno script su cui sto lavorando. Purtroppo in Python l'utilizzo dei thread è pesantemente limitato dall'uso di un lock globale (GIL); solo un thread alla volta può eseguire codice Python. > In particolare, lo > script in questione effettua un parsing di un input file e subito dopo > genera una serie di file di dimensioni più piccole. Di seguito, un > loop è utilizzato per effettuare alcune operazioni su tutti i file > creati. Tali operazioni sono le medesime per ogni file. Mi chiedevo > se, utilizzando i threads, fossi in grado di ridurre i tempi di > esecuzione del loop, magari indirizzando parte dei file generati a > threads indipendenti. Temo che non avrai nessun incremento di prestazioni usando i thread. L'unico vantaggio nell'usare i thread si ha quando si chiamano funzioni scritte in C che rilasciano il GIL (come ad esempio la read su un socket). Ti consiglio quindi di usare i processi ed il modulo multiprocessing: http://docs.python.org/library/multiprocessing.html Per le versioni di Python inferiori alla 2.6 lo trovi come package esterno. Il package multiprocessing ti offre una implementazione di un Pool: http://docs.python.org/library/multiprocessing.html#module-multiprocessing.pool che dovrebbe essere tutto quello di cui hai bisogno; in particolare il metodo map. > [...] Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksU8VQACgkQscQJ24LbaUQ0aACcCeIclPNjc3DWdSynUtW+GiAz SlsAoJlWD0m3jVvPyx9OwYUXCCGkRpGd =DLqi -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] R: threads
Pasini Paolo spiffera, alle Tuesday 01 December 2009 circa: > > *non* procedere. I thread (in particolare sui multicore ) in python > > evitali. > Come Mai ? Hanno problemi(Bugs?) o non sono progettati per tale uso ? difficile da dirsi, di fatto ti ha gia' risposto Manlio, ma giusto per completezza, se hai voglia di di capirci un po' di piu', leggi questo: www.dabeaz.com/python/GIL.pd bye! -- -gaspa- --- https://launchpad.net/~gaspa - - HomePage: http://gaspa.yattaweb.it -- -Il lunedi'dell'arrampicatore: www.lunedi.org - ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] R: threads
Pasini Paolo ha scritto: > Ciao a tutti , > > Anche io premetto che non ho alcuna esperienza con i threads , ma > Propongo , perché ritengo che sarebbe in generale molto utile per tutti , > di sviluppare questa richiesta in modo da creare un oggetto generalizzato. > > Intendo dire che vedrei bene un Oggetto-Loop , un oggetto generico che > 1 . Usa una lista di operazioni(1) generiche ( potrebbe essere una lita di > metodi di un oggetto o nomi di funzioni di un modulo) > 2 . Usa una lista di "elementi"(2) su cui effettuare tali operazioni ( in > questo caso i files ) > > Quindi l' Oggetto - Loop generalizzato dovrebbe. > > Loop is > - A partire dalla lista 2. Di elementi , per ogni elemento: > - Attiva un nuovo task con associate le operazioni da fare e > lancialo su elemento i-esimo > - next element > > In questo modo sarà riusabile per set di operazioni generiche e per liste di > elementi da elaborare generici > ( ovviamente a patto che le operazioni generiche(1) nella lista fornita siano > state sviluppate per "manipolare" tipi del tipo "elementi"(2) ) > Attenzione che Python non è Java! Python ha i generatori[1] per quello che tu descrivi come Oggetto-Loop, e multiprocessing.Pool ha un metodo imap (e imap_unordered, che non so se sia più efficiente del metodo imap) che funziona su iteratori. [1] http://www.python.org/dev/peps/pep-0255 Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
> premetto che non ho alcuna esperienza con i threads. Ciò nonostante, > vorrei iniziare a capire come poterli utilizzare per sfruttare le > architetture multicore delle moderne cpu e, quindi, migliorare le > prestazione di uno script su cui sto lavorando. In particolare, lo > script in questione effettua un parsing di un input file e subito dopo > genera una serie di file di dimensioni più piccole. Di seguito, un > loop è utilizzato per effettuare alcune operazioni su tutti i file > creati. Tali operazioni sono le medesime per ogni file. Mi chiedevo > se, utilizzando i threads, fossi in grado di ridurre i tempi di > esecuzione del loop, magari indirizzando parte dei file generati a > threads indipendenti. Nel caso affermativo, come potrei procedere? > Ciao, come ti hanno risposto, a causa del GIL non avrai nessun miglioramento delle prestazioni, soprattutto per operazioni di IO di questo genere. Se devi effettuare pesantemente questo genere di operazioni ti posso indicare invece un framework che ti può aiutare, come ha fatto con me! Twisted (http://twistedmatrix.com) Si tratta di programmazione ad eventi, e come mi par di capire, puoi strutturare la cosa come un controller ed n processi che fanno il lavoro. Con twisted puoi usare il perspective broker a cui si possono sottoscrivere più client e lo puoi anche distribuire sulla rete. Il perspective broker "server" è quello che ha la logica e distribuisce i compiti ai figli disponibili in ascolto, mentre il "client" è quello "stupido" ed esegue un solo compito per volta e ripetitivo. HTH Ciao Fabrizio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
Fabrizio Mancini ha scritto: > [...] > > come ti hanno risposto, a causa del GIL non avrai nessun miglioramento > delle prestazioni, soprattutto per operazioni di IO di questo genere. > Se devi effettuare pesantemente questo genere di operazioni ti posso > indicare invece un framework che ti può aiutare, come ha fatto con me! > Twisted (http://twistedmatrix.com) > Si tratta di programmazione ad eventi, e come mi par di capire, puoi > strutturare la cosa come un controller ed n processi che fanno il > lavoro. > Con twisted puoi usare il perspective broker a cui si possono > sottoscrivere più client e lo puoi anche distribuire sulla rete. Per task semplici, AMP dovrebbe essere meglio; ed è anche disponibile https://launchpad.net/ampoule. Comunque ritengo che il modulo multiprocessing sia più semplice per questo tipo di compito. > [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
Andrea Gasparini spiffera, alle Tuesday 01 December 2009 circa: > *non* procedere. I thread (in particolare sui multicore) in python > evitali. Piuttosto cerca di fare una cosa multiprocesso, se ne hai > veramente bisogno. Chiarisco: evitali se li devi usare per migliorare le performance, perchè di solito, per problemi interni di python, le peggiorano. Se hai bisogno di thread per chiarezza, per strutturare meglio il tuo codice, ma non sono "speed-critical" allora ben vengano. bye -- -gaspa- --- https://launchpad.net/~gaspa - - HomePage: http://gaspa.yattaweb.it -- -Il lunedi'dell'arrampicatore: www.lunedi.org - ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
> premetto che non ho alcuna esperienza con i threads. male, se non sai cosa è una regione critica o un semaforo privato ti conviene dare una lettura veloce... :-) > vorrei iniziare a capire come poterli utilizzare per sfruttare le > architetture multicore delle moderne cpu e, quindi, migliorare le > prestazione di uno script su cui sto lavorando. http://masci.wordpress.com/2009/03/20/i-thread-python-ed-il-global-interpreter-lock/ questo link spiega tutto... Ciao ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
>> *non* procedere. I thread (in particolare sui multicore) in python >> evitali. Piuttosto cerca di fare una cosa multiprocesso, se ne hai >> veramente bisogno. > Da quanto ho capito, quindi, non avrei alcun beneficio in termini di performance. In pratica mi ero accorto della cosa in quanto avevo scritto una piccola applicazione dove lanciavo una funzione stupida usando un numero diverso di thread. I tempi di esecuzione erano i medesimi sia per per numero di thread=1 che per numero di thread=2. Grazie per i chiarimenti. A questo punto proverò con un multiprocesso. Ernesto ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
>> premetto che non ho alcuna esperienza con i threads. > male, se non sai cosa è una regione critica o un semaforo privato ti > conviene dare una lettura veloce... :-) Sicuramente è un mio limite e lo riconosco ma "non avere esperienza" non significa non sapere cosa sia una determinata cosa, ma semplicemente che che non ho mai avuto modo di lavorarci. >> vorrei iniziare a capire come poterli utilizzare per sfruttare le >> architetture multicore delle moderne cpu e, quindi, migliorare le >> prestazione di uno script su cui sto lavorando. > http://masci.wordpress.com/2009/03/20/i-thread-python-ed-il-global-interpreter-lock/ > > questo link spiega tutto... > Grazie comunque per il link da cui cercherò di fare tesoro dei contenuti. Grazie anche a tutti gli altri suggerimenti, Ernesto ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] R: threads
2009/12/1 Andrea Gasparini > Pasini Paolo spiffera, alle Tuesday 01 December 2009 circa: > > > *non* procedere. I thread (in particolare sui multicore ) in python > > > evitali. > > Come Mai ? Hanno problemi(Bugs?) o non sono progettati per tale uso ? > > difficile da dirsi, di fatto ti ha gia' risposto Manlio, ma giusto per > completezza, se hai voglia di di capirci un po' di piu', leggi questo: > www.dabeaz.com/python/GIL.pd > Il link corretto é www.dabeaz.com/python/GIL.pdf Pensavo che il problema del GIL fosse stato corretto in python 2.6 o 3.0. Forse l'affermazione giusta é che in python 2.6 é stato incluso il modulo multiprocessing, che fornisce una soluzione per aggirare il problema del GIL: - http://www.python.org/dev/peps/pep-0371/ -- Giovanni Dall'Olio, phd student Department of Biologia Evolutiva at CEXS-UPF (Barcelona, Spain) My blog on bioinformatics: http://bioinfoblog.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
On Dec 1, 2009, at 11:35 AM, Andrea Gasparini wrote: > Se hai bisogno di thread per chiarezza, per strutturare meglio il tuo > codice, ma non sono "speed-critical" allora ben vengano. Se hai bisogno dei thread per "chiarezza" hai bisogno di ridefinirti il concetto di chiarezza. :) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] R: threads
On Dec 1, 2009, at 12:50 PM, Giovanni Marco Dall'Olio wrote: > Pensavo che il problema del GIL fosse stato corretto in python 2.6 o 3.0. Non c'e' nessun "problema del GIL". C'e' il GIL. Punto. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
Il giorno mar, 01/12/2009 alle 11.21 +0100, Andrea Gasparini ha scritto: > Ernesto spiffera, alle Tuesday 01 December 2009 circa: > > Ciao a tutti, > > > > premetto che non ho alcuna esperienza con i threads. Ciò nonostante, > > vorrei iniziare a capire come poterli utilizzare per sfruttare le > > architetture multicore delle moderne cpu e, quindi, migliorare le > > prestazione di uno script su cui sto lavorando. > [...] > > Nel caso affermativo, come potrei procedere? > > *non* procedere. I thread (in particolare sui multicore) in python evitali. > Piuttosto cerca di fare una cosa multiprocesso, se ne hai veramente > bisogno. > (altrimenti potresti provare stackless-python, ma devi usare una sua > sintassi particolare) Potresti precisare? Mi sembrava di avere capito che 1) stackless-python _non_ ha una sua sintassi particolare 2) in ogni caso, non risolve il problema dell'esistenza GIL* ... non avevo capito nulla? ciaociao Pietro *così è accettabile, Enrico? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
On Dec 1, 2009, at 5:14 PM, Pietro Battiston wrote: > *così è accettabile, Enrico? Guarda, non e' per fare polemica. Non ritengo l'esistenza del GIL un problema. Non averlo (e' stato provato) causerebbe problemi nel senso che il codice si comporterebbe in modo poco intuitivo su CPython. Se per qualche bislacco motivo dovessi scrivere codice pesantemente threaded in Python, valuterei di usare Jython con piattaforma, pensa. Dopo di che, avendo twisted... ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
Andrea Gasparini ha scritto: > Ernesto spiffera, alle Tuesday 01 December 2009 circa: >> Ciao a tutti, >> >> premetto che non ho alcuna esperienza con i threads. Ciò nonostante, >> vorrei iniziare a capire come poterli utilizzare per sfruttare le >> architetture multicore delle moderne cpu e, quindi, migliorare le >> prestazione di uno script su cui sto lavorando. > [...] >> Nel caso affermativo, come potrei procedere? > > *non* procedere. I thread (in particolare sui multicore) in python evitali. > Piuttosto cerca di fare una cosa multiprocesso, se ne hai veramente > bisogno. > (altrimenti potresti provare stackless-python, ma devi usare una sua > sintassi particolare) > Stackless Python, a quanto mi risulta, mappa i suoi micro thread su un solo thread del sistema operativo, quindi non risolve il problema originale, che è probabilmente CPU bound. Gli unici linguaggi il cui runtime supporta un mapping N:M dei microthread su thread del sistema operativo sono (almeno quelli che conosco): - Erlang - Haskell (ma solo GHC, credo) a cui si aggiungono altri linguaggi, di cui però non ho esperienza. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
Il giorno mar, 01/12/2009 alle 17.25 +0100, Enrico Franchi ha scritto: > On Dec 1, 2009, at 5:14 PM, Pietro Battiston wrote: > > > *così è accettabile, Enrico? > > Guarda, non e' per fare polemica. Scusami, volevo solo suggerire che il problema nelle parole "il problema del GIL" sembrava più una sottigliezza di italiano che di concetto... > Non ritengo l'esistenza del GIL > un problema. Non averlo (e' stato provato) causerebbe problemi > nel senso che il codice si comporterebbe in modo poco intuitivo > su CPython. > > Se per qualche bislacco motivo dovessi scrivere codice pesantemente > threaded in Python, valuterei di usare Jython con piattaforma, pensa. > Uhm... non riesco a seguirti. Poniamo che consideriamo "problema" il fatto di non poter sfruttare efficacemente due processori (senza creare due diversi processi). Allora se Jython, come mi sembra di capire, lo fa, ed esegue sempre codice Python, in cosa è poco intuitivo? Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
On Dec 1, 2009, at 6:26 PM, Pietro Battiston wrote: > Scusami, volevo solo suggerire che il problema nelle parole "il problema > del GIL" sembrava più una sottigliezza di italiano che di concetto... Il punto è che il GIL è la soluzione ad un problema, non un problema egli stesso. Viceversa, i threads sono una soluzione ad un problema che sono *anche* un problema essi stessi. Per lo meno in ambito di programmazione con memoria condivisa, come è in ambito imperativo. Nel mondo funzionale non sono un problema, per dire. Al limite non è una buona soluzione. Ma io credo che il problema sia incoraggiare la programmazione a thread in ambiente imperativo/oo. Questo si che è un problema, per non parlare del fatto che ti lega le zampe rispetto alla distribuzione su più macchine. > Uhm... non riesco a seguirti. Poniamo che consideriamo "problema" il > fatto di non poter sfruttare efficacemente due processori (senza creare > due diversi processi). Allora se Jython, come mi sembra di capire, lo > fa, ed esegue sempre codice Python, in cosa è poco intuitivo? Perchè Jython ha come primitive quelle della JVM e tutto può funzionare come in Java (ovvero ugualmente male o bene che con Java). In particolare ti trovi pure quell'obrobrio di synchronized. Se come van Roy e Haridi ritieni questo "funzionare male" (e mi associo) allora funzioni male come la JVM. Se come Gosling lo consideri funzionare bene, allora funziona bene. Suppongo che chi volesse usare il modello di concorrenza di Java lo considererebbe funzionare bene. Il GIL impedisce che due thread siano vivi nell'interprete Python. In particolare tu assumi che un sacco di cose in Python siano atomiche. Senza GIL non lo sarebbero e di conseguenza avresti programmi *scorretti*. Jython si appoggia ad una diversa macchina virtuale e di conseguenza usa una differente implementazione. Idem IronPython. Idem dovrebbe fare Unladen Swallow nel futuro. La cosa poco intuitiva sarebbe che il codice Python *corretto* che girasse su un cPython senza GIL diventerebbe magicamente scorretto, perchè ti entrerebbero dalla finestra race conditions e altre schifezze ad un livello *sottostante* il tuo codice. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
Il giorno mar, 01/12/2009 alle 18.47 +0100, Enrico Franchi ha scritto: > On Dec 1, 2009, at 6:26 PM, Pietro Battiston wrote: > > Uhm... non riesco a seguirti. Poniamo che consideriamo "problema" il > > fatto di non poter sfruttare efficacemente due processori (senza creare > > due diversi processi). Allora se Jython, come mi sembra di capire, lo > > fa, ed esegue sempre codice Python, in cosa è poco intuitivo? > > Perchè Jython ha come primitive quelle della JVM e tutto può funzionare > come in Java (ovvero ugualmente male o bene che con Java). > In particolare ti trovi pure quell'obrobrio di synchronized. Se come > van Roy e Haridi ritieni questo "funzionare male" (e mi associo) allora > funzioni male come la JVM. Se come Gosling lo consideri funzionare bene, > allora funziona bene. Suppongo che chi volesse usare il modello di > concorrenza di Java lo considererebbe funzionare bene. > > Il GIL impedisce che due thread siano vivi nell'interprete Python. In > particolare tu assumi che un sacco di cose in Python siano atomiche. > Senza GIL non lo sarebbero e di conseguenza avresti programmi *scorretti*. > Jython si appoggia ad una diversa macchina virtuale e di conseguenza > usa una differente implementazione. Idem IronPython. Idem dovrebbe > fare Unladen Swallow nel futuro. > > La cosa poco intuitiva sarebbe che il codice Python *corretto* che girasse > su un cPython senza GIL diventerebbe magicamente scorretto, perchè > ti entrerebbero dalla finestra race conditions e altre schifezze ad un > livello *sottostante* il tuo codice. Davo per scontato che scrivere "codice per cPython" invece che semplicemente "codice Python" fosse caldamente sconsigliato... sbagliavo? Ovvero: quando gli sviluppatori di Jython dicono "Jython 2.5 implements the same language as CPython 2.5", mentono o è semplicemente ritenuto normale che non tutti i programmi in Python x.y funzionino su tutti gli interpreti di Python x.y? (ovviamente tutto ciò a prescindere dalle estensioni in C) Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
On Dec 1, 2009, at 7:14 PM, Pietro Battiston wrote: > Davo per scontato che scrivere "codice per cPython" invece che > semplicemente "codice Python" fosse caldamente sconsigliato... > sbagliavo? Forse il tuo unico errore e' quello di avere pensato che io l'abbia detto. Dove sarebbe accaduto? > Ovvero: quando gli sviluppatori di Jython dicono "Jython 2.5 implements > the same language as CPython 2.5", mentono o è semplicemente ritenuto > normale che non tutti i programmi in Python x.y funzionino su tutti gli > interpreti di Python x.y? Provo a rispiegartelo: tutti i programmi Python x.y funzionano su tutti gli interpreti Python x.y. Si. Se pero' tu togli il GIL a cPython l'affermazione di cui sopra diventa falsa. In particolare, ci sarebbero programmi *corretti* che smetterebbero di funzionare secondo la semantica attesa. In altre parole, se tu prendi l'interprete cPython (inteso come insieme compilatore+vm) e gli cavi il GIL, il risultato *non* e' un interprete Python, esattamente perche' non farebbe girare in modo corretto i programmi Python. Il GIL e' semplicemente un dettaglio implementativo di cPython che serve a garantire la semantica intesa. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
Enrico Franchi ha scritto: > [...] > > Il GIL e' semplicemente un dettaglio implementativo di cPython che serve > a garantire la semantica intesa. > Ci sono però delle considerazioni da fare. Ad esempio in CPython, "grazie" al lock, abbiamo la garanzia che le varie operazioni su strutture dati mutevoli come liste e dizionari sono atomiche. Ma questo non è mai specificato formalmente, a quanto ne so. In Jython, almeno le vecchie versioni, le varie funzioni che modificano una lista, come append, non sono atomiche; deve essere usato un lock esplicito. E dato che questo non viene documentato nel reference del linguaggio, non si capisce se: - l'atomicità in CPython è un effetto "collaterale" o dettaglio implementativo - l'implementazione di Jython è errata Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
In data martedì 01 dicembre 2009 17:14:19, Pietro Battiston ha scritto: > Potresti precisare? Mi sembrava di avere capito che > 1) stackless-python _non_ ha una sua sintassi particolare > 2) in ogni caso, non risolve il problema dell'esistenza GIL* > > ... non avevo capito nulla? o forse non ho capito nulla io. :P Sulla sintassi mi sono espresso male, ha il suo bel 'import stackless', ma da quel che avevo capito allora, non è soltanto il modulo ma tutto l'interprete a essere modificato (appena ho un attimo faccio un diff cosi' lo scopro ;) ), quindi se usi cPython non hai il modulo relativo. A questo punto mi fai venire il dubbio di non avere capito un accidente, ma di sicuro distribuiscono *tutto* l'interprete, per cui mi viene da pensare qualcosa di diverso ci sia. bye! -- -gaspa- --- - http://launchpad.net/~gaspa - -- HomePage: iogaspa.altervista.org --- -Il lunedi'dell'arrampicatore: www.lunedi.org - ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
Pietro Battiston ha scritto: > [...] > > Davo per scontato che scrivere "codice per cPython" invece che > semplicemente "codice Python" fosse caldamente sconsigliato... > sbagliavo? > Scrivere "codice Python" non è ben definito, dato che il linguaggio Python non ha una descrizione/definizione formale completa. il linguaggio Python è definito dalla sua implementazione ufficiale, CPython. Quindi noi in realtà scriviamo codice per CPython. Ci sono dei dettagli di cui si deve tenere conto, comunque. Ad esempio, quando si parla di CPython si fa riferimento anche a moduli di estensione specifici come ctypes, che tra l'altro si trova nella libreria standard. Ma ctypes non è detto sia disponibiile su tutte le implementazioni di Python. > Ovvero: quando gli sviluppatori di Jython dicono "Jython 2.5 implements > the same language as CPython 2.5", mentono o è semplicemente ritenuto > normale che non tutti i programmi in Python x.y funzionino su tutti gli > interpreti di Python x.y? > Non mentono; Jython cerca di implementare lo stesso linguaggio Python come definito da CPython. Se ci sono delle differenze, possiamo assumere che sia un bug; vedi ad esempio http://twistedmatrix.com/trac/browser/trunk/twisted/internet/base.py#L900 > [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] threads
In data martedì 01 dicembre 2009 20:34:41, Andrea Gasparini ha scritto: > A questo punto mi fai venire il dubbio di non avere capito un accidente, ma > di sicuro distribuiscono *tutto* l'interprete, per cui mi viene da pensare > qualcosa di diverso ci sia. confermo, ci sono differenze anche negli header, quindi mi sembra anche probabile che i moduli .so non funzionino da uno all'altro. ( non ho trovato nessuna conferma su performance, magari qualcuno è piu' informato :P ) bye. -- -gaspa- --- - http://launchpad.net/~gaspa - -- HomePage: iogaspa.altervista.org --- -Il lunedi'dell'arrampicatore: www.lunedi.org - ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
