Que ce soit en Python ou Java ou C++ les différences de performances sont extrèmement minimes (à algorithme équivalent). Tout bonnement car le code est de toute façon exécuté en code natif compilé (même si en Python ou Java, la compilation est faite à la demande au tout début de l'utilisation d'une classe). Je dirais même l'ayant constaté souvent, que le code est plus rapide en Python ou Java qu'en C++, tout bonnement car la compilation a lieu sur la machine cible elle-même en tenant compte au mieux de ses capacités physiques et de tout un tas de critères liées aux mesures de performance (le code s'autooptimise) : ce n'est pas le cas du code C++ qui est compilé sur une machine donnée pour être déployé sur une autre dont on ne connait pas grand chose.
Bref le problème n'est pas là : le choix de l'algorithme (et surtout des structures de données utilisées), et divers détails (surtout liés à la "localité" des données, et à certaines autres choses comme la minimisation des appels à l'allocateur mémoire), c'est ce qui fait réellement la différence. L'autre différence c'est lié aux traitements qu'on fait en trop (par exemple analyser une structure en entier, pour n'en utiliser en fin de compte qu'une toute petite partie : les APIs ou bblilothèques utilisées doivent être bien choisies). Sinon en C++ on a tendance à en faire trop (et dans ce trop, ne pas tout vérifier et introduire des anomalies qui se répercutent sur ce dont on a réellement besoin). Bref une appli avant d'être du code dans un langage donné, c'est avant tout une bonne architecture, un bon design (ça passe même avant toute optimisation locale du code, surtout en C++, car Java ou Python et tout langage fonctionnant sur une base de machine virtuelle savent éliminer plein de choses automatiquement si on ne les utilise pas). Une solution hybride, c'est le C++ compilé en code managé pour une machine virtuelle (par exemple .Net) qui offre le meilleur des deux mondes (mais pas tout car C++ permet encore trop de choses : il faut se restreindre à employer du code managé "clean" sans manipulations de pointeurs supposant un modèle mémoire unique). Mais il n'y a strictement aucune différence de performance alors entre du C++ managé (ou C#), du Java (ou du J#) hormi les performances de la machine virtuelle elle-même (et les VM Java sont aujourd'hui excellentes, du moins celles fournies par Sun/Oracle, car du côté des VM Java de Google, Dalvik VM, ou de GNU c'est pas encore le top au niveau de leur gestionnaire mémoire ; on peut aussi le dire aussi de la VM pour CLI (.Net) de Microsoft est bien meilleure que les autres VM CLI portées actuellement. Si on veut le top des VM, Intel fournit une VM managée vraiment au poil (mais elle est chère et sert surtout pour des serveurs pro commerciaux); Intel sait aussi faire des compilateurs C++ très performants (y compris C++ pour CLI/.Net où il fournit des optimiseurs dynamiques pour les VM a compilation de type "JIT", autrement dit compilation à l'exécution, sur la machine cible et pouvant même adapter le code compilé en fonction de la charge à effectuer ou de la charge en cours, et la possibilité de distribuer le code automatiquement sur un réseau de processeurs distants fournisseurs de puissance, ou vers des processeurs massivement parallèles, tels que les GPU). C++ n'est cependant pas le code idéal pour programmer du parallélisme massif, il n'est pas assez précis pour décrire les conditions de "rendez-vous", de synchronisation, ou de dépendance entre les flux de données ou leur conditions de validité (ou alors il s'avère particulièrement verbeux et les oublis et erreurs de programmation sont alors nombreuses). De fait un compilateur C++ s'interdit plein d'optimisations possibles car il n'a pas les moyens de décider tout seul. J'ai programmé beaucoup en C et C++ dans le passé; maintenant je suis accro à Java (même si le langage est encore un peu verbeux pour certaines choses, mais il existe des moyens automatiques de réduire cette verbosité, y compris avec les générateurs de code et les frameworks), et de temps en temps Eiffel pour des modélisations plus complexes, surtout en phase de prototypage et évaluation de la faisabilité ou l'étude fonctionnelle préalable. D'autres langages plus pratiques (mais compatibles) apparaissent qui compilent pour une VM Java, .Net, ou Python ; même pour PHP qui inclue lui aussi une VM qui s'améliore de plus en plus mais n'a pas encore le même niveau de qualité et devrait plutôt songer à utiliser une compilation vers une VM Java, .Net, ou Python, ce qui est parfaitement possible et permettrait des intégrations et déploiement plus faciles. Javascript aussi est devenu extrèmemement performant dans ses VM. On reproche souvent aux programmeurs Java ou .Net (et surtout Javascript) d'utiliser trop la "Réflexion", c'est vrai, ça ralentit énormément beaucoup et ça brise le moule solide de l'analyse et la modélisation. Pourtant on a des outils dans les deux cas qui permettent au code à l'exécution d'utiliser une seule fois la Réflexion pour générer du code à l'exécution, ce code étant ensuite exécuté sans appel à la Réflexion. De même, le moule de l'analyse et de la modélisation peut être maintenu en isolant le générateur de code utilisant la réflexion dans un moule "Factory" bien isolé. Les programmeurs C ou C++ s'arrêtent uniquement au code qu'ils analysent à l'échelle d'une seule fonction ou méthode, ils n'ont pas beaucoup d'outils pour avoir une vision globale du programme tel qu'il sera déployé ou utilisé : le retour d'expérience est très lent et très parcellaire, les choix sont souvent assez arbitraires et trop limités (et bien peu de programmeurs C/C++ savent programmer des générateurs de code à l'exécution, car cela demande des compétences sérieuses et dans des techniques très complexes de compilation). Mais au moins ils peuvent apprendre des frameworks standards quelques bases sur les meilleurs modèles de données. De même un programmeur C/C++ qui aujourd'hui ne maitrise pas la modélisation UML de pondra plus grand chose de bien (ou alors au prix de très longs et coûteux efforts et de passer leur temps à tenter de corriger des tonnes d'anomalies sur les nombreuses impasses qui ont été commises) : on n'avance pas vite en C/C++, les progrès sont lents dès qu'on dépasse le stade d'une seule méthode, même pour des choses aussi simple qu'une collection linéaire d'objets (si on ajoute le polymorphisme à ces objets, la situation s'agrave, le code se remplit de tonnes de if/else et de switch plus ou moins complets, sans compter des tonnes de variables plus ou moins locales dont on a du mal à suivre ce qu'on appelle les "préconditions"). L'ennui de tous ces nouveaux langages ce n'est pas le langage (un langage d'apprend en quelques heures, un peu plus pour les langages dits "fonctionnels" qui introduisent de nouveaux concepts, justement dans les préconditions et la vérifiabilité du code) mais la profusion des frameworks : on a du mal à rentrer dans tous, les docs sont interminables et on n'a pas le temps de tout lire ; on ne peut pas passer son temps à en comprendre pour chacun leurs subtitilités. Mais on peut se débrouiller en voyant que de nombreux modèles communs sont implémentés dans ces frameworks, et justement en évitant de rentrer dans des subtitlités trop spécifiques (afin de permettre ensuite d'en remplacer un par un autre avec une couche d'abstraction minimale limitant juste aux fonctions dont on a réellement besoin, autrement dit la spécification des "interfaces" nécessaires, dépourvues totalement d'implémentations et les plus petites possibles). Les langages très productifs et très performants d'aujourd'hui sont pratiquement tous des langages à VM, ou compilant pour une VM (même si la VM ajoute des contraintes ne permettant plus de faire ce qui était permis avant dans le langage d'origine), ils sont tous orientés objets (mais au delà de la seule programmation "OO" du pauvre C++, les langages dits "fonctionnels" tendent à être de plus en plus utilisés, ou bien les frameworks implémentent ces fonctionnalités pour exposer une programmation fonctionnelle, qui permet de très nombreuses optimisations dynamiques et une très grande souplesse tout en gardant une modélisation très solide sur une architecture la plus opaque possible).
_______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
