aldweb

Fermer I. aldweb

Fermer II. Gratuitiels PC

Fermer III. Gratuitiels Palm

Fermer IV. Partagiciels Palm

Fermer V. iziBasic Palm

Fermer VI. Connaissance Palm

Fermer VII. Ordinateur Poche

Fermer VIII. miniPortail

Recherche




Newsletter
Pour avoir des nouvelles de ce site, inscrivez-vous à notre Newsletter.
S'abonner
Se désabonner
298 Abonnés
Webmaster - Infos
Visites

   visiteurs

   visiteurs en ligne

article.gifVI. Connaissance Palm - 3. Benchmark Outils de développement

Bench2


Version 12 - 25 juillet 2009
Fait par Laurent Duveau
web Site : http://www.aldweb.com
e-mail : info@aldweb.com


QUOI DE NEUF DANS CETTE VERSION DE BENCH2 ?

Version 12 (25 juillet 2009)
  • Ai ajouté FastBasic
Version 11 (17 octobre 2006)
  • Ai ajouté NaPP ("private preview release")
Version 10 (7 janvier 2006)
  • Ai ajouté PocketC Architect (merci à Christopher Hill)
  • Ai ajouté Palm Basic
Version 9 (23 février 2005)
  • Ai ajouté Quartus Forth (merci à Marc Furrer)
  • Mise à jour des résultats pour iziBasic dans sa 5ème version (plus rapide)
  • Ai groupé les outils en 4 catégories dans la table de résultats
