Le 26 septembre 2016 à 10:04:15 guyver2 a écrit :
le projet que je fais avec des geographes ou reecrire leur code python en C++, sans aucun changement algorithmique et sans augmentation de complexite du code a abouti a une amelioration de performance d'un facteur 60000.
C'est pas plutot les geographes le soucis
? Python s'en sort bien en calcul numerique si on lui fait pas faire des millions de boucles for et qu'on utilise les bonnes lib (ecrites en C/C++/fortran) 
Par exemple, un joli raytracer avec reflections en 150 lignes de python avec numpy qui tourne en 1/10eme de seconde.
Donc c'est bien ce que je dis, c'est pas python qui fait le calcul numerique 
L'histoire du code des geographes etait vraiment un probleme de python. En l'occurence, c'etait une interaction bizarre entre numpy et l'interpreteur python qui faisait barrer le code en couille. Reecrire le code un petit peu differement contourne le probleme et faisait aller le code en gros 1000 fois plus vite. Compiler le code avec pypy apportait un autre facteur 8. Et reecrire le code en C++ et activer toutes les options d'optimization de gcc donnait un autre facteur 8.
Donc heu ouais au final c'est bien pour faire des algos rapidement quand le gros des calcul est fait dans un langage plus bas niveau. Pour le coup c'est vraiment facile de faire une lib en C/C++ qui sera appelee par ton prog en python. Je fais comme ca depuis plusieurs années, je dev en python et ensuite je replace de maniere transparente certaines fonctions ou classes en code C++ quand c'est necessaire.
En calcul numerique, python ca marche pour le petit code et le code de haut niveau. Mais des que tu essayes de faire du calcul brute, ca ne suit pas et il faut passer a autre chose.
Deja si le code est pas compile, tu n'as aucune chance de tirer une perf quelconque d'un code numerique. Et les compilateurs python que j'ai essaye avaient plein de soucis de compatibilite avec differente lib, ce qui tuent completement l'interet de python qui est justement de reutiliser des blocs deja ecrit.