Très inintéressant pour ne pas dire plus.
Passons les grosses erreurs de code en C++ évoquées plus haut, il y a plusieurs problèmes fondamentaux qui font qu'on ne peut comparer (ou qu'il n'est pas intéressant de la faire) facilement les performances du C++ et du Python :
- Python est principalement conçu pour faire un lien simple pour le programmeur entre des bibliothèques, qui sont souvent codées en C/C++. Ainsi il n'est pas pertinent de programmer en Python sans utiliser ces bibliothèques pour faire des gros calculs ou des simulations.
- Python est limité par l'interpréteur. Vous avez mentionné qu'il y avait 6 coeurs sur votre machine. Sachez que Python à ma connaissance ne tourne que sur un seul coeur. Ainsi en avoir 6 ou 1 ne change pas grand chose. Pour ce qui est du C++ il tourne par défaut sur un seul coeur mais pour faire des gros calculs on peut diviser le programme en tâches et les répartir sur les différents processeurs. Ainsi par exemple sur un 12 coeurs on peut gagner jusqu'à x12 en performances.
- Il est dommage d'avoir pris en compte le temps de compilation. Tout l'intérêt d'un langage compilé est de lancer le compilateur une seule fois puis de réutiliser la version compilée. Ainsi dans un cas d'utilisation normal on ne prendrait pas en compte le temps de compilation puisque quand on réexécute un programme on ne le recompile pas systématiquement.
Ainsi on ne peut comparer les deux langages car ils n'ont pas les mêmes usages. S'il s'agit simplement de faire tourner de lourdes simulations sans usage de bibliothèques externes, choisissez le C++.
S'il s'agit de faire un petit script qui ne demande pas trop de calculs ou d'utiliser directement des bibliothèques toutes faites, utilisez Python !
C'est dans les vieux pots que l'on fait les meilleures confitures
Pour ce problème, un bon vieux programme C, sans objet inutile, fera mieux que C++ : moins verbeux, plus rapide à compiler (car il faut bien compter aussi le temps de compilation dans le bench), et plus rapide à exécuter. Et même l'allocation/désallocation dynamique pourrait certainement être évitée. Aucun besoin de typage dynamique. On s'évertue à s'en débarrasser avec des interpréteurs modernes ultracompliqués pour python, alors que le problème est peut-être tout simplement que c'était un mauvais choix de base.. La variation de type contrainte par le graphe d'héritage, oui, pour des choses complexes, qui permet de factoriser du code, mais pour le l'algorithmie comme ce bench... Au secours.:?