Cela semble indiquer que (le moteur) Python est capable de récupérer un
objet abandonné, d'après son contenu, pour le ré-associer à un nom.
Hasard ? ou conception (très) avancée ?
b et a[2] ont le même id(). Aaaarrrrggg de aaaarrrggg ! Comment Python fait-il ?
@+ -- Michel Claveau
Bruno Desthuilliers
Méta-MCI (MVP) a écrit :
Et, je m'enfonce...
a=[0,11,22,33,44] print id(a[2])
b" print id(b) print id(a[2])
23034300 23034300 23034300
b et a[2] ont le même id(). Aaaarrrrggg de aaaarrrggg ! Comment Python fait-il ?
Optimisation... Les "petits" entiers (pour une définition qui varie selon les versions - sous 2.5.1, c'est 256), de même qu'un certain nombre de chaines (principalement celle qui font des identifiants Python valides), sont conservés en cache par CPython.
Essaie avec a =[200, 256, 257,], b%6 et c%7...
Méta-MCI (MVP) a écrit :
Et, je m'enfonce...
a=[0,11,22,33,44]
print id(a[2])
b"
print id(b)
print id(a[2])
23034300
23034300
23034300
b et a[2] ont le même id(). Aaaarrrrggg de aaaarrrggg ! Comment Python
fait-il ?
Optimisation... Les "petits" entiers (pour une définition qui varie
selon les versions - sous 2.5.1, c'est 256), de même qu'un certain
nombre de chaines (principalement celle qui font des identifiants Python
valides), sont conservés en cache par CPython.
b et a[2] ont le même id(). Aaaarrrrggg de aaaarrrggg ! Comment Python fait-il ?
Optimisation... Les "petits" entiers (pour une définition qui varie selon les versions - sous 2.5.1, c'est 256), de même qu'un certain nombre de chaines (principalement celle qui font des identifiants Python valides), sont conservés en cache par CPython.
Essaie avec a =[200, 256, 257,], b%6 et c%7...
Méta-MCI \(MVP\)
Bonsoir !
Les "petits" entiers ... sont conservés en cache par CPython.
Au moins je ne terminerai pas 2008 sur une ignorance. Merci pour l'info.
Optimisation...
Que ce soit pour optimiser la place mémoire, ou la vitesse, j'ai comme un doute sur les gains, versus les lourdeurs (de tests de valeurs) que cela entraine, pour toutes les affectations. M'enfin, comme je ne suis pas, à l'inverse de toi, capable de lire le code-source, je vais m'arrêter là.
Bonne Année 2009 -- Michel Claveau
Bonsoir !
Les "petits" entiers ... sont conservés en cache par CPython.
Au moins je ne terminerai pas 2008 sur une ignorance.
Merci pour l'info.
Optimisation...
Que ce soit pour optimiser la place mémoire, ou la vitesse, j'ai comme
un doute sur les gains, versus les lourdeurs (de tests de valeurs) que
cela entraine, pour toutes les affectations.
M'enfin, comme je ne suis pas, à l'inverse de toi, capable de lire le
code-source, je vais m'arrêter là.
Les "petits" entiers ... sont conservés en cache par CPython.
Au moins je ne terminerai pas 2008 sur une ignorance. Merci pour l'info.
Optimisation...
Que ce soit pour optimiser la place mémoire, ou la vitesse, j'ai comme un doute sur les gains, versus les lourdeurs (de tests de valeurs) que cela entraine, pour toutes les affectations. M'enfin, comme je ne suis pas, à l'inverse de toi, capable de lire le code-source, je vais m'arrêter là.
Bonne Année 2009 -- Michel Claveau
OdarR
On 31 déc, 16:41, Bruno Desthuilliers <bruno. wrote:
Optimisation... Les "petits" entiers (pour une définition qui varie selon les versions - sous 2.5.1, c'est 256), de même qu'un certain nombre de chaines (principalement celle qui font des identifiants Python valides), sont conservés en cache par CPython.
Essaie avec a =[200, 256, 257,], b%6 et c%7...
ouaip. J'ai lu ce que tu dis il y a peu de temps dans http://www.amazon.fr/Learning-Python-Mark-Lutz/dp/0596513984 au début du livre.
Déroutant :-)
Olivier
On 31 déc, 16:41, Bruno Desthuilliers <bruno.
42.desthuilli...@websiteburo.invalid> wrote:
Optimisation... Les "petits" entiers (pour une définition qui varie
selon les versions - sous 2.5.1, c'est 256), de même qu'un certain
nombre de chaines (principalement celle qui font des identifiants Python
valides), sont conservés en cache par CPython.
Essaie avec a =[200, 256, 257,], b=256 et c=257...
ouaip.
J'ai lu ce que tu dis il y a peu de temps dans
http://www.amazon.fr/Learning-Python-Mark-Lutz/dp/0596513984
au début du livre.
On 31 déc, 16:41, Bruno Desthuilliers <bruno. wrote:
Optimisation... Les "petits" entiers (pour une définition qui varie selon les versions - sous 2.5.1, c'est 256), de même qu'un certain nombre de chaines (principalement celle qui font des identifiants Python valides), sont conservés en cache par CPython.
Essaie avec a =[200, 256, 257,], b%6 et c%7...
ouaip. J'ai lu ce que tu dis il y a peu de temps dans http://www.amazon.fr/Learning-Python-Mark-Lutz/dp/0596513984 au début du livre.
Déroutant :-)
Olivier
Bruno Desthuilliers
Méta-MCI (MVP) a écrit :
Bonsoir !
Les "petits" entiers ... sont conservés en cache par CPython.
Au moins je ne terminerai pas 2008 sur une ignorance. Merci pour l'info.
Optimisation...
Que ce soit pour optimiser la place mémoire, ou la vitesse,
Surtour le second en l'occurrence - il s'agit avant tout d'éviter des instanciations (coûteuses) à répétition, quite à bouffer un peu plus de RAM (et encore : un tableau statique d'environ 300 pointeurs, c'est pas monstrueux non plus).
j'ai comme un doute sur les gains, versus les lourdeurs (de tests de valeurs) que cela entraine,
J'aurais pour ma part tendance à penser que si cette optimisation s'était avérée contre-productive[1], elle aurait été abandonnée depuis longtemps... Accessoirement, dans la mesure où Python n'a pas de types "immédiats", mais uniquement des objets, on peut aisément comprendre que pour des objets immutables très utilisés,le coût d'un lookup [2] soit marginal comparé à celui d'une instanciation.
[1] en moyenne bien sûr - pour toutes les optimisations, on trouve toujours des cas pathologiques...
[2] en l'occurrence, tout bêtement dans un tableau C (lequel est pré-rempli à l'initialisation du module), puisque la valeur immédiate (utilisée pour créer l'objet <int>) est elle-même un entier (int C), donc du type qui convient pour indexer un tableau. Le coût du lookup est donc _vraiment_ minime.
pour toutes les affectations.
Ca ne concerne pas spécifiquement les affectations, mais toute instanciation d'un <int> Python.
M'enfin, comme je ne suis pas, à l'inverse de toi, capable de lire le code-source,
Je n'avais pas eu besoin d'aller chercher dans le source pour répondre à ta question, c'est un détail d'implémentation assez connu de CPython (et une FAQ sur c.l.py).
Par contre j'y ai été pour vérifier comment était implémenté le cache. Si tu veux aller voire par toi-même, c'est au début de Objects/intobject.c. Tu constatera au passage qu'il n'est nul besoin de pouvoirs mystiques pour comprendre cette partie du code !-)
Bonne Année 2009
Pareil !-)
Méta-MCI (MVP) a écrit :
Bonsoir !
Les "petits" entiers ... sont conservés en cache par CPython.
Au moins je ne terminerai pas 2008 sur une ignorance.
Merci pour l'info.
Optimisation...
Que ce soit pour optimiser la place mémoire, ou la vitesse,
Surtour le second en l'occurrence - il s'agit avant tout d'éviter des
instanciations (coûteuses) à répétition, quite à bouffer un peu plus de
RAM (et encore : un tableau statique d'environ 300 pointeurs, c'est pas
monstrueux non plus).
j'ai comme
un doute sur les gains, versus les lourdeurs (de tests de valeurs) que
cela entraine,
J'aurais pour ma part tendance à penser que si cette optimisation
s'était avérée contre-productive[1], elle aurait été abandonnée depuis
longtemps... Accessoirement, dans la mesure où Python n'a pas de types
"immédiats", mais uniquement des objets, on peut aisément comprendre que
pour des objets immutables très utilisés,le coût d'un lookup [2] soit
marginal comparé à celui d'une instanciation.
[1] en moyenne bien sûr - pour toutes les optimisations, on trouve
toujours des cas pathologiques...
[2] en l'occurrence, tout bêtement dans un tableau C (lequel est
pré-rempli à l'initialisation du module), puisque la valeur immédiate
(utilisée pour créer l'objet <int>) est elle-même un entier (int C),
donc du type qui convient pour indexer un tableau. Le coût du lookup est
donc _vraiment_ minime.
pour toutes les affectations.
Ca ne concerne pas spécifiquement les affectations, mais toute
instanciation d'un <int> Python.
M'enfin, comme je ne suis pas, à l'inverse de toi, capable de lire le
code-source,
Je n'avais pas eu besoin d'aller chercher dans le source pour répondre à
ta question, c'est un détail d'implémentation assez connu de CPython (et
une FAQ sur c.l.py).
Par contre j'y ai été pour vérifier comment était implémenté le cache.
Si tu veux aller voire par toi-même, c'est au début de
Objects/intobject.c. Tu constatera au passage qu'il n'est nul besoin de
pouvoirs mystiques pour comprendre cette partie du code !-)
Les "petits" entiers ... sont conservés en cache par CPython.
Au moins je ne terminerai pas 2008 sur une ignorance. Merci pour l'info.
Optimisation...
Que ce soit pour optimiser la place mémoire, ou la vitesse,
Surtour le second en l'occurrence - il s'agit avant tout d'éviter des instanciations (coûteuses) à répétition, quite à bouffer un peu plus de RAM (et encore : un tableau statique d'environ 300 pointeurs, c'est pas monstrueux non plus).
j'ai comme un doute sur les gains, versus les lourdeurs (de tests de valeurs) que cela entraine,
J'aurais pour ma part tendance à penser que si cette optimisation s'était avérée contre-productive[1], elle aurait été abandonnée depuis longtemps... Accessoirement, dans la mesure où Python n'a pas de types "immédiats", mais uniquement des objets, on peut aisément comprendre que pour des objets immutables très utilisés,le coût d'un lookup [2] soit marginal comparé à celui d'une instanciation.
[1] en moyenne bien sûr - pour toutes les optimisations, on trouve toujours des cas pathologiques...
[2] en l'occurrence, tout bêtement dans un tableau C (lequel est pré-rempli à l'initialisation du module), puisque la valeur immédiate (utilisée pour créer l'objet <int>) est elle-même un entier (int C), donc du type qui convient pour indexer un tableau. Le coût du lookup est donc _vraiment_ minime.
pour toutes les affectations.
Ca ne concerne pas spécifiquement les affectations, mais toute instanciation d'un <int> Python.
M'enfin, comme je ne suis pas, à l'inverse de toi, capable de lire le code-source,
Je n'avais pas eu besoin d'aller chercher dans le source pour répondre à ta question, c'est un détail d'implémentation assez connu de CPython (et une FAQ sur c.l.py).
Par contre j'y ai été pour vérifier comment était implémenté le cache. Si tu veux aller voire par toi-même, c'est au début de Objects/intobject.c. Tu constatera au passage qu'il n'est nul besoin de pouvoirs mystiques pour comprendre cette partie du code !-)
