Pour faire un test de performance, il serait probablement judicieux d'avoir l'interpréteur compilé avec les mêmes options et dans les mêmes conditions. Voici mon petit test.
Kernel 2.6.18-6-k7
CPU : Athlon 1.2 GHz (*)
RAM : 512 Mo DDR
Python 2.6.1 et 3.0 compilés avec les options suivantes :
./configure --with-fpectl --with-wctype-functions --with-pymalloc --with-doc-strings --with-threads --with-signal-module --with-system-ffi --enable-ipv6
Compilateur (affiché dans la console interpréteur) :
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)]
Ensuite j'ai repris le test précédent, dont voici les résultats obtenus :
10 échantillons c'est un peu faible, la tendance qui se dégage est que Python 3 est plus lent *sur ce test*, dans des conditions égales de compilation et d'exécution. Bien évidemment pour être affirmatif, il est nécessaire d'effectuer des tests de performances mettant en oeuvre des algorithmes choisis avec un nombre suffisamment grand d'échantillons.
Pour conclure, personellement, si j'ai besoin de performance de calcul je préfère de loin utiliser un algo en C ou Fortran que j'appelle dans l'interpréteur, c'est tellement simple et confortable.
[HS]
(*) Certains vont rire car parler de "performances" avec une telle machine face à celles d'aujourd'hui peut sembler incongru. Cependant elle n'a rien a envier aux netbooks à la mode et ronronne comme un chat depuis plus de 7 ans. (parfois le chat est enroué, saleté de poussière qui désaxe les ventilos !)
[/HS]
Effectivement, l'adoption de la version 3 en production demandera probablement du temps pour ceux qui ont besoin des extensions développées en C/C++/Fortran.
Numpy : pas de paquet précompilé, cependant sous Linux je compile sans soucis l'extension qui a l'air de bien fonctionner pour mon utilisation
Scipy, pyQt4 : non testés
Quand à l'utilisation de ces extensions avec Python 3, laissons un peu de temps aux développeurs pour absorber les changements et nouveautés. Rien n'empêche de contribuer aussi rapports de bugs, corrections, etc ...
Pour les impatients, compiler l'interpréteur et les extensions nécessaires en attendant les paquets "tout prêts" ;)
On ne peut présumer ici de l'avenir, je pense qu'il serait dommage d'abandonner Python au profit d'un autre langage. Lorsque mon choix s'est porté sur Mercurial c'est justement que je ne souhaitais pas devoir prendre des tonnes d'outils tierces alors que je travaille déjà avec Python (qui est très riche avec sa bibliothèque standard).
Même si Mercurial m'a au début un peu dérouté je m'y suis habitué rapidement. Je suis aussi utilisateur de SVN et Clearcase (pro). Ce que j'aime est le stockage des informations de configuration dans le répertoire .hg avec l'absence de serveur (même local) car sous certaines contraines (utilisation/accès/environnement) il me permet de faire de la micro-gestion de mes sources.
[^] # Re: Trollons peu trollons bien
Posté par Stephane Jeannenot . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 3.
Kernel 2.6.18-6-k7
CPU : Athlon 1.2 GHz (*)
RAM : 512 Mo DDR
Python 2.6.1 et 3.0 compilés avec les options suivantes :
./configure --with-fpectl --with-wctype-functions --with-pymalloc --with-doc-strings --with-threads --with-signal-module --with-system-ffi --enable-ipv6
Compilateur (affiché dans la console interpréteur) :
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)]
Ensuite j'ai repris le test précédent, dont voici les résultats obtenus :
10 itérations : (moyennne, écart-type)
python 2.6.1 = ( 0.00012204382154655558 ; 4.133267903850333e-06 )
python 3.0 = ( 0.0001832379235161111 ; 1.0711521205702668e-05 )
10 échantillons c'est un peu faible, la tendance qui se dégage est que Python 3 est plus lent *sur ce test*, dans des conditions égales de compilation et d'exécution. Bien évidemment pour être affirmatif, il est nécessaire d'effectuer des tests de performances mettant en oeuvre des algorithmes choisis avec un nombre suffisamment grand d'échantillons.
Pour conclure, personellement, si j'ai besoin de performance de calcul je préfère de loin utiliser un algo en C ou Fortran que j'appelle dans l'interpréteur, c'est tellement simple et confortable.
[HS]
(*) Certains vont rire car parler de "performances" avec une telle machine face à celles d'aujourd'hui peut sembler incongru. Cependant elle n'a rien a envier aux netbooks à la mode et ronronne comme un chat depuis plus de 7 ans. (parfois le chat est enroué, saleté de poussière qui désaxe les ventilos !)
[/HS]
[^] # Re: Nouveautés
Posté par Stephane Jeannenot . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 2.
PIL 1.1.6 fonctionne avec Python 2.6, même un paquet précompilé pour win existe : http://www.pythonware.com/products/pil/
Numpy : pas de paquet précompilé, cependant sous Linux je compile sans soucis l'extension qui a l'air de bien fonctionner pour mon utilisation
Scipy, pyQt4 : non testés
Quand à l'utilisation de ces extensions avec Python 3, laissons un peu de temps aux développeurs pour absorber les changements et nouveautés. Rien n'empêche de contribuer aussi rapports de bugs, corrections, etc ...
Pour les impatients, compiler l'interpréteur et les extensions nécessaires en attendant les paquets "tout prêts" ;)
[^] # Re: Mercurial 2.0
Posté par Stephane Jeannenot . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 1.
Même si Mercurial m'a au début un peu dérouté je m'y suis habitué rapidement. Je suis aussi utilisateur de SVN et Clearcase (pro). Ce que j'aime est le stockage des informations de configuration dans le répertoire .hg avec l'absence de serveur (même local) car sous certaines contraines (utilisation/accès/environnement) il me permet de faire de la micro-gestion de mes sources.
[^] # Re: Mercurial 2.0
Posté par Stephane Jeannenot . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 1.