Dans un livre ("Apprendre à programmer avec Python" de Swinnen),
l'auteur explique (assez rapidement car ces questions ne sont vraiment
pas l'objet du livre) que Python serait une sorte de langage
intermédiaire entre "langage interprété"/"langage compilé". Il dit que
lorsqu'on fourni un source à Python:
1) Python commence à compiler le source en un code intermédiaire le
"bytecode", qui n'est pas un code exécutable directement, mais qui est
un code en langage machine (en binaire) et qui serait portable en plus.
2) Ensuite, c'est ce bytecode qui est interprété (par ... un
interpréteur) pour qu'il y ait exécution du programme. Comme le bytecode
est en langage machine, son interprétation est un peu plus rapide que
pour un langage interprété "classique", mais moins que pour un
exécutable binaire classique quand même.
a) Déjà, êtes vous d'accord avec tout ceci ? N'hésitez pas à me
rectifier la moindre imprécision (je trouve que c'est plus bénéfique).
b) Si tout cela est exact, alors est-il possible de récupérer le
bytecode d'un script quelconque (d'un simple hello world) ? Par exemple,
j'ai un script Python toto.py, je le "pré-compile" en toto.bytecode et
je peux lancer mon programme avec une commande du genre :
Le Tue, 01 Apr 2008 20:58:13 +0200, BertrandB a écrit :
--{ Laurent Pointal a plopé ceci: }--
- Tout dépend de ton age :) pour le "relativement moderne". Si je me souviens bien, il y avait déja quelques interpréteurs Basic qui procédaient d'une manière équivalente dans les années 80. Je pense au GFA Basic de l'Atari ST, entre autres... Et le Pascal UCSD...
Pour rester dans le ton du fil, j'ai un peu fait (p'taing, je suis si vieux que ça ?) de l'UCSD sur Apple ][, et si je me souviens bien, la phase de compilation était explicite.
http://www.pascaland.org/historiq.htm
Je vais aller lire, donc.
c'était bien un compilateur et non pas un interpréteur.
Un compilateur vers une VM qui elle même faisait du JIT si j'ai bien compris, finalement un peu comme les "novateurs" Java et C#: """ UCSD Pascal was based on a p-code machine architecture. Its contribution to these early virtual machines was to extend p-code away from its roots as a compiler intermediate language into a full execution environment. """
""" UCSD p-System achieved machine independence by defining a virtual machine, called the p-Machine (or pseudo-machine, which many users began to call the "Pascal-machine" like the OS—although UCSD documentation always used "pseudo-machine") with its own instruction set called p-code (or pseudo-code). """
Source: http://en.wikipedia.org/wiki/UCSD_Pascal
-- Laurent POINTAL -
Le Tue, 01 Apr 2008 20:58:13 +0200, BertrandB a écrit :
--{ Laurent Pointal a plopé ceci: }--
- Tout dépend de ton age :) pour le "relativement moderne". Si je
me
souviens bien, il y avait déja quelques interpréteurs Basic qui
procédaient d'une manière équivalente dans les années 80. Je
pense au GFA Basic de l'Atari ST, entre autres...
Et le Pascal UCSD...
Pour rester dans le ton du fil, j'ai un peu fait (p'taing, je suis si
vieux que ça ?) de l'UCSD sur Apple ][, et si je me souviens bien, la
phase de compilation était explicite.
http://www.pascaland.org/historiq.htm
Je vais aller lire, donc.
c'était bien un compilateur et non pas un interpréteur.
Un compilateur vers une VM qui elle même faisait du JIT si j'ai bien
compris, finalement un peu comme les "novateurs" Java et C#:
"""
UCSD Pascal was based on a p-code machine architecture. Its contribution
to these early virtual machines was to extend p-code away from its roots
as a compiler intermediate language into a full execution environment.
"""
"""
UCSD p-System achieved machine independence by defining a virtual
machine, called the p-Machine (or pseudo-machine, which many users began
to call the "Pascal-machine" like the OS—although UCSD documentation
always used "pseudo-machine") with its own instruction set called p-code
(or pseudo-code).
"""
Le Tue, 01 Apr 2008 20:58:13 +0200, BertrandB a écrit :
--{ Laurent Pointal a plopé ceci: }--
- Tout dépend de ton age :) pour le "relativement moderne". Si je me souviens bien, il y avait déja quelques interpréteurs Basic qui procédaient d'une manière équivalente dans les années 80. Je pense au GFA Basic de l'Atari ST, entre autres... Et le Pascal UCSD...
Pour rester dans le ton du fil, j'ai un peu fait (p'taing, je suis si vieux que ça ?) de l'UCSD sur Apple ][, et si je me souviens bien, la phase de compilation était explicite.
http://www.pascaland.org/historiq.htm
Je vais aller lire, donc.
c'était bien un compilateur et non pas un interpréteur.
Un compilateur vers une VM qui elle même faisait du JIT si j'ai bien compris, finalement un peu comme les "novateurs" Java et C#: """ UCSD Pascal was based on a p-code machine architecture. Its contribution to these early virtual machines was to extend p-code away from its roots as a compiler intermediate language into a full execution environment. """
""" UCSD p-System achieved machine independence by defining a virtual machine, called the p-Machine (or pseudo-machine, which many users began to call the "Pascal-machine" like the OS—although UCSD documentation always used "pseudo-machine") with its own instruction set called p-code (or pseudo-code). """
Source: http://en.wikipedia.org/wiki/UCSD_Pascal
-- Laurent POINTAL -
Thierry B.
--{ Laurent Pointal a plopé ceci: }--
Pour rester dans le ton du fil, j'ai un peu fait (p'taing, je suis si vieux que ça ?) de l'UCSD sur Apple ][, et si je me souviens bien, la phase de compilation était explicite.
http://www.pascaland.org/historiq.htm
Je vais aller lire, donc.
c'était bien un compilateur et non pas un interpréteur.
Un compilateur vers une VM qui elle même faisait du JIT si j'ai bien compris, finalement un peu comme les "novateurs" Java et C#: """ UCSD Pascal was based on a p-code machine architecture. Its contribution to these early virtual machines was to extend p-code away from its roots as a compiler intermediate language into a full execution environment. """
Et cette "machine p-code" a aussi été implémenté en hardware, si je me réfère à http://www.threedee.com/jcm/psystem/ qui parle de Western Digital. J'ai d'ailleurs le souvenir d'une publicité dans Micro-Systèmes qui proposait la "Pascaline".
Il doit bien rester des traces de ce p-code, et peut-être même des implémentations utilisable de cette VM. J'me demande si je ne vais pas essayer de jouer avec ça un de ces jours :)
xposts + foutou appropriés, je pense.
-- Alors pourquoi demander sur linuxfr.org ? Tout simplement parce que le nombre de geeks au kilobits est le plus élevé de la sphère internet.
--{ Laurent Pointal a plopé ceci: }--
Pour rester dans le ton du fil, j'ai un peu fait (p'taing, je suis si
vieux que ça ?) de l'UCSD sur Apple ][, et si je me souviens bien, la
phase de compilation était explicite.
http://www.pascaland.org/historiq.htm
Je vais aller lire, donc.
c'était bien un compilateur et non pas un interpréteur.
Un compilateur vers une VM qui elle même faisait du JIT si j'ai bien
compris, finalement un peu comme les "novateurs" Java et C#:
"""
UCSD Pascal was based on a p-code machine architecture. Its contribution
to these early virtual machines was to extend p-code away from its roots
as a compiler intermediate language into a full execution environment.
"""
Et cette "machine p-code" a aussi été implémenté en hardware,
si je me réfère à http://www.threedee.com/jcm/psystem/ qui
parle de Western Digital. J'ai d'ailleurs le souvenir d'une
publicité dans Micro-Systèmes qui proposait la "Pascaline".
Il doit bien rester des traces de ce p-code, et peut-être
même des implémentations utilisable de cette VM. J'me demande
si je ne vais pas essayer de jouer avec ça un de ces jours :)
xposts + foutou appropriés, je pense.
--
Alors pourquoi demander sur linuxfr.org ? Tout simplement parce que le nombre
de geeks au kilobits est le plus élevé de la sphère internet.
Pour rester dans le ton du fil, j'ai un peu fait (p'taing, je suis si vieux que ça ?) de l'UCSD sur Apple ][, et si je me souviens bien, la phase de compilation était explicite.
http://www.pascaland.org/historiq.htm
Je vais aller lire, donc.
c'était bien un compilateur et non pas un interpréteur.
Un compilateur vers une VM qui elle même faisait du JIT si j'ai bien compris, finalement un peu comme les "novateurs" Java et C#: """ UCSD Pascal was based on a p-code machine architecture. Its contribution to these early virtual machines was to extend p-code away from its roots as a compiler intermediate language into a full execution environment. """
Et cette "machine p-code" a aussi été implémenté en hardware, si je me réfère à http://www.threedee.com/jcm/psystem/ qui parle de Western Digital. J'ai d'ailleurs le souvenir d'une publicité dans Micro-Systèmes qui proposait la "Pascaline".
Il doit bien rester des traces de ce p-code, et peut-être même des implémentations utilisable de cette VM. J'me demande si je ne vais pas essayer de jouer avec ça un de ces jours :)
xposts + foutou appropriés, je pense.
-- Alors pourquoi demander sur linuxfr.org ? Tout simplement parce que le nombre de geeks au kilobits est le plus élevé de la sphère internet.
Francois
Pardon de remonter ce fil sur le byte-code Python et le rapport avec la rapidité d'exécution d'un script. Juste pour signaler que j'ai vu ceci dans le tutoriel de Guido van Rossum en personne (concepteur de Python).On peut donc prendre ça au sérieux.
« A program doesn't run any faster when it is read from a .pyc or .pyo file than when it is read from a .py file; the only thing that's faster about .pyc or .pyo files is the speed with which they are loaded. »
Un fichier toto.pyc sera chargé plus rapidement que son copain toto.py, mais l'exécution en elle-même du programme sera aussi rapide avec l'un comme avec l'autre.
-- François
Pardon de remonter ce fil sur le byte-code Python et le rapport avec
la rapidité d'exécution d'un script. Juste pour signaler que j'ai vu
ceci dans le tutoriel de Guido van Rossum en personne (concepteur de
Python).On peut donc prendre ça au sérieux.
« A program doesn't run any faster when it is read from a .pyc or .pyo
file than when it is read from a .py file; the only thing that's faster
about .pyc or .pyo files is the speed with which they are loaded. »
Un fichier toto.pyc sera chargé plus rapidement que son copain
toto.py, mais l'exécution en elle-même du programme sera aussi rapide
avec l'un comme avec l'autre.
Pardon de remonter ce fil sur le byte-code Python et le rapport avec la rapidité d'exécution d'un script. Juste pour signaler que j'ai vu ceci dans le tutoriel de Guido van Rossum en personne (concepteur de Python).On peut donc prendre ça au sérieux.
« A program doesn't run any faster when it is read from a .pyc or .pyo file than when it is read from a .py file; the only thing that's faster about .pyc or .pyo files is the speed with which they are loaded. »
Un fichier toto.pyc sera chargé plus rapidement que son copain toto.py, mais l'exécution en elle-même du programme sera aussi rapide avec l'un comme avec l'autre.
-- François
Bruno Desthuilliers
Pardon de remonter ce fil sur le byte-code Python et le rapport avec la rapidité d'exécution d'un script. Juste pour signaler que j'ai vu ceci dans le tutoriel de Guido van Rossum en personne (concepteur de Python).On peut donc prendre ça au sérieux.
« A program doesn't run any faster when it is read from a .pyc or .pyo file than when it is read from a .py file; the only thing that's faster about .pyc or .pyo files is the speed with which they are loaded. »
Un fichier toto.pyc sera chargé plus rapidement que son copain toto.py, mais l'exécution en elle-même du programme sera aussi rapide avec l'un comme avec l'autre.
Forcément. Puisque le "chargement" d'un .py (en l'absence d'un .pyc correspondant et plus récent que le .py) consiste à compiler le source en byte-code, et (dans le cas d'un import) à sauvegarder ce byte-code dans le .pyc. C'est donc exactement le même byte-code qui est exécuté dans les deux cas (même rapidité d'exécution), mais le temps de "chargement" est plus long pour le .py puisqu'il faut le compiler.
Esprit de Monsieur de Lapalisse, es-tu la ?-)
Pardon de remonter ce fil sur le byte-code Python et le rapport avec
la rapidité d'exécution d'un script. Juste pour signaler que j'ai vu
ceci dans le tutoriel de Guido van Rossum en personne (concepteur de
Python).On peut donc prendre ça au sérieux.
« A program doesn't run any faster when it is read from a .pyc or .pyo
file than when it is read from a .py file; the only thing that's faster
about .pyc or .pyo files is the speed with which they are loaded. »
Un fichier toto.pyc sera chargé plus rapidement que son copain
toto.py, mais l'exécution en elle-même du programme sera aussi rapide
avec l'un comme avec l'autre.
Forcément. Puisque le "chargement" d'un .py (en l'absence d'un .pyc
correspondant et plus récent que le .py) consiste à compiler le source
en byte-code, et (dans le cas d'un import) à sauvegarder ce byte-code
dans le .pyc. C'est donc exactement le même byte-code qui est exécuté
dans les deux cas (même rapidité d'exécution), mais le temps de
"chargement" est plus long pour le .py puisqu'il faut le compiler.
Pardon de remonter ce fil sur le byte-code Python et le rapport avec la rapidité d'exécution d'un script. Juste pour signaler que j'ai vu ceci dans le tutoriel de Guido van Rossum en personne (concepteur de Python).On peut donc prendre ça au sérieux.
« A program doesn't run any faster when it is read from a .pyc or .pyo file than when it is read from a .py file; the only thing that's faster about .pyc or .pyo files is the speed with which they are loaded. »
Un fichier toto.pyc sera chargé plus rapidement que son copain toto.py, mais l'exécution en elle-même du programme sera aussi rapide avec l'un comme avec l'autre.
Forcément. Puisque le "chargement" d'un .py (en l'absence d'un .pyc correspondant et plus récent que le .py) consiste à compiler le source en byte-code, et (dans le cas d'un import) à sauvegarder ce byte-code dans le .pyc. C'est donc exactement le même byte-code qui est exécuté dans les deux cas (même rapidité d'exécution), mais le temps de "chargement" est plus long pour le .py puisqu'il faut le compiler.
