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 negl
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 for
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 c
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 mu
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?
>
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)
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
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
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, quind
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
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
> >
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. :)
_
>> 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
>> *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 av
> 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 l
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è
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ò ai
> 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 e
-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
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 u
20 matches
Mail list logo