Version 8 (22 octobre 2004)
  • Ai ajouté AppForge (merci à Ingbert Grimpe)
  • Ai changé le type (d'interprété à runtime) pour HotPaw Basic et SmallBasic car il apparaît que ces 2 outils utilisent un bytecode interne
Version 7 (5 septembre 2004)
  • Mise à jour des résultats pour iziBasic dans sa 2ème version (plus rapide)
Version 6 (22 juillet 2004)
  • Changement de la machine de référence : du Sony Clié N770C au Palm Tungsten C, donc j'ai du reprendre toutes les mesures !
  • Conséquence du point précédent, j'ai commencé à inclure des versions d'ARMlets (Palm OS 5) de Bench2
  • Mise à jour pour de nombreux outils de développement dans leur dernière version : cbasPad5, HotPaw Basic, HSPascal, LyME, OnBoardC, picoBASIC, PLua, PP, Rexx
  • Ajout de LaFac HELP, µBAS, µPAS et µC (mon propre outil de développement multi-mini-langages)
  • Ajout de iziBasic
Version 5 (17 février 2004)
  • Ajout de LispMe
  • Ajout de CASL
Version 4 (18 septembre 2003)
  • Ajout de OrbForms Designer
  • Mise à niveau de PocketC dans sa dernière version
  • Mise à niveau de PP dans sa dernière version
Version 3 (1er septembre 2003)
  • Ajout de HB++, tout nouveau compilateur Basic et outil de développement RAD
Version 2 (12 décembre 2002)
  • 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
Version 1 (22 octobre 2002)
  • Première version


LA GENESE 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 :
  1. 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.
  2. 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.
  3. 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.

Michael Winikoff a déjà effectué un travail très impressionnant sur ce sujet dans sa page PalmPilot Software Development - Alternatives to C. Michael a en effet " benchmarké " (ouh l'affreux anglicisme !) différents outils de développement avec la routine de bechmark toute simple (routine que j'ai surnommé Bench 1 et c'est pour cela que j'ai appelé ma propre routine Bench 2) qui suit :


début du programme
démarre le chronomètre
x = 1000
y = 0
tant que (x>0) faire
x = x-1
y = y+2
fin tant que
arrête le chronomètre
affiche le temps d'exécution
fin du programme

C'est déjà une très bonne idée et une initiative pertinente, mais ce benchmark est assez limité puisqu'il ne teste que des simples additions et soustractions sur des nombres entiers. De plus, un compilateur intelligent découvrira facilement que les variables x et y ne sont pas réutilisées par la suite et il sautera tout bonnement l'exécution de la routine tant que (c'est ce que fait CodeWarrior dans sa nouvelle version 8... une compilation en Delphi sur PC donnerait plutôt un message d'avertissement à la compilation et laisserait le programmeur décider des actions à prendre).

J'ai donc essayé de créer une routine de benchmark qui travaille avec des nombres entiers et réels, avec des tests (si... alors...), des boucles (pour ... jusque...). J'ai choisi une routine de recherche des 500 ou 1000 premiers nombres parfaits que voici :


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 = N div 2
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 ] (travail sur les nombres entiers - c'est l'analyse additionnelle apportée par la version 2 de Bench2) tourne 4 fois plus, 249001 fois, que celle avec [ si (N/D)=(N div D) alors S = S+D ] (travail sur les nombres réels - c'était la seule analyse faite dans Bench2 version 1) qui elle tourne 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.


LES RESULTATS DE BENCH2


Tous les temps mesurés ici sont ceux obtenus sur mon Palm Tungsten C (processeur XScale à 400 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 l'IDE de l'interpréteur.

Notes :
  • les outils tournant en mode 68k (PACE) sont en Bleu, ceux tournant en mode ARM natif sont en Rouge.
  • pour faciliter la lecture des résultats, j'ai choisi de grouper les outils en 4 catégories :
    1. moins de 10 secondes
    2. entre 10 et 100 secondes
    3. entre 100 et 1000 secondes
    4. plus de 1000 secondes



Outil dév. Version Langage Type Chrono 1 Chrono 2 Chrono Total
--------------------------------------------------------------------------------------------
NaPP preview Pascal compilé 0.11 sec 0.06 sec 0.17 sec
PP 2.08q Pascal compilé 0.14 sec 0.07 sec 0.21 sec
FastBasic 1.2 Basic compilé 0.86 sec 0.09 sec 0.95 sec
CodeWarrior 8.0 C compilé 0.70 sec 0.49 sec 1.19 sec
HSPascal 2.1.0 Pascal compilé 0.82 sec 0.52 sec 1.34 sec
HB++ 1.02 Basic compilé 1.12 sec 0.63 sec 1.75 sec
PP 2.08q Pascal compilé 0.71 sec 1.06 sec 1.77 sec
PocketStudio 1.1 Pascal compilé 1.08 sec 0.89 sec 1.97 sec
OnBoardC 2.4.2 C compilé 1.65 sec 0.58 sec 2.23 sec
Jump2 2.0ß8 Java compilé 1.33 sec 1.26 sec 2.59 sec
FastBasic 1.2 Basic compilé 1.55 sec 1.65 sec 3.21 sec
Quartus Forth 1.2.1 Forth compilé 2.89 sec 1.56 sec 4.45 sec
cbasPad 5.3b0i Basic interprété 1.07 sec 3.60 sec 4.67 sec
Falch.net / GCC 2.5 C compilé 5.34 sec 0.51 sec 5.85 sec
SuperWaba 4.21b Java runtime 3.06 sec 6.31 sec 9.37 sec
--------------------------------------------------------------------------------------------
AppForge 5.1.1 Basic runtime 12.92 sec 10.01 sec 22.93 sec
CASLpro / GCC 4.1.3 CASL compilé 12.46 sec 18.38 sec 30.84 sec
FastBasic 1.2 Basic interprété 10.68 sec 37.53 sec 48.21 sec
Sun MIDP (*) 1.0 Java runtime 12.20 sec 42.10 sec 54.30 sec
PLua 1.0 Lua runtime ~12 sec ~50 sec ~62 sec
OrbForms 2.1.1 C runtime 16.14 sec 49.20 sec 65.34 sec
PocketC Architect 4.0.0 C runtime 16.22 sec 49.29 sec 65.51 sec
LaFac - HELP 1.1 HELP runtime 18.73 sec 63.69 sec 82.42 sec
iziBasic 5.0 Basic runtime 21.61 sec 75.80 sec 97.41 sec
--------------------------------------------------------------------------------------------
HotPaw Basic 1.4.1 Basic runtime 29.54 sec 108.50 sec 138.04 sec
SmallBASIC 0.8.2 Basic runtime 45.14 sec 133.27 sec 178.41 sec
LispMe 3.21 Scheme runtime 39.76 sec 140.60 sec 180.36 sec
CASL 4.1.3 CASL runtime 36.16 sec 147.24 sec 184.40 sec
NS Basic/Palm 3.0.0d Basic runtime 44.71 sec 155.11 sec 199.82 sec
LaFac - µBAS 1.1 Basic runtime 47.31 sec 174.29 sec 221.60 sec
LaFac - µC 1.1 C runtime 64.90 sec 245.17 sec 310.07 sec
LaFac - µPAS 1.1 Pascal runtime 64.91 sec 245.20 sec 310.11 sec
PocketC 6.0.0 C runtime 82.51 sec 265.89 sec 348.40 sec
REXX 1.00 Rexx interprété ~89 sec ~265 sec ~354 sec
LyME 2.8 LME interprété 124.16 sec 577.78 sec 701.94 sec
Palm Tcl 0.4 Tcl interprété 203.64 sec 607.21 sec 810.85 sec
--------------------------------------------------------------------------------------------
Palm Basic (**) 1.02 Basic interprété ~280 sec ~1152 sec ~1432 sec
picoBASIC (*) 1.01 Basic interprété ~4590 sec ~15931 sec ~20521 sec
--------------------------------------------------------------------------------------------
Satellite Forms 5.0.0 Basic runtime [ne fonctionne pas sur les machines ARM]
cbasPad 0.97b4 Basic interprété [ne fonctionne pas sur les machines ARM]

Et la même chose en graphique (c'est plus visuel !) :


Langage Graphique (plus court = meilleur)
--------------------------------------------------------------------------------------------
NaPP
PP
FastBasic
CodeWarrior
HSPascal
HB++
PP
PocketStudio
OnBoardC
Jump2
FastBasic
Quartus Forth
cbasPad
Falch.net / GCC
SuperWaba
--------------------------------------------------------------------------------------------
AppForge
CASLpro / GCC
Sun MIDP (*)
PLua
OrbForms
PocketC Archit.
LaFac - HELP
iziBasic
--------------------------------------------------------------------------------------------
HotPaw Basic
SmallBASIC
LispMe
CASL
NS Basic/Palm
LaFac - µBAS
LaFac - µC
LaFac - µPAS
PocketC
REXX
LyME
Palm Tcl
--------------------------------------------------------------------------------------------
Palm Basic (**)
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.
(**) : Palm Basic n'a pas d'opérateur modulo. C'est la raison pour laquelle la boucle [ si B=2 alors si (N modulo D)=0 alors S = S+D ] ne peut être écrite telle quelle. En la remplaçant par [ si B=2 alors si (N-(N div D)*D)=0 alors S = S+D ] donne une formulation équivalente.


CONCLUSIONS


Comme vous avez pu le remarquer en lisant attentivement les tableaux ci-dessus, les résultats sont différents selon ce que l'on considère. Aucune des 3 analyses (Chrono Total Bench2 avec les 1ère et 2ème boucles, 1ère boucle seulement ou 2ème boucle seulement) ne donne le même classement.

On observe par ailleurs un écart impressionnant entre le tout premier résultat (PP en mode ARM) et le tout dernier (picoBASIC Integer en mode 68k) : 0.21 seconde versus 20521 secondes. Ce sont un peu plus de 5 heures 42 minutes qui séparent ces deux extrèmes quand le premier tourne en moins d'un quart de seconde !!!
Si l'on considère le deuxième (CodeWarrior en mode 68k à 1.19 secondes) et le dernier "raisonnable" (Palm Tcl en mode 68k à 810.85 secondes), en considérant donc que les extrêmes ne sont pas significatifs, on a encore un énorme écart de presque 13 minutes et demie à ramener sur 1.19 secondes !!!

Sans surprise, on voit que les langages compilés sont plus rapides que ceux à runtime, eux mêmes plus rapides que les langages interprétés.

Personellement, je suis plutôt heureux de voir que mes langages HELP, µBAS, µPAS et µC inclus dans LaFac sont plutôt placés dans la bonne moyenne (auto-satisfaction !).
Je suis encore plus satisfait de voir que iziBasic se place en tête dans le groupe des Basic bien connus, mais moins riches en terme de fonctionnalités GUI.

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, en prenant en compte cet objectif, je vous laisse établir par vous même votre podium personnel !

En guise de conclusion, n'oublions pas, comme me l'a fort justement 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, professionnel ou amateur, 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 ?

Si vous répondez à ces questions, vous trouverez votre vérité. Et il y a bien plusieurs vérités puisque nous sommes tous différents.
Réalisons aussi que nous sommes bien chanceux d'avoir à notre disposition un tel choix d'outils de développement sur notre plateforme Palm !


LE CODE SOURCE DE BENCH2 POUR CHAQUE LANGAGE


Seuls les résultats finaux ont été reportés dans cette page. 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.

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 ou dans une version plus récente, je serais très content si vous me contactiez.

Date de création : 01/01/2003 @ 00:00
Dernière modification : 30/07/2009 @ 21:05
Catégorie : VI. Connaissance Palm


Imprimer l'article Imprimer l'article

 
react.gifRéactions à cet article


Réaction n°28 

par aldweb le 12/06/2007 @ 20:04

Hello Michael,

Your contribution offer is very welcome, thank you.
I will send you the project file I was sent at the time of NSBasic v3.
Could you, in return, send back to me the compiled PRC (and required v6 runtime) and the updated source code... this might be useful to someone in the future (just like the current sending is for you now!). Thanks.

Cheers,
aldweb

PS: for people willing to help, the source code for all languages is available here or you can drop me an e-mail to retrieve it in the working format

Réaction n°27 

par Michael Verive le 12/06/2007 @ 04:39

I noticed that your NSBasic version is 3, while the current version is 6.1. I'd be happy to run the benchmark and report the results. If you have the original source, I can use that. If not, I'll write a version for NSBasic.

Réaction n°26 

par bvoqui le 16/11/2006 @ 11:08

Ce n'est pas tout à fait le même test , mais voici nos mesures sur notre machine 'embarquée' avec un ARM d'origine Atmel : AT91RM avec horloge système à 180 MHZ :

/* main.c ------------------------------------------------------------------
*/

#include "../Plug/Common.h"

/* Portage partiel PalmOS -> AT91RM
Mesure du nombre de 'slow clocks' [ 1 / 32768 emes de seconde ]
*/
static int TimGetTicks ()
{
return AT91C_BASE_ST -> ST_CRTR ;
}

/*
// Perfect Numbers finder routine
*/
void PerfectNum( int b ) {
int n,d,m,s,p;
long t;
int e ; // mesure mise a l'echelle
char c[80];

t=TimGetTicks();
p=0;
for(n=2;n<=b*500;n++) {
m=n/2;
s=1;
for(d=2;d<=m;d++) {
if(b==1) if((n%d)==0) s=s+d;
if(b==2) if((n%d)==0) s=s+d;
}
if(s==n) p=p+1;
}
if ( p != 3 ) d = 0 ; else d = TimGetTicks () - t ;
e = d * 1000000 / 32768 ;
sprintf ( c , "Mesure : %d slowclocks -> %d usrn" , d , e ) ;
DBGputs ( c ) ;
return;
}

/*--------------------------------------------------------------------------*/
int main ()
{
int b;

x_Twait ( 1234 ) ;

DBGputs ( "rnrnrnPortage du test aldweb : ARM Atmel + GCCrn" ) ;

for(b=1;b<=2;b++) {
PerfectNum( b );
}
x_Texit () ;
}

Portage du test aldweb : ARM Atmel + GCC
Mesure : 24 slowclocks -> 732 us
Mesure : 100 slowclocks -> 3051 us

Réaction n°25 

par aldweb le 15/11/2006 @ 13:42

Bonjour bvoqui,

La mesure a été faite avec une version de GCC qui compile en code 68k DragonBall, pas en ARM. Le ralentissement est alors du à l'émulateur 68k inclus dans Palm OS 5 (qui tourne sur processeurs ARM quand les versions précédentes tournaient sur processeurs DragonBall).

Je serais donc heureux de recevoir le Bench2 compilé en GCC ARM pour Palm, afin d'avoir cet autre élément de mesure.

@+
aldweb

Réaction n°24 

par bvoqui le 14/11/2006 @ 18:08

Avec quelques collègues nous sommes un peu surpris du mauvais résultat de GCC . Nous développons en effet du logiciel embarqué sur un processeur à base ARM [ AT91RM9200 ] avec gcc 2.95.3 qui ne semble pas si mauvais par rapport à ce qui pourrait être fait 'à la main' en assembleur ARM . Bien sûr , nous utilisons l'optimisation maximale ( 03 ) et avons repris les fonctions de division et de modulo ..
DébutPrécédent [ 1 2 3 4 5 6 ] SuivantFin
 
Spécial !



Version mobile
de l'aldweb Site

m.aldweb.com


Ni Français, ni Anglais ?

Essayez donc l'un de ces drapeaux :
[de] [es] [it] [pt]
Météo / Spam / www

Météo Lyon


aldweb contre le SPAM


Sites web de la famille

News Amis
Sondage
Comment trouve-tu le nouvel habillage de l'aldweb Site ?
 
Superbe !
Joli
Moyen
Moche...
Résultats
^ Haut ^