Si on exclu les applis mobile

Pas de multithreading en python a cause du gil.
Typage merdiqur en python.
Du code python est difficile a prouver.
Pas d'access au bas niveau qui est utile pour plein de projet.

Je suis sur qu'il y a plein d'autres raison.

Bah énormément de trucs, déjà python c'est quasiment impossible de faire du bas-niveau avec

Les principales raisons :

• Pour avoir de meilleurs performances Indispensable pour les applications hautement mathématiques
• Pour avoir un typage et de l'encapsulation plus régulée Utile pour les code base énormes avec beaucoup de développeurs
• Pour pouvoir programmer dans des environnements spécifiques Python ne permet pas de faire du Android, iOS, web client, etc
• Pour faire du bas level et de l'embarqué Rien ne remplace le C pour ce genre de nécessités

Après, Python est un langage qui convient "suffisamment bien" dans la plupart des applications possibles.

Sa grande force étant de permettre un prototypage rapide, d'avoir une grosse communauté d'utilisateurs, et de posséder beaucoup d'outils et frameworks.

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.

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.

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.

Si c'est en python "pur" c'est pas quelques minutes de différence.

Le 25 avril 2018 à 21:35:27 Blaff12 a écrit :
Les principales raisons :

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

c'est pas le fait d'avoir une application "hautement mathematique" qui rend la performance indispensable

typiquement, tout ce que tu fais avec mathematica et maple, c'est hautement mathematique, certes tu veux pas attendre trop longtemps, mais c'est pas un indispensable d'avoir quelque chose d'ultra performant, du moins pas dans tous les cas

la ou tu as un indispensable au niveau perf, c'est quand tu commences a avoir des contraintes temps reel, faut que ca aille vite car tu en es contraint

• Pour avoir un typage et de l'encapsulation plus régulée Utile pour les code base énormes avec beaucoup de développeurs
• Pour pouvoir programmer dans des environnements spécifiques Python ne permet pas de faire du Android, iOS, web client, etc
• Pour faire du bas level et de l'embarqué Rien ne remplace le C pour ce genre de nécessités

Après, Python est un langage qui convient "suffisamment bien" dans la plupart des applications possibles.

Sa grande force étant de permettre un prototypage rapide, d'avoir une grosse communauté d'utilisateurs, et de posséder beaucoup d'outils et frameworks.

Le 25 avril 2018 à 22:37:16 anaiogie a écrit :

Le 25 avril 2018 à 21:35:27 Blaff12 a écrit :
Les principales raisons :

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

c'est pas le fait d'avoir une application "hautement mathematique" qui rend la performance indispensable

typiquement, tout ce que tu fais avec mathematica et maple, c'est hautement mathematique, certes tu veux pas attendre trop longtemps, mais c'est pas un indispensable d'avoir quelque chose d'ultra performant, du moins pas dans tous les cas

la ou tu as un indispensable au niveau perf, c'est quand tu commences a avoir des contraintes temps reel, faut que ca aille vite car tu en es contraint

Oui, sauf que aujourd'hui, une bonne partie des contraintes de "temps réelle" auxquelles les programmes font faces sont I/O bound (requêtes, accès BDD, etc.), et dans de tels cas, coder ton application en C++ plutôt qu'en Python ne garantit pas d'améliorer significativement les performances.

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.

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

Le 25 avril 2018 à 22:37:16 anaiogie a écrit :

Le 25 avril 2018 à 21:35:27 Blaff12 a écrit :
Les principales raisons :

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

c'est pas le fait d'avoir une application "hautement mathematique" qui rend la performance indispensable

typiquement, tout ce que tu fais avec mathematica et maple, c'est hautement mathematique, certes tu veux pas attendre trop longtemps, mais c'est pas un indispensable d'avoir quelque chose d'ultra performant, du moins pas dans tous les cas

la ou tu as un indispensable au niveau perf, c'est quand tu commences a avoir des contraintes temps reel, faut que ca aille vite car tu en es contraint

Oui, sauf que aujourd'hui, une bonne partie des contraintes de "temps réelle" auxquelles les programmes font faces sont I/O bound (requêtes, accès BDD, etc.), et dans de tels cas, coder ton application en C++ plutôt qu'en Python ne garantit pas d'améliorer significativement les performances.

"oui, sauf qu'une bonne partie est io bound"

"dans de tels cas, coder ton application en C++ plutôt qu'en Python ne garantit pas d'améliorer significativement les performances"

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.

Ca c'est juste pas vrai. La plupart des codes de calcul numerique ecrit en python que j'ai regarde etait extrement lent a cause de python.

Recement j'ai regarde avec des collegues geographe des calculs qu'il faisait et passer de python a c++ a fait passe le code de 24 heures a quelques minutes avant de faire quoique ce soit d'ingenue.

L'interpreteur python a des performances difficile a prevoir et des fois un changement qui a l'air cosmetique peut completement tuer les performances.

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...

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.

python + data science / big data > all

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

