|
2003-01-02 11:24:55 - Contribution de aldweb - Transmis par aldweb
 " Quelle est la performance de mon outil de développement ? "
Voici une question que tout développeur se pose lorsqu'il choisit un outil et un langage de programmation. Car il souhaite bien sur concilier deux choses :
- programmer vite et facilement avec un langage qu'il affectionne
- obtenir un programme qui s'exécute de manière fluide
C'est pourquoi, j'ai élaboré une routine chronométrée, que j'ai appelée Bench2 qui vise à positionner les différents outils de développement en fonction de la rapidité d'exécution de cette routine dans chacun de ces langages.
Le précédent article sur ce sujet, paru sur PeekPocket en octobre 2002, a généré un grand nombre de commentaires, remarques et critiques positives.
Aussi, Bench2 a été revu et corrigé afin d'affiner l'analyse et d'ajouter de nouveaux outils de développement... et il y a quelques changements dans le classement !
RAPPEL DES OBJECTIFS DE BENCH2
J'ai développé la routine de "benchmark" (désolé, je ne sais pas traduire ce mot en français !) avec trois idées en tête que je liste ci-dessous par ordre d'importance :- Fournir un exemple simple mais néanmoins assez riche d'une même routine dans différents langages, le but étant avant tout pédagogique. Le résultat est que la comparaison des différents codes sources est très intéressante.
- Trouver une routine qu'un programmeur amateur moyen pourrait écrire, pas spécialement optimisée mais donnant le même résultat juste. Le résultat est toujours plus important que les moyens... dit le bon proverbe.
- Afin de donner une raison d'être ludique à l'écriture de cette même routine dans les différents langages, essayer d'évaluer l'efficacité des différents compilateurs et interpréteurs disponibles sur l'environnement Palm OS où performance et rapidité sont très importantes.
A ce stade, je vous invite à vous référer à mon précédent article sur le sujet Bench2.
QUOI DE NEUF DANS CETTE VERSION DE BENCH2 ?
- Ré-écriture complète de la routine Bench2 pour mieux "benchmarker" (ouh l'anglicisme !) les outils de développement.
Merci à tous ceux qui m'ont alimenté avec des analyses pointues, des commentaires brillants et des bonnes idées. - Par conséquence, j'ai fortement mis à jour cette page web !
- J'ai raffraichi les résultats pour NSBasic/Palm dans sa nouvelle version 3.0.0d
- J'ai mis à jour les résultats pour PP dans sa nouvelle version 1.05a
- J'ai ajouté les résultats pour cbasPad, Jump2, Rexx et Satellite Forms
LA ROUTINE BENCH2 "AMELIOREE"
début du programme
pour B=1 jusque 2 par palier de 1 faire
execute la routine NombreParfait
fin pour
fin du programme
routine NombreParfait
début de la routine
démarre le chronomètre
P = 0
pour N=2 jusque B*500 par palier de 1 faire
M = N2
S = 1
pour D=2 jusque M par palier de 1 faire
si B=1 alors si (N/D)=(N div D) alors S = S+D
si B=2 alors si (N modulo D)=0 alors S = S+D
fin pour
si S=N alors P = P+1
fin pour
arrête le chronomètre
si P<>3 alors le temps d'exécution = 0
affiche le temps d'exécution
fin de la routine
Note : "div" signifie "division entière"
ainsi 3 div 2 = 1 et 3/2 = 1.5
|
Les 4 premiers nombres parfaits sont : 6, 28, 496 et 8128. Comme nous recherchons les nombre parfaits entre 2 et 500 ou 1000, P devrait toujours contenir 3 à la fin de la routine. Si ce n'était pas le cas, alors un temps d'exécution de 0 seconde serait retourné, nous donnant donc l'indication d'une erreur de codage. De plus, la réutilisation de la variable P permet d'éviter qu'un compilateur "intelligent" ne détecte que cette variable n'est jamais réutilisée après qu'on l'ait chargée avec une valeur.
Les autres idées qui ont servi à l'établissement de cette routine furent les suivantes :- Garder la routine de benchmark aussi simple que possible afin de permettre une vraie comparaison entre les différents outils de programmation.
- Garder la routine aussi similaire que possible d'un langage à un autre, éviter des optimisations du style inc(P) au lieu de P:=P+1 en Pascal ou S+=D au lieu de S=S+D en C. Je ne sais pas si celà a un réel impact sur la performance, mais je pense que c'est plus simple de comparer la routine dans différents langages en procédant ainsi.
- La gestion des nombres réels et des nombres entiers est un sujet délicat dans l'environnement Palm OS et il a provoqué un grand nombre d'e-mails et de commentaires lorsque j'ai publié la version initiale de Bench2 qui n'effectuait pas le test avec le modulo. Le processeur DragonBall a une gestion native des entiers sur 16 bits sur laquelle certains outils de développement s'appuient quand d'autres outils ont développé une gestion propre des nombre entiers sur 32 bits. La conséquence évidente est que les seconds peuvent être un peu plus lents à l'exécution (mais pas toujours, par exemple PocketStudio tourne aussi vite avec le type integer qu'avec le type longint). La plupart des outils de développement s'appuient sur les APIs Palm OS pour gérer les nombres réels et la même remarque que pour les nombres entiers vaut aussi pour les gestions des nombres réels en simple précision ou en double précision. Il a bien fallu prendre une décision, et j'ai donc choisi de travailler avec les types simples entier et réel proposés par défaut par l'outil de développement pour le test Bench2 (même si, par exemple OnBoardC tourne plus vite avec le type Double qu'avec le type Float). Ceci est justifié par le fait que nous portons une attention particulière à notre deuxième objectif (une routine qu'un programmeur amateur moyen pourrait écrire, pas spécialement optimisée mais donnant le même résultat juste).
- La boucle [ si (N modulo D)=0 alors S = S+D ] tourne 4 fois plus (249001 fois) que celle avec [ si (N/D)=(N div D) alors S = S+D ] (62001 fois). Ceci fut fait pour prendre en compte les commentaires et retours qui me sont arrivés après avoir publié la version 1 de Bench2. En effet, je me suis gentiment fait rappeler, et je le reconnais bien volontiers, qu'un benchmark sur des nombres réels n'est pas toujours complètement significatif. Donc, la durée d'exécution totale de Bench2 sera pondérée par cette différence de nombre de boucles effectuées.
LE CODE SOURCE DE BENCH2 POUR CHAQUE LANGAGE
Seuls les résultats finaux sont reportés dans cet article. Pour le détail des codes source, des liens vers les langages et des résultats pour tous les outils de développement étudiés, merci de vous référer à la page codes sources Bench2 que j'ai posée sur mon aldweb Site.
Il est d'ailleurs fort enrichissant et instructif, pour le développeur amateur comme pour le développeur chevronné, de lire les codes sources dans les différents langages. Aussi, je vous invite vivement à les consulter.
Note : si vous voulez m'aider à étendre la liste des outils de développement déjà benchmarkés et que vous travaillez avec un langage non listé ici, je serais plus que content si vous me contactiez.
LES RESULTATS DE BENCH2
Tous les temps mesurés sont ceux obtenus sur mon Sony Clié PEG-N770C (processeur DragonBall à 33 MHz) en faisant tourner Bench2, soit avec un programme PRC autonome (pour les langages compilés), soit utilisant un runtime (pour les langages de style Pseudo-Code), soit dans de l'IDE de l'interpréteur.
Les tableaux de chronométrage complets sont sur mon site, page Benchmark. Je ne reporterai ici que le graphique final :
Langage Graphique (plus court = meilleur)
HSPascal 
CodeWarrior
Falch.net / GCC
PP
Jump2
PocketStudio
OnBoardC
SuperWaba
PLua
cbasPad
SmallBASIC
Satellite Forms
PocketC
HotPaw Basic
LyME
NS Basic/Palm
REXX
Palm Tcl
Sun MIDP (*)
picoBASIC (*)
|
(*) picoBASIC et Sun MIDP ne travaillent qu'avec des nombres entiers et ne proposent pas de gestion des nombres réels. C'est la raison pour laquelle la boucle [ si B=1 alors si (N/D)=(N div D) alors S = S+D ] ne peut être écrite telle quelle. En la remplaçant par [ si B=1 alors si (N-(N/D)*D)=0 alors S = S+D ] donne un moyen de ne pas retirer ces deux outils de développement de la comparaison des outils effectuée par Bench2 même s'ils ne peuvent pas être exactement et strictement comparés avec les autres outils de développement.
CONCLUSIONS
Alors, où est la vérité ? Y a t-il seulement une vérité dans cet exercice ?
Pour répondre à ces interrogations, rappelons nos objectifs initiaux et plus particulièrement celui ci : trouver une routine qu'un programmeur amateur moyen pourrait écrire, pas spécialement optimisée mais donnant le même résultat juste. Le résultat est toujours plus important que les moyens... dit le bon proverbe.
Donc, si l'on prend en compte cet objectif, on va considérer le Chrono Total de la routine Bench2 pour établir notre podium, en additionnant les chronos mesurés sur les 1ère et 2ème boucle. Et ceci sera NOTRE vérité pour les conclusions.
Le podium des outils :- Le grand vainqueur est HSPascal qui porte donc bien son nom (High Speed Pascal).
- Arrive en deuxième position, CodeWarrior, l'outil de développement officiel en C utilisé par les équipes de développeurs de Palm OS. On notera que CodeWarrior et HSPascal sont tellement proches en terme de résultat qu'on pourrait aussi les considérer comment gagnants execo.
- Arrive ensuite en troisième position GCC (l'outil GNU " encapsulé " dans Falch.net). Notons que la performance relative de GCC est très proche des deux premiers outils (92% à comparer avec 100%).
- Enfin, arrive en quatrième position un autre Pascal, PP. J'ai exceptionnellement étendu ce podium au quatrième outil de développement car PP est un tout nouvel outil développé par un Français... et je suis Français... (cocorico !)
Le podium des langages :- Les 7 premières places sont " trustées " (et encore un anglicisme barbare !) par les 3 compilateurs Pascal, les 3 compilateurs C et le surprenant compilateur Java qu'est Jump2. Je considère donc que et le Pascal et le C sont les langages vainqueurs de cette petite compétition sympathique qu'est Bench2.
- Les langages basés sur le Java arrivent en troisième position derrière le Pascal et le C, ce qui en font les langages à base de runtime les plus rapides, SuperWaba se détachant d'ailleurs nettement de Sun MIDP qui se rapproche plus du surprenant PLua.
- Enfin on trouve les langages typés Basic ou autres interprétés.
En guise de conclusion, n'oublions pas, comme me l'a fort gentiment rappelé George Henne de NSBasic Corporation, qu'un benchmark comme Bench2 doit être considéré dans un contexte complet de projet de développement dans lequel le développeur doit répondre aux questions suivantes afin de choisir un outil de développement adapté à ses besoins :- Quelle proportion du travail est liée à la performance du processeur ?
- Combien de temps va me prendre le développement de mon application ?
- Quel est le rendu visuel du projet ?
- Quelle sera sa compatibilité avec les différentes machines tournant sous Palm OS ?
- Quelle est la qualité du support de l'éditeur de l'outil de développement ?
- Quelle est la facilité de déploiement ?
- Quelle est la stabilité et la solidité de l'éditeur ? Quelle est la probabilité qu'il réponde présent pendant toute la durée de vie de mon produit ?
aldweb
|
