Le message qui suit est une réponse automatique activée par un modérateur.
Les réponses automatiques permettent d'éviter aux modérateurs d'avoir à répéter de nombreuses fois la même chose, et donc de leur faire gagner beaucoup de temps.
Nous sommes néanmoins ouverts et si vous avez une question ou une remarque, n'hésitez pas à contacter le modérateur en question par MP.
Veuillez modifier le titre du sujet
Bonjour,
Ce sujet a un titre qui ne décrit pas correctement le sujet, ou il est écrit en majuscules.
La présentation de votre message étant néanmoins correcte, nous ne fermons pas le sujet, mais vous êtes invité(e) à modifier son titre en éditant votre premier message.
Cette modification doit être faite dans les plus brefs délais, sans quoi nous serons dans l’obligation de clore le sujet .
Voici quelques correspondances pour vous aider à choisir au mieux votre titre :
Il faut bien comprendre ce que l'on entend par "lent".
Python étant un langage à bytecode, il va effectivement être moins rapide que le code équivalent compilé nativement sur ta machine (par exemple en C ou C++), mais cela ne signifie pas que tu vas voir ton programme pédaler en côte à chaque opération : son implémentation standard (CPython) en fait actuellement l'un des langages interprétés les plus rapides (il dispose d'un avantage léger sur Java et Ruby sur certaines opérations, et scotche littéralement PHP...), et il existe d'autres implémentations (Pypy, Unladen Swallow) qui visent à optimiser encore les performances (et y arrivent de manière sensible).
Ensuite, ce que tu perds en vitesse par rapport à C et C++, tu le gagnes en simplicité de développement, en économie de lignes de code, et en portabilité directe (puisqu'il est interprété).
De plus, sache qu'il est tout à fait possible, au pire, d'écrire des modules pour Python en C ou C++ : ceci permet, une fois que l'on a isolé dans un programme toute la partie du code qui est "sensible" au niveau performances, de les effectuer à une vitesse pratiquement native, tout en les incluant naturellement dans du code Python. Ceci dit, je n'ai personnellement jamais eu recours à ce genre de solution alors que je programme en Python au boulot : l'implémentation standard est suffisamment rapide pour que mes programmes soient (très) réactifs.
Enfin, tout dépend de ce que tu cherches à programmer (pour du gros calcul matriciel ou de la 3D en temps réel, là, effectivement, Python "seul" s'essouffle), mais personnellement, je pense qu'il est bon de connaître Python, même si tu apprends ensuite un langage compilé comme C++ : le temps d'apprentissage n'est pas du tout le même (C++ est beaucoup plus complexe à appréhender), les applications concrètes sont différentes et les deux forment un tandem complet.
Edit :
Ah, oui, et modifie ton titre avant ce soir, sinon le topic sera fermé.
non mais en fait c'est lent ...
c'est pour ça qu'il y a autant de réponses différentes sur les sujets portant sur du code. Non pas qu'il y ait rééllement plusieurs réponses, mais chacun essaye d'optimiser le code précédent; et ça c'est marrant
non mais en fait c'est lent ...
c'est pour ça qu'il y a autant de réponses différentes sur les sujets portant sur du code. Non pas qu'il y ait rééllement plusieurs réponses, mais chacun essaye d'optimiser le code précédent; et ça c'est marrant
Je dirais plutôt que chacun essaye de "pythonifier" le code précédent : le rendre le plus "pythonnique" possible (ça vient du principe de python : « There should be one, and preferably only one way to do it »).
C'est surtout que chacun veut poster quelque chose, mais comme celui de juste avant a déjà posté la solution et qu'en général les problèmes sont assez triviaux pour qu'il n'y ait pas 36 moyens de le faire, on change un bout et on dit "oh tiens on aurait pu faire ça aussi"
Sinon, Pypy est plus rapide que C dans certains cas (bien choisis).
Peux-tu développer stp puisque tu connais aussi C++ me semble-t-il ? Une fois Python bien compris, en quoi n'a-t-on pas fait un grand pas vers une compréhension approfondie de certains concepts du C++ (même si de nombreux détails techniques diffèrent) ?
Bon, alors je ne vais peut-être pas faire l'unanimité, mais puisque tu me demandes mon avis…
Le problème de C++ pour quelqu'un qui a appris Python (jusqu'à devenir "pythonnique") en premier langage, c'est avant tout, évidemment, la résolution de types à la compilation. Quand on vient du duck-typing de python, on a l'habitude que le polymorphisme "se fasse tout seul". Bon, en fait, cela devient vite contourné quand on prend l'approche "je fais beaucoup d'interfaces publiques abstraites", mais ça laisse un goût de plomb dans la bouche quand même, parce qu'il faut différencier plus précisément les comportements que l'on veut figer dans le marbre à la compilation (là, je pense aux templates), et ceux que l'on veut pouvoir changer dynamiquement à l'exécution si nécessaire.
En python, il n'y a pas ce genre de problématique : on peut tout faire sur tout, tout le temps, tout est objet, et par définition tout est dynamique. En gros, ça demande d'acquérir une rigueur et une précision dans la conception, que Python n'encourage pas nécessairement.
Après ça, je pense qu'il y a aussi la gestion de la mémoire… Contrairement au C où l'on n'a pas le choix, en C++ on est libre de se rapprocher ou s'éloigner du silicium à notre guise. Pour ça, il y a pas mal de mécanismes dont il faut passer du temps à étudier le fonctionnement pour en comprendre les secrets (par exemple : pointeurs ou références ou pointeurs intelligents et si pointeur intelligent que type de pointeur intelligent utiliser dans quel cas ? Ou encore les différents styles d'itérateurs...). Alors qu'en Python, tout est référence et le tout-puissant garbage-collector nous soulage de ça.
Ce dernier exemple (les différents styles d'itérateurs) m'amène à ce que je reprocherais le plus volontiers à C++ : pour paraphraser le Zen de Python « there is never only one way to do it ». Même en ayant pratiqué C++ de façon professionnelle pendant maintenant 3 ans, j'ai encore du mal à définir/utiliser une sémantique claire. C'est, je pense, l'un des points qui font que l'on n'est jamais vraiment totalement à l'aise en C++ : il y a tellement de manières de faire la même chose qu'il est plutôt difficile de déterminer si ce que l'on fait est "propre", adapté au problème à résoudre, "sémantique", clair, ou facile à réutiliser derrière…
C'est là qu'intevient la relation <math>\(python_{t_{exec}} + python_{t_{codage}} = \alpha ( cpp_{t_{exec}} + cpp_{t_{codage}} )\)</math> avec le coeficient <math>\(\alpha\)</math> qui reste à déterminer
Je programme en C++ et en Python, ça dépend des besoins, et tu pourrais poster tes (futurs) projets ici histoire que l'on compare
Ton coefficient <math>\(\alpha\)</math> dépend du projet, et est assez variable, quoique, dans beaucoup de cas (ceux où l'application n'est pas un gouffre à performances comme un programme de Vision Par Ordinateur en temps réel, par exemple), supérieur, voir très supérieur à 1.
Pour pratiquer les 2 langages de manière professionnelle, je pense être bien placé pour dire que quand on peut se passer de C++, programmer en Python est beaucoup plus facile, rapide et agréable.
Pour pratiquer les 2 langages de manière professionnelle, je pense être bien placé pour dire que quand on peut se passer de C++, programmer en Python est beaucoup plus facile, rapide et agréable.
Ton coefficient \alpha dépend du projet, et est assez variable, quoique, dans beaucoup de cas (ceux où l'application n'est pas un gouffre à performances comme un programme de Vision Par Ordinateur en temps réel, par exemple), supérieur, voir très supérieur à 1.
Ton coefficient \alpha dépend du projet, et est assez variable, quoique, dans beaucoup de cas (ceux où l'application n'est pas un gouffre à performances comme un programme de Vision Par Ordinateur en temps réel, par exemple), supérieur, voir très supérieur à 1.
Inférieur
Ça dépend de ce que représentent les variables "python" et "cpp" dans son équation, mais s'il s'agit d'un score "le plus, le mieux", c'est bien supérieur (si c'est juste une question de temps, là on est d'accord).
Pour pratiquer les 2 langages de manière professionnelle, je pense être bien placé pour dire que quand on peut se passer de C++, programmer en Python est beaucoup plus facile, rapide et agréable.
Ça, c'est clair !
Tout "gros" programme en C++ contient (espérons-le) du code pour lequel C++ est bien à l'aise (traitement d'image, gros calculs, 3D...), et il contient aussi énormément (et généralement beaucoup plus) de code pour lequel C++ est totalement inadapté :
Donc, la solution logique est d'utiliser un langage haut niveau où c'est possible (python, lua, etc), et un langage bas niveau mais très rapide (C++) pour le reste.
Exemples :
- Lightroom, tout le traitement d'images est en C/C++, tout le reste en Lua.
- eric, IDE python, tout est en python sauf l'éditeur de texte (Scintilla)
Citation : NoHaR
pour du gros calcul matriciel
python + scipy + blas/lapack
J'ai envie de me mettre au D, aussi. Cela semble un langage tout à fait excellent, la rapidité du C++, sans les inconvénients excessivements nombreux (langage compréhensible, GC à la carte, types de base puissants, etc)
Désolé de remonter le sujet, mais je voulais rajouter (comme on en parle pas sur le sujet et sa me parait important) que se n'est pas le langage par lui même qui défini si le programme (gourmand ou non) est rapide ou lent mais belle est bien les composants de la machine.
En effet pour prendre un exemple, si vous faites tourné un serveur de discussion multi-clients sur une connexion câblé en électrique avec PC 500mo de ram et un CPU de 1,60Ghz développé en C voir en assembleur, je vous assure que pour le même programme en python avec un PC 8go de ram avec un CPU 4xcoeur 3,68 Ghz sur une connexion fibre optiques et bien votre programme en python seras bien bien bien plus rapide que votre même programme en C.
On ne peut pas comparer deux langages avec deux machines différentes, ça va de soi, et c'est pourquoi on en parle pas.
Pour moi sa me parait important d'en parler et/ou de le rappeler car je pense que l'auteur du poste se posait plus la question de savoir si ces programmes développés en python seront lent ou pas et sa ne doit pas influencer le choix du langage python pour les personnes qui se pose la question :
es que mon programme python seras lent ou pas ?
Quand on parle de rapidité d'un langage (ou d'une implémentation d'un langage, pour être plus précis), on compare normalement avec d'autres langages similaires depuis un environnement identique. C'est évident qu'on ne peut pas comparer quelque chose depuis deux ordinateurs fondamentalement différents et que les résultats sont faussés.
Je ne crois pas que la précision que tu amènes, guyome41, ne soit très pertinente.
Si, justement, on peut, et le post en question contient 3 trucs intéressants :
- quand le programme passe 90% du temps à attendre (l'utilisateur, les IO...) alors ce n'est pas si utile qu'il soit optimisé à mort, autant le faire en python...
- pour un truc complexe (comme un serveur de chat) il n'est pas dit qu'un programme dans un langage "lent" sera plus lent que le même dans un langage "rapide" (implémenter des algos efficaces demande beaucoup plus d'effort avec un langage bas niveau)
- dans l'hypothèse ou on a 2 programmes équivalents, limités par le cpu, développés chacun par des types qui ne sont pas des tanches, avec un temps de développement illimité, il faudrait beaucoup plus qu'un "CPU 4xcoeur 3,68 Ghz" pour que le programme en python batte le programme en C sur un 1.6 GHz... mais ça fait beaucoup d'hypothèses...
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Python c'est bon, mangez-en.