[OSM-dev-fr] python shapely -> c geos

[Philippe Verdy]

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).
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20121117/8ead9a70/attachment.html>