De toutes façons, la rapidité d'un programme, c'est 20% le matériel, 20% le langage, et 60% l'algo... C'est "empirique", mais c'est souvent très vrai.On peut de toutes façons distinguer trois types de langages :
- Interprétés,
- Managés / pseudo-code,
- Natifs.
Les langages interprétés (Python, PHP, Ruby, LUA, Javascript, ...) nécessitent un interpréteur pour fonctionner (si, si, j'vous assure !
), et souvent uniquement un interpréteur, mais offrent alors une portabilité colossale... La plupart des interpréteurs sont en ligne de commande, et peuvent être compilés sur quasiment n'importe quel système existant.
De plus, ils permettent des choses difficilement accessibles aux autres langages, comme la modification de code à la volée et l'auto-modification des programmes.
Inconvénient, ils sont souvent très lents... Dans le cadre d'un séquenceur / système de contrôle, ça n'a aucune importance. Si c'est pour du calcul lourd, c'est plus que rédhibitoire. Certains de ces langages sont "améliorés" en terme de vitesse d'exécution via une "compilation" à la volée lors de la première exécution (PHP notamment est plutôt efficace à ce sujet).
Autre inconvénient, les erreurs de syntaxe ne sont pas forcément détectées au lancement du programme, parfois c'est lorsque l'on arrive sur la ligne fautive uniquement (voire avec des valeurs particulières en plus), ce qui rend le test extensif de tels programmes assez pénible.
Les langages managés / en pseudo-code (.NET, inclus C# bien sûr, et Java) sont nettement plus véloces que les langages interprétés, par contre ils nécessitent un compilateur, un débugger, un IDE / gestionnaire de projets, bref toute une chaîne de développement. Leur portabilité est limitée à celle du framework qui les soutient (JDK/JRE, .NET) : si le framework existe, les programmes pourront être portés. Sinon, ça risque d'être coton, voire infaisable sans l'aide de la société éditrice. Avantage, par contre, si le framework existe, le programme n'a pas besoin d'être recompilé pour être utilisé sur une autre plate-forme matérielle.
Là aussi, une compilation "native" du pseudo-code est en général faite à la première exécution, pour accélérer le traitement... Cela ne résoud pas tout, hélas.
Enfin, les langages natifs, les plus "lourds" à gérer, produisent du code directement exécutable par le processeur, et sont compilés pour un couple processeur / système d'exploitation "figé". Un exécutable C compilé pour PowerPC / Linux ne fonctionnera JAMAIS tel quel sur une machine Windows / x86... Le programme devra être recompilé impérativement. De plus, le code binaire produit n'est pas le même en fonction du compilateur, et encore moins en fonction du langage source. Le débuggage peut s'avérer difficile et fastidieux en fonction des optimisations du compilateur, voire dans certains cas quasi-impossible.
Par contre, c'est le seul moyen d'obtenir des performances maximales (ou presque), en fonction du langage utilisé toutefois, et normalement déployable sur n'importe quelle plate-forme compatible avec simplement un "jeu" de librairies dynamiques (runtimes) pour certaines applications.
Par exemple, en considérant à chaque fois un matériel identique et des algos optimisés au quart de poil, on a souvent le classement suivant pour les langages les plus connus : Assembleur < C < C++ < Pascal/Delphi < ADA
Après, il faut voir aussi la vitesse de développement avec chacun de ces langages : faire un truc qui ne crashe pas en assembleur, ça peut devenir vite une prise de tête colossale... En ADA, par contre, c'est plutôt "si ça compile, ça marche", vu la rigueur colossale du langage au niveau de la phase lexicale/syntaxique...
Cela ne change pas qu'entre un programme en C, avec un bon algo, et son équivalent Java avec un algo tout aussi optimisé, la différence de performances sera
réelle, mais pas forcément aussi énorme qu'on pourrait le croire (hors calculs lourds, faut pas pousser non plus). Par contre, la vitesse de développement avec un langage de très haut niveau est bien plus réduite qu'avec un langage "bas niveau".
De même, en restant dans le domaine d'un "lourd" du domaine, C++ : entre un programme C++ "brut", où tout est développé / optimisé "à la main", et un programme C++ écrit en utilisant intensivement les templates, la STL et des API comme QT, le résultat final est là aussi clair et net : la version "à la barbare" est plus rapide (à optimisation d'algo égale, bien entendu), mais la version "soutenue" par des librairies de haut niveau a par contre pris deux fois moins de temps (au moins !!) à être écrite...
Quant à la perte de performances, même si elle est toujours mesurable, c'est parfois bien moins de 1% de différence si l'on n'est pas en train d'écrire une application de calcul lourd et/ou brassant d'énormes quantités de données...
Si c'est pour faire une application à usage unique / interne, une faisabilité, ou encore un outil de test, ou encore quelque chose de souvent modifié, il faut sérieusement se pencher sur la question du temps de développement... Et envisager les langages interprétés.
Si c'est pour quelque chose ne devant pas être touché, devant être rapide, diffusé largement, etc. alors les langages natifs sont à préférer.
Si cela ne doit pas être touché, diffusé largement mais que la rapidité d'exécution n'est pas cruciale, les langages managés sont l'idéal.
Comme dans presque tous les domaines de l'informatique, le choix du langage, c'est surtout une question de besoins et de contraintes de développement...
1 |
0 |
Envoyé par aityahia
(pour plaisanter)