Donc j'imagine que pixar s'en fout que une frame qui met environ 3-4h (jusqu'à 7 parfois) à render en prenne UN MOIS entier maintenant. Parce que oui, on parle d'un facteur 100 (voire 200, 300, 400 parfois) entre C++ et Python, pas un tout petit facteur 2.

Aussi j'imagine qu'on s'en bat les couilles que le frein (bon le frein sera toujours mécanique justement pour ces raisons) mette 3 minutes à s'activer.

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.

Bien sûr que si, de 24h à quelques minutes c'est encore un facteur de l'ordre de 100/200 donc c'est très fortement possible. C'est raisonnable pour des langages interprétés.

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.

Et en l'occurence, je raconte ce probleme la, mais ce n'est pas le premier probleme de performance du genre que je rencontre en python. D'ailleurs les auteur de python le savent et le disent: si ton python est lent, reecrit en C.

Le 26 avril 2018 à 00:56:27 anaiogie a écrit :

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

Le 25 avril 2018 à 22:37:16 anaiogie a écrit :

Le 25 avril 2018 à 21:35:27 Blaff12 a écrit :
Les principales raisons :

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

c'est pas le fait d'avoir une application "hautement mathematique" qui rend la performance indispensable

typiquement, tout ce que tu fais avec mathematica et maple, c'est hautement mathematique, certes tu veux pas attendre trop longtemps, mais c'est pas un indispensable d'avoir quelque chose d'ultra performant, du moins pas dans tous les cas

la ou tu as un indispensable au niveau perf, c'est quand tu commences a avoir des contraintes temps reel, faut que ca aille vite car tu en es contraint

Oui, sauf que aujourd'hui, une bonne partie des contraintes de "temps réelle" auxquelles les programmes font faces sont I/O bound (requêtes, accès BDD, etc.), et dans de tels cas, coder ton application en C++ plutôt qu'en Python ne garantit pas d'améliorer significativement les performances.

"oui, sauf qu'une bonne partie est io bound"

"dans de tels cas, coder ton application en C++ plutôt qu'en Python ne garantit pas d'améliorer significativement les performances"

En l'occurence, il a raison, si ton probleme est IO bound, tu ne devrasi pas voir beaucoup de difference entre python et C++. Et en effet, il y a des classes entiere d'applications qui snot IO bound, et du coup, le langage on s'en fout un peu.
Pour les applis calculatoire (et il y en a de plus en plus en dans cette ere du big data), la tu vois une difference fondamentale entre un code qui se compile bien et un langage qui ne se compile pas bien.

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é.

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

Le 26 avril 2018 à 16:26:29 godrik a écrit :

Le 26 avril 2018 à 00:56:27 anaiogie a écrit :

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

Le 25 avril 2018 à 22:37:16 anaiogie a écrit :

Le 25 avril 2018 à 21:35:27 Blaff12 a écrit :
Les principales raisons :

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

c'est pas le fait d'avoir une application "hautement mathematique" qui rend la performance indispensable

typiquement, tout ce que tu fais avec mathematica et maple, c'est hautement mathematique, certes tu veux pas attendre trop longtemps, mais c'est pas un indispensable d'avoir quelque chose d'ultra performant, du moins pas dans tous les cas

la ou tu as un indispensable au niveau perf, c'est quand tu commences a avoir des contraintes temps reel, faut que ca aille vite car tu en es contraint

Oui, sauf que aujourd'hui, une bonne partie des contraintes de "temps réelle" auxquelles les programmes font faces sont I/O bound (requêtes, accès BDD, etc.), et dans de tels cas, coder ton application en C++ plutôt qu'en Python ne garantit pas d'améliorer significativement les performances.

"oui, sauf qu'une bonne partie est io bound"

"dans de tels cas, coder ton application en C++ plutôt qu'en Python ne garantit pas d'améliorer significativement les performances"

En l'occurence, il a raison, si ton probleme est IO bound,

il n'est pas question d'avoir raison ou tort, vous repondez a une question pas posee

pour recapituler :

la remarque que blaff a fait est

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

j'y repond en disant juste que c'est pas le fait que ce soit hautement mathematique qui rend le besoin de perf indispensable, sans evoquer de python vs c++ ou quoi que ce soit, juste, je pretends dire, que c'est pas le fait que ce soit tres mathematique qui implique un besoin de perf, en y apportant 2 contres exemples, c'est tout

ensuite je dis que c'est plutot lorsqu'on a une contrainte temps reel, quelle qu'elle soit, ca implique un besoin de perf, et ici je ne dis rien sur comment repondre a ce besoin de perf, en y apportant aucun exemple et en evoquant aucun langage

il repond en disant "oui, sauf que t'as une bonne partie qui est io bound et donc c++ vs python est caduque"

ok, mais ca contredit pas ce que je dis, quand je dis que t'as un besoin de perf dans le temps reel, je dis pas qu'il faut passer a c++, je dis juste, que t'as besoin de perf, quelle qu'elle soit

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

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?

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

Et en l'occurence, je raconte ce probleme la, mais ce n'est pas le premier probleme de performance du genre que je rencontre en python. D'ailleurs les auteur de python le savent et le disent: si ton python est lent, reecrit en C.