Le 26 avril 2018 à 19:06:55 Grand__Smurf a écrit :

Mais clairement le probleme vient de l'interpreteur et si il y a une difference de fou entre for range et while, ca ne donne pas confiance.

Dans ce cas tu peux avoir exactement le même problème en C++ selon le compilateur utilisé.

En effet, on voit des differences forte sur certains code C++. J'ai des programmations dynamique qui ne sont pas bien optimiser par gcc, mais qui sont bien optimiser par icc. Et qui donne des difference d'un facteur 10 en gros.

Si tu te bases sur un bug pour définir la performance d'un langage, j'crois que tu devrais changer de métier.

Perso, je vis dans le vrai monde ou al performance du langage est donnee par l'outils qui me permet de faire tourner le code. Et pas dans un monde theorique ou il y a un compilateur/interpreteur super intelligent qui est a disposition. Et dans le vrai monde, python a de serieux probleme de performance sur des codes relativement simple. Comme c'est un langage plus complique et plus permissif. C'est plus difficile d'interpreter/compiler/optimiser. Et ca, ca vient bien du langage. Regarde en C, si tu as des problemes de compilation/performance, c'est souvent a cause d'une semantique de langage (pointer aliasing, risque d'overflow, ...)

Le 26 avril 2018 à 19:51:49 anaiogie a écrit :

Le 26 avril 2018 à 16:23:33 godrik a écrit :

Le 26 avril 2018 à 07:29:18 Grand__Smurf a écrit :

Le 25 avril 2018 à 23:44:51 Blaff12 a écrit :

Le 25 avril 2018 à 21:46:07 Grand__Smurf a écrit :

> Le 25 avril 2018 à 21:35:27 Blaff12 a écrit :

> * Pour avoir de meilleurs performances Indispensable pour les applications hautement mathématiques

Et bah justement non, t'as pas besoin que ça soit rapide pour des calculs, parce que dans tous les cas ça va prendre longtemps, alors c'est pas les quelques minutes de différence qui vont changer quoi que ce soit.

Essaye de coder un ray tracer en Python pur et revient me dire ça en face.

Mais comme je l'ai dis, je m'en bas les couilles que mon Raytracer prenne 2h plutôt qu'une pour render...

Peut etre que toi tu t'en fou, mais l'industrie ne s'en fout pas du tout. Je vais de la performance dans la vie, donc j'ai poser la question a plein de gens, des gens qui font de l'IA (Facebook), et des gens qui du graphismes (Disney) pour essayer de comprendre si j'allais dans le mur. Si ton ray tracer peut passer de 2h a 1h, ca veut dire que tu peux :

• faire plus de rendu pendant la nuit sur le meme materiel
• eteindre la moitie de ton materiel et sauver beaucoup d'electricite
• dans une journee de travail de 8 heures, tu peux faire 3 iterations avec un ray tracer de deux heure ou 5 avec un raytracer d'une heure

En vrai ce dernier exemple vient de gens d'IA qui peuvent rafiner le modele plus souvent quand tu gagnes un ordre de grandeur, en particulier quand tu atteins des temps qui sont plus petit qu'une journee. Si le modele prend plus d'une semaine a converger, ca veut dire qu'ils ne vont pas le faire, parcequ'ils ne pourront pas tuner les parametres. En pratique, si ca prends plus de 2 heures a entrainer le modele, ils ne vont probablement pas regarder le probleme de pres parceqeu les temps de developpement deviennent trop lent. Apres ils en regardent quelques un a cette echelle la, mais ils ne peuvent pas regarder des centaines de problemes qui ont ce cout de calcul.

Le 26 avril 2018 à 00:58:37 godrik a écrit :
passer de python a c++ a fait passe le code de 24 heures a quelques minutes avant de faire quoique ce soit d'ingenue.

Ouais alors là j'te le dis tout de suite, le problème venait pas du langage.

J'aime pas python hein, je l'utiliserais jamais, mais faut arrêter les conneries, de 24h à quelques minutes c'est pas le langage qui fait ça.

Et bah, si. J'ai fini par creuser pour comprendre ce qu'il se passait, et il se trouve que les constructions a base de forrange en python casse l'optimiseur de l'interpreteur. Et du coup, avec un optimiseur qui ne tourne pas, tu prends un facteur entre 100 et 1000 dans la gueule. En l'occurence, en reecrivant le code avec while au lieu de for, l'optimiseur s'active et ca se passe beaucoup mieux. Mais clairement le probleme vient de l'interpreteur et si il y a une difference de fou entre for range et while, ca ne donne pas confiance.

est ce l'exemple assez connu des allocations dynamiques bidon entre xrange vs range en python < 3 ? avec range qui va t'allouer dynamiquement ton tableau d'incides juste pour iterer dessus?

C'etait une histoire comme ca en effet. Mais le probleme n'etait pas un probleme d'allocation de ces trucs la parceque xrange avait le meme comportement. C'etait un probleme que l'utilisation de range cassait l'optimiseur (j'ai cause avec l'expert python local) et du coup le code etait reinterprete par iteration (ce qui a un cout monstre) et empeche toute les optimisations inter-iteration (software pipelining, vectorization, factorisation d'expression, et tous les trucs standard de polyhedrale).

si c'est ca, alors ce probleme d'allocations inutiles et tres penalisantes existe aussi en c++ avec des gens qui vont te faire du push back sur du vector pas reserve dans des for imbriques

ou du `vector<StructureLourde> foo(grandN);` declare a l'interieur d'une fonction appele beaucoup de fois, au lieu d'utiliser reserve la ici aussi ou de mettre ce vecteur ailleur pour faire moins d'allocations

Note qu'en l'occurence tout etait dans la meme fonction et donc un compilateur/interpreteur intelligent devrait savoir faire ca. (?)
Mais ce n'est pas forcement evident que le compilateur peut arriver a s'en rendre compte. Mais si le code:
for x in range (0,n): for y in range (0,n): for z in range (0,n): something(x,y,z)
est commun en python, alors c'est le travail du compilateur/interpreteur/middleware/runtime de s'assurer que l'execution de ces constructions la est correctement optimiser. Et comme il y a des problemes de typage en python, il y a plein de trucs qui devrait etre triviaux pour les outils et qui ne le sont pas en pratique.

pour moi sa reponse etait juste de l'etalage typique "oui sauf que https://image.noelshack.com/fichiers/2017/15/1491911449-laurence-gros2.png"

du coup je repond avec du risitas

j'ai le droit

C'est quand même plus intéressant pour moi et les éventuels lecteurs quand tu décris le fond de ta pensée avec des mots plutôt que des stickers que toi seul comprend...

Et en effet, je reconnais avoir lu en diagonal ton message et avoir donc répondu un peu à côté, j'espère que tu ne m'en veux pas.

Le 26 avril 2018 à 21:29:46 godrik a écrit :

Le 26 avril 2018 à 19:51:49 anaiogie a écrit :

Le 26 avril 2018 à 16:23:33 godrik a écrit :

Le 26 avril 2018 à 07:29:18 Grand__Smurf a écrit :

Le 25 avril 2018 à 23:44:51 Blaff12 a écrit :

> Le 25 avril 2018 à 21:46:07 Grand__Smurf a écrit :

>> Le 25 avril 2018 à 21:35:27 Blaff12 a écrit :

> > * Pour avoir de meilleurs performances Indispensable pour les applications hautement mathématiques

>

> Et bah justement non, t'as pas besoin que ça soit rapide pour des calculs, parce que dans tous les cas ça va prendre longtemps, alors c'est pas les quelques minutes de différence qui vont changer quoi que ce soit.

Essaye de coder un ray tracer en Python pur et revient me dire ça en face.

Mais comme je l'ai dis, je m'en bas les couilles que mon Raytracer prenne 2h plutôt qu'une pour render...

Peut etre que toi tu t'en fou, mais l'industrie ne s'en fout pas du tout. Je vais de la performance dans la vie, donc j'ai poser la question a plein de gens, des gens qui font de l'IA (Facebook), et des gens qui du graphismes (Disney) pour essayer de comprendre si j'allais dans le mur. Si ton ray tracer peut passer de 2h a 1h, ca veut dire que tu peux :

• faire plus de rendu pendant la nuit sur le meme materiel
• eteindre la moitie de ton materiel et sauver beaucoup d'electricite
• dans une journee de travail de 8 heures, tu peux faire 3 iterations avec un ray tracer de deux heure ou 5 avec un raytracer d'une heure

En vrai ce dernier exemple vient de gens d'IA qui peuvent rafiner le modele plus souvent quand tu gagnes un ordre de grandeur, en particulier quand tu atteins des temps qui sont plus petit qu'une journee. Si le modele prend plus d'une semaine a converger, ca veut dire qu'ils ne vont pas le faire, parcequ'ils ne pourront pas tuner les parametres. En pratique, si ca prends plus de 2 heures a entrainer le modele, ils ne vont probablement pas regarder le probleme de pres parceqeu les temps de developpement deviennent trop lent. Apres ils en regardent quelques un a cette echelle la, mais ils ne peuvent pas regarder des centaines de problemes qui ont ce cout de calcul.

Le 26 avril 2018 à 00:58:37 godrik a écrit :
passer de python a c++ a fait passe le code de 24 heures a quelques minutes avant de faire quoique ce soit d'ingenue.

Ouais alors là j'te le dis tout de suite, le problème venait pas du langage.

J'aime pas python hein, je l'utiliserais jamais, mais faut arrêter les conneries, de 24h à quelques minutes c'est pas le langage qui fait ça.

Et bah, si. J'ai fini par creuser pour comprendre ce qu'il se passait, et il se trouve que les constructions a base de forrange en python casse l'optimiseur de l'interpreteur. Et du coup, avec un optimiseur qui ne tourne pas, tu prends un facteur entre 100 et 1000 dans la gueule. En l'occurence, en reecrivant le code avec while au lieu de for, l'optimiseur s'active et ca se passe beaucoup mieux. Mais clairement le probleme vient de l'interpreteur et si il y a une difference de fou entre for range et while, ca ne donne pas confiance.

est ce l'exemple assez connu des allocations dynamiques bidon entre xrange vs range en python < 3 ? avec range qui va t'allouer dynamiquement ton tableau d'incides juste pour iterer dessus?

C'etait une histoire comme ca en effet. Mais le probleme n'etait pas un probleme d'allocation de ces trucs la parceque xrange avait le meme comportement. C'etait un probleme que l'utilisation de range cassait l'optimiseur (j'ai cause avec l'expert python local) et du coup le code etait reinterprete par iteration (ce qui a un cout monstre) et empeche toute les optimisations inter-iteration (software pipelining, vectorization, factorisation d'expression, et tous les trucs standard de polyhedrale).

Je suis assez surpris, car l'optimisation Python est extrêmement sommaire. Il y a juste un "peephole optimizer" à ma connaissance, rien d'aussi avancé que les techniques que tu listes. Et dans la pratique, les boucles while sont généralement plus lentes que les boucles for (tu peux faire le test). Peut-être étais-tu tombé dans un cas particulier.

Le 26 avril 2018 à 22:37:06 Blaff12 a écrit :

Le 26 avril 2018 à 21:29:46 godrik a écrit :

Le 26 avril 2018 à 19:51:49 anaiogie a écrit :

Le 26 avril 2018 à 16:23:33 godrik a écrit :

Le 26 avril 2018 à 07:29:18 Grand__Smurf a écrit :

> Le 25 avril 2018 à 23:44:51 Blaff12 a écrit :

>> Le 25 avril 2018 à 21:46:07 Grand__Smurf a écrit :

> >> Le 25 avril 2018 à 21:35:27 Blaff12 a écrit :

> > > * Pour avoir de meilleurs performances Indispensable pour les applications hautement mathématiques

> >

> > Et bah justement non, t'as pas besoin que ça soit rapide pour des calculs, parce que dans tous les cas ça va prendre longtemps, alors c'est pas les quelques minutes de différence qui vont changer quoi que ce soit.

>

> Essaye de coder un ray tracer en Python pur et revient me dire ça en face.

Mais comme je l'ai dis, je m'en bas les couilles que mon Raytracer prenne 2h plutôt qu'une pour render...

Peut etre que toi tu t'en fou, mais l'industrie ne s'en fout pas du tout. Je vais de la performance dans la vie, donc j'ai poser la question a plein de gens, des gens qui font de l'IA (Facebook), et des gens qui du graphismes (Disney) pour essayer de comprendre si j'allais dans le mur. Si ton ray tracer peut passer de 2h a 1h, ca veut dire que tu peux :

• faire plus de rendu pendant la nuit sur le meme materiel
• eteindre la moitie de ton materiel et sauver beaucoup d'electricite
• dans une journee de travail de 8 heures, tu peux faire 3 iterations avec un ray tracer de deux heure ou 5 avec un raytracer d'une heure

En vrai ce dernier exemple vient de gens d'IA qui peuvent rafiner le modele plus souvent quand tu gagnes un ordre de grandeur, en particulier quand tu atteins des temps qui sont plus petit qu'une journee. Si le modele prend plus d'une semaine a converger, ca veut dire qu'ils ne vont pas le faire, parcequ'ils ne pourront pas tuner les parametres. En pratique, si ca prends plus de 2 heures a entrainer le modele, ils ne vont probablement pas regarder le probleme de pres parceqeu les temps de developpement deviennent trop lent. Apres ils en regardent quelques un a cette echelle la, mais ils ne peuvent pas regarder des centaines de problemes qui ont ce cout de calcul.

> Le 26 avril 2018 à 00:58:37 godrik a écrit :

> passer de python a c++ a fait passe le code de 24 heures a quelques minutes avant de faire quoique ce soit d'ingenue.

Ouais alors là j'te le dis tout de suite, le problème venait pas du langage.

J'aime pas python hein, je l'utiliserais jamais, mais faut arrêter les conneries, de 24h à quelques minutes c'est pas le langage qui fait ça.

Et bah, si. J'ai fini par creuser pour comprendre ce qu'il se passait, et il se trouve que les constructions a base de forrange en python casse l'optimiseur de l'interpreteur. Et du coup, avec un optimiseur qui ne tourne pas, tu prends un facteur entre 100 et 1000 dans la gueule. En l'occurence, en reecrivant le code avec while au lieu de for, l'optimiseur s'active et ca se passe beaucoup mieux. Mais clairement le probleme vient de l'interpreteur et si il y a une difference de fou entre for range et while, ca ne donne pas confiance.

est ce l'exemple assez connu des allocations dynamiques bidon entre xrange vs range en python < 3 ? avec range qui va t'allouer dynamiquement ton tableau d'incides juste pour iterer dessus?

C'etait une histoire comme ca en effet. Mais le probleme n'etait pas un probleme d'allocation de ces trucs la parceque xrange avait le meme comportement. C'etait un probleme que l'utilisation de range cassait l'optimiseur (j'ai cause avec l'expert python local) et du coup le code etait reinterprete par iteration (ce qui a un cout monstre) et empeche toute les optimisations inter-iteration (software pipelining, vectorization, factorisation d'expression, et tous les trucs standard de polyhedrale).

Je suis assez surpris, car l'optimisation Python est extrêmement sommaire. Il y a juste un "peephole optimizer" à ma connaissance, rien d'aussi avancé que les techniques que tu listes. Et dans la pratique, les boucles while sont généralement plus lentes que les boucles for (tu peux faire le test). Peut-être étais-tu tombé dans un cas particulier.

CPython est assez basique, mais pypy sait faire des trucs comme ca (de memoire).

Mais en effet, si tu compare CPython a un code similaire mais ecrit en C++, tu vas voir des differences importantes. Sur des algos de programmations dynamiques (pas toutes, mais sur les algo de partitionement que je regardais a l'epoque, vers 2011), j'avais vu des differences de fou entre icpc et g++. Des facteurs de 10 ou 15 sur certains algos a l'avantage de icpc. Mais sur des codes creux (SpMV, SpMV symetrique), g++ gagnait a l'epoque de l'ordre de 15% sur icpc, son prefetching logiciel marchait mieux. C'etait il y a 7 ans, il faudrait refaire le benchmark aujourd'hui.

Le 25 avril 2018 à 19:00:23 souleyus a écrit :
Si on exclu les applis mobile

Tu trouves un langage plus adapté car plus spécialisé (communauté, librairies, paradigme) dans pratiquement tous les domaines.

Perso je cherche encore l’interêt du Python.

Le langage ne correspond à aucun environnement de développement, tu n’a rien qui nécessite du Python.

Savoir coder n’est pas une compétence, c’est la finalité derrière qui en est une et qui fait votre valeur ajouté.

Le 27 avril 2018 à 00:59:55 godrik a écrit :

Le 26 avril 2018 à 22:37:06 Blaff12 a écrit :

Le 26 avril 2018 à 21:29:46 godrik a écrit :

Le 26 avril 2018 à 19:51:49 anaiogie a écrit :

Le 26 avril 2018 à 16:23:33 godrik a écrit :

> Le 26 avril 2018 à 07:29:18 Grand__Smurf a écrit :

>> Le 25 avril 2018 à 23:44:51 Blaff12 a écrit :

> >> Le 25 avril 2018 à 21:46:07 Grand__Smurf a écrit :

> > >> Le 25 avril 2018 à 21:35:27 Blaff12 a écrit :

> > > > * Pour avoir de meilleurs performances Indispensable pour les applications hautement mathématiques

> > >

> > > Et bah justement non, t'as pas besoin que ça soit rapide pour des calculs, parce que dans tous les cas ça va prendre longtemps, alors c'est pas les quelques minutes de différence qui vont changer quoi que ce soit.

> >

> > Essaye de coder un ray tracer en Python pur et revient me dire ça en face.

>

> Mais comme je l'ai dis, je m'en bas les couilles que mon Raytracer prenne 2h plutôt qu'une pour render...

>

Peut etre que toi tu t'en fou, mais l'industrie ne s'en fout pas du tout. Je vais de la performance dans la vie, donc j'ai poser la question a plein de gens, des gens qui font de l'IA (Facebook), et des gens qui du graphismes (Disney) pour essayer de comprendre si j'allais dans le mur. Si ton ray tracer peut passer de 2h a 1h, ca veut dire que tu peux :

• faire plus de rendu pendant la nuit sur le meme materiel
• eteindre la moitie de ton materiel et sauver beaucoup d'electricite
• dans une journee de travail de 8 heures, tu peux faire 3 iterations avec un ray tracer de deux heure ou 5 avec un raytracer d'une heure

En vrai ce dernier exemple vient de gens d'IA qui peuvent rafiner le modele plus souvent quand tu gagnes un ordre de grandeur, en particulier quand tu atteins des temps qui sont plus petit qu'une journee. Si le modele prend plus d'une semaine a converger, ca veut dire qu'ils ne vont pas le faire, parcequ'ils ne pourront pas tuner les parametres. En pratique, si ca prends plus de 2 heures a entrainer le modele, ils ne vont probablement pas regarder le probleme de pres parceqeu les temps de developpement deviennent trop lent. Apres ils en regardent quelques un a cette echelle la, mais ils ne peuvent pas regarder des centaines de problemes qui ont ce cout de calcul.

> > Le 26 avril 2018 à 00:58:37 godrik a écrit :

> > passer de python a c++ a fait passe le code de 24 heures a quelques minutes avant de faire quoique ce soit d'ingenue.

>

> Ouais alors là j'te le dis tout de suite, le problème venait pas du langage.

>

> J'aime pas python hein, je l'utiliserais jamais, mais faut arrêter les conneries, de 24h à quelques minutes c'est pas le langage qui fait ça.

Et bah, si. J'ai fini par creuser pour comprendre ce qu'il se passait, et il se trouve que les constructions a base de forrange en python casse l'optimiseur de l'interpreteur. Et du coup, avec un optimiseur qui ne tourne pas, tu prends un facteur entre 100 et 1000 dans la gueule. En l'occurence, en reecrivant le code avec while au lieu de for, l'optimiseur s'active et ca se passe beaucoup mieux. Mais clairement le probleme vient de l'interpreteur et si il y a une difference de fou entre for range et while, ca ne donne pas confiance.

est ce l'exemple assez connu des allocations dynamiques bidon entre xrange vs range en python < 3 ? avec range qui va t'allouer dynamiquement ton tableau d'incides juste pour iterer dessus?

C'etait une histoire comme ca en effet. Mais le probleme n'etait pas un probleme d'allocation de ces trucs la parceque xrange avait le meme comportement. C'etait un probleme que l'utilisation de range cassait l'optimiseur (j'ai cause avec l'expert python local) et du coup le code etait reinterprete par iteration (ce qui a un cout monstre) et empeche toute les optimisations inter-iteration (software pipelining, vectorization, factorisation d'expression, et tous les trucs standard de polyhedrale).

Je suis assez surpris, car l'optimisation Python est extrêmement sommaire. Il y a juste un "peephole optimizer" à ma connaissance, rien d'aussi avancé que les techniques que tu listes. Et dans la pratique, les boucles while sont généralement plus lentes que les boucles for (tu peux faire le test). Peut-être étais-tu tombé dans un cas particulier.

CPython est assez basique, mais pypy sait faire des trucs comme ca (de memoire).

Ah oui, c'est vrai que moi dès le début je pensais à CPython. Pour Pypy c'est une autre affaire, effectivement je suis moins surpris que tu aies constaté de telle variations au niveau d'une boucle for vs while

Mais en effet, si tu compare CPython a un code similaire mais ecrit en C++, tu vas voir des differences importantes. Sur des algos de programmations dynamiques (pas toutes, mais sur les algo de partitionement que je regardais a l'epoque, vers 2011), j'avais vu des differences de fou entre icpc et g++. Des facteurs de 10 ou 15 sur certains algos a l'avantage de icpc. Mais sur des codes creux (SpMV, SpMV symetrique), g++ gagnait a l'epoque de l'ordre de 15% sur icpc, son prefetching logiciel marchait mieux. C'etait il y a 7 ans, il faudrait refaire le benchmark aujourd'hui.

Un facteur 10 juste en changeant de compilateur ?!
J'imagine que ipcp doit profiter de certaines optimisations hardware peu accessibles à g++.

Le 28 avril 2018 à 15:17:02 terin22 a écrit :
Perso je cherche encore l’interêt du Python.

Le langage ne correspond à aucun environnement de développement, tu n’a rien qui nécessite du Python.

Savoir coder n’est pas une compétence, c’est la finalité derrière qui en est une et qui fait votre valeur ajouté.

Tu peux facilement faire des scripts utilisateurs, ou serveurs. Il existe des librairies pour quasiment tout aussi donc pas besoin de réinventer la roue. Ca permet aussi de faire du calcul scientifique car la syntaxe du langage est très sobre et donc de permettre à des gens qui n'ont pas fait beaucoup de developpement de l'utiliser sans trop de prise de tête. En plus de ça c'est intégré dans des distris linux donc pas besoin de télécharger un interpreteur.

Mais en effet, si tu compare CPython a un code similaire mais ecrit en C++, tu vas voir des differences importantes. Sur des algos de programmations dynamiques (pas toutes, mais sur les algo de partitionement que je regardais a l'epoque, vers 2011), j'avais vu des differences de fou entre icpc et g++. Des facteurs de 10 ou 15 sur certains algos a l'avantage de icpc. Mais sur des codes creux (SpMV, SpMV symetrique), g++ gagnait a l'epoque de l'ordre de 15% sur icpc, son prefetching logiciel marchait mieux. C'etait il y a 7 ans, il faudrait refaire le benchmark aujourd'hui.

Un facteur 10 juste en changeant de compilateur ?!
J'imagine que ipcp doit profiter de certaines optimisations hardware peu accessibles à g++.

C'est le cas le plus extreme que je n'ai jamais vu. J'ai regarde l'assembleur pour voir ce qu'il se passait. Sur ce code la, tu avais plein de facteur en meme temps.

• icpc a l'epoque savait faire de l'optimisation a travers les appels de fonctions ce qui permettait d'inliner des tucs que g++ ne savait pas faire.
• la polyhedral de g++ n'avait pas vu qu'il pouvait bloquer l'execution ce qui donnait
  • une structure vectorizable alors que la version normale ne l'etait pas
  • une reutilisation du cache L1

D'un compilateur raisonnable a un autre compilateur raisonnable c'est rare d'avoir un facteur de plus de 2, mais la c'etait un cas ou g++ ne voyait rien a faire et icpc a trouve la reecriture qui change tout.

Le 28 avril 2018 à 16:59:36 Exacompta a écrit :

Le 28 avril 2018 à 15:17:02 terin22 a écrit :
Perso je cherche encore l’interêt du Python.

Le langage ne correspond à aucun environnement de développement, tu n’a rien qui nécessite du Python.

Savoir coder n’est pas une compétence, c’est la finalité derrière qui en est une et qui fait votre valeur ajouté.

Tu peux facilement faire des scripts utilisateurs, ou serveurs. Il existe des librairies pour quasiment tout aussi donc pas besoin de réinventer la roue. Ca permet aussi de faire du calcul scientifique car la syntaxe du langage est très sobre et donc de permettre à des gens qui n'ont pas fait beaucoup de developpement de l'utiliser sans trop de prise de tête. En plus de ça c'est intégré dans des distris linux donc pas besoin de télécharger un interpreteur.

Ouais, mais ça justifie pas sa popularité

http://pypl.github.io/PYPL.html
https://www.tiobe.com/tiobe-index/

Je cherche à comprendre pourquoi on apprend se langage partout maintenant, ça apporte vraiment un plus le python ?

Je cherche à comprendre pourquoi on apprend se langage partout maintenant, ça apporte vraiment un plus le python ?

C'est un compromis raisonnable entre un langage dur compile comme C#, java et C++, et un langage interprete completement dynamique comme ruby ou javascript. En tant que langage, c'est quand meme mieux goler que php ou javascript ouil y a des absurdites completes dans le systeme de typage.

Je pense que ses performances relativement limitées suffisent à justifier la raison.

Industriellement parlant de toute façon on s'enfou complètement de la syntaxe, c'est simplement les perfs qui compte.
Et sur ce point là, Python ne fait pas le poids.

Mais après, personnellement, ça a été mon premier langage, et c'est toujours mon préféré.

Industriellement parlant de toute façon on s'enfou complètement de la syntaxe, c'est simplement les perfs qui compte.

Et sur ce point là, Python ne fait pas le poids.

Quelle industrie ?
Développer du code en entreprise ne signifie pas forcément avoir le programme le plus rapide. Python répond à des besoins, C++ à d'autres.
Tout dépend des besoins, du contexte et de l'évolution prévue du code.

Tu ne sembles pas avoir rencontré le problème de maintenir du code historique. Relire du code C++ ou Javascript (et bcp d'autres langages) est une tannée par rapport à du Python bien qu'il soit possible d'écrire un code Python pourri.

Evidemment, écrire du code Python en entreprise nécessite une méthode et des outils adaptés. Je pense à un IDE comme PyCharm et certaines PEP.

Si tu préfères, la " grosse industrie ".

Mais oui c'est évident Python répond à certains besoins, notamment dans un contexte scientifique.