|
|
VI. Connaissance Palm - 3. Benchmark Outils de développement |
|
|
Bench2Version 12 - 25 juillet 2009 Fait par Laurent Duveau web Site : http://www.aldweb.com e-mail : info@aldweb.comQUOI DE NEUF DANS CETTE VERSION DE BENCH2 ?Version 12 (25 juillet 2009) 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) LA GENESE DE BENCH2J'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.
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 BENCH2Tous 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 :
- moins de 10 secondes
- entre 10 et 100 secondes
- entre 100 et 1000 secondes
- 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.CONCLUSIONSComme 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 LANGAGESeuls 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
|
|
|
|
|
|
Ré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 ..
|
Réaction n°23 |
par Emma
le 06/11/2006 @ 04:30 |
Coucou !
Pour celles et ceux qui comme moi ce demandais ce que c'était un "benchmark" je vous invite à aller voir la définition sur wikipédia... tout d'un coup tout s'éclair !
C'est par ici : http://fr.wikipedia.org/wiki/Benchmark
Bises ! Emma
|
Réaction n°22 |
par Pacman
le 08/05/2006 @ 18:55 |
Il serait intéressant d'ajouter Websphere/J9 qui semble être la plateforme poussée par PalmSource en ce moment.
Enfin à titre de comparaison technique surtout, car c'est quand même assez différent du reste du lot...
|
Réaction n°21 |
par Miellaby
le 09/03/2005 @ 10:36 |
:) oui d'ailleurs je crois que je vais m'arrêter. Merci d'avoir répondu à chaque fois.
|
Réaction n°20 |
par aldweb
le 08/03/2005 @ 20:34 |
Et bien, cher Miellaby, le moins que l'on puisse dire est que cet article te passionne ou, tout du moins, te fait réagir !
Je suis ennuyé et même vexé que tu ais vu autant de "sous-entendus" dans ces questions qui m'ont été suggérées par un développeur renommé et que j'ai trouvé intéressant de reprendre ici pour bien aider les gens à ne pas faire des conclusions hatives à la vue des seuls résultats exposés dans cette page.
Je n'ai pour ma part jamais cherché quoi que ce soit d'autre dans ce petit exercice de style qu'est Bench2 que ce que je mets dans le préambule. Ce qu'on pourrait écrire en d'autres termes : 1. surtout découvrir des syntaxes de langages que je connaissais peu 2. et aussi recenser nombre d'outils de développement "exotiques", peu connus et néanmoins fort intéressants
Ma conclusion dit surtout "(...) je vous laisse établir par vous même votre podium personnel !" ou encore "(...) vous trouverez votre vérité. Et il y a bien plusieurs vérités (...)", ce qui laisse bien entendre, et rien sous-entendre dans mon esprit, qu'il y a bien des choix possibles laissés au libre arbitre de chacun.
Ceci étant, je suis tout disposé à collaborer avec toi pour monter un "Bench3" qui propose d'autres vues.
@+ aldweb
|
Réaction n°19 |
par Miellaby
le 08/03/2005 @ 14:16 |
Pour choisir un langage, je vois les questions suivantes :
"Quelle proportion du travail est liée à la performance du processeur ?"
Sous-entendu : si la vitesse d'exécution est primordial, alors il faut du compilé, et peut-être même de l'assembleur.
Mon opinion : c'est faux pour un programmeur moyen et une application qui manipulent des données complexes (chaîne de caractères, enregistrements structurés) tout en proposant de nombreuses fonctionnalités : classements, recherche, indexation... Dance ce cas : pascal/C/Assembleur = programme lent. En {Langage interprété avancé} = {programme simple et rapide}.
"Combien de temps va me prendre le développement de mon application ?"
Sous-entendu : s'il faut faire vite, alors choisir basic.
Mon opinion : Non, on peut programmer rapidement dans tout langage du moment où on choisit le bon pour le logiciel à concevoir. On peut perdre du temps en Basic à programmer des choses aussi simples q'une pile ou une recherche de données dans des tableaux.
"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 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 ?"
Ici beaucoup de questions équivalentes, qui sous-entendent que si on veut du pro, il faut un langage cher, pas du freeware. Mais depuis l'émergence d'un troisième acteur: l'open-source, tout cela n'est plus tout à fait vrai.
"Quelle est la facilité de déploiement ?"
Sous-entendu : Source + run-time/interpréteur moins bien que binaire exécutable. Là aussi, ça se discute. Tout dépend de l'installateur.
Mais pour finir, il manque la question que je ne vois nulle part : "Qu'est ce que doit faire votre programme?".
Si c'est un programme peu d'intelligence: BASIC.
S'il s'agit de faire de la "computation" sur des données simples (entier, réel...) : C, Pascal, procédural compilé.
S'il s'agit de faire des traitements avancées sur des données structurées : Lua, Tcl, Python, Lisp, etc...
|
Réaction n°18 |
par aldweb
le 25/02/2005 @ 00:33 |
Miellabi,
Relis bien la conclusion, surtout le paragraphe tout droit sorti d'un échange d'e-mails avec George Henne, échange très similaire à cette discussion que tu as engagée ici. Je crois bien que nous sommes fondamentalement d'accords !
Je suis bien d'accord aussi sur la finalité des applications Palm générales. Mon benchmark Speedy qui est dans le TOP 50 des applis les plus utilisées selon http://trackerdog.a0soft.com/ fonctionne sous un tout autre principe que ce petit exercice de style Bench2, avec bien cet objectif de donner une estimation de rapidité d'une application "moyenne", car pas 2 applis se ressemblent néanmoins.
|
Réaction n°17 |
par Miellaby
le 17/02/2005 @ 11:22 |
computionnels: lire "computationnels"
|
Réaction n°16 |
par miellaby
le 17/02/2005 @ 11:21 |
Le calcul numérique que tu as choisis permet de comparer des langages procéduraux entre eux (C, Pascal, Java...) ou de comparer les basics entre eux.
Mais il ne permet pas de comparer le tout à des langages haut-niveau. Ces derniers sont conçus pour gérer de l'information, pas pour faire des calculs computionnels primaires.
Il s'agit de savoir à quoi va servir le langage. Basic est bien pour faire un petit convertisseur d'Euro en 3 lignes, Pascal est bien pour programmer un logiciel rapide mais pas trop complexe (un jeu d'action).
Mais voilà. Les logiciels pour lesquels les Palms sont prévus au départ, c'est avant tout des gestionnaires... de rendez-vous, de n° de téléphone, de scoubidous... avec des possibilités de classement, de tri, de recherche, de renvoi et toutes ces sortes de chose.
Or des langages scriptiques lents et compliqués quand il s'agit de faire des calculs (en Tcl, il faut exécuter une commande pour faire une addition), se révèlent faciles à employer et très efficaces (hashTable à tous les étages) pour ce genre d'application.
Ils vont même être plus rapides à l'exécution que du Pascal compilé quand la quantité de données augmente, à moins d'avoir mis au point des hashTables de hashTables en Pascal, ce qui n'est à la portée de presque personne.
je vais être plus précis avec l'exemple du gestionnaire d'adresse. Voilà un début de programme:
En basic -------------------- DIM N$(10) 'Les noms DIM A$(10) 'Les adresses N = 0 'Le nombre de nom
'A transformer en procedure N = N + 1 N$(N) = "sylvain" A$(N) = "palmville"
'Trouver une adresse INPUT C$ FOR I = 1 TO N IF N$(I) = C$ THEN PRINT A$(I) NEXT I En Tcl (par exemple) -------------------- # a : la table des adresses, indexé par les noms set a(sylvain) "palmville" set c [gets] puts $a($c)
... à partir de là, toutes les opérations dont j'ai parlé plus haut (recherche, tri...) se font en quelques instructions, alors qu'en Basic, ca deviendrait vite l'usine à gaz.
|
Réaction n°15 |
par aldweb
le 11/02/2005 @ 15:10 |
miellaby,
Merci pour tes bien sympathiques compliments.
Il n'y a pas de problème que tu interviennes. Au contraire ! Si tu as cru que j'étais vexé, point du tout. Tu ouvres un débat, je trouve tes remarques intéressantes, donc je me permets à mon tour de te répondre
Pour en revenir au benchmark, permets moi de te donner quelques réflexions (pas par odre d'importance, mais dans l'ordre où mon cerveau les produit !) :
1. Un benchmark reste une approximation, à ne jamais oublier !
2. Ce que tu proposes fait plus appel aux API Palm OS, ce n'est donc plus tout à fait le langage de développement qui est benchmarké mais plutôt Palm OS lui-même. Il y aura donc un énorme lissage entre les différents outils.
3. Un benchmark d'outil de développement doit donc en rester à des opérations mathématiques simples, en nombres entiers. Tu noteras mon paragraphe sur la routine nombres réels de Bench2... nombre d'outils s'appuient sur Palm OS pour les réels...
4. Un compilo pur et dur, rapide, sera vraiment utile pour ceux qui font beaucoup d'algorithmique et de calculs dans leur logiciel, et il y en a plus que tu le crois... ne serait-ce que nombre de jeux. Si tu prends mes deux jeux Cells et PalmPulus, ils ne tournent de façon fluide que parce que j'ai pris un des outils en haut du tableau pour chacun d'entre eux.
@+ aldweb
|
Réaction n°14 |
par miellaby
le 07/02/2005 @ 13:29 |
je me demande encore pourquoi je suis intervenu. On ne devrait jamais émettre une critique avant d'avoir formuler 7 compliments, pas vrai?
Donc j'ai vraiment apprécié ce benchmark, et surtout ta volonté de faire partager ta connaissance pour faire avancer le schmilblick.
Et puis, les sources dans les différents langages. C'est très éducatif.
J'ai tout de suite mis cette page et bien d'autre dans mes signets.
En plus, après avoir installer pp (influencé par le benchmark), j'ai explorer et tester le source de NekoPP.
Quel talent! Bravi brava bravo.
Mais bon, j'en reviens à l'interprétation des résultats du benchmark. Je veux pas te faire de la peine, mais si ça s'adresse à un développeur, c'est un développeur franchement atypique!
... parce que sur le Palm d'un invidu Lambda, y'a plus une seule appli qui ait besoin de calculer une factorielle. Quand tu dis que l'objectif est de tester "une routine pas spécialement optimisée"... j'aurai aimé que tu ajoutes :"[...] et qui ne correspond pas à un cas d'utilisation courant des langages aujourd'hui".
Si tu fais un benchmark sur la base d'un petit gestionnaire d'adresse (ajouter/supprimer/chercher une adresse), les langages scriptiques qui savent gérer en natif des collections de donnée se retrouvent en tête, avec un code super simpe en prime. Ben c'est tout. Fallait le dire non?
|
Réaction n°13 |
par aldweb
le 20/01/2005 @ 22:22 |
Miellaby,
Ce bench ne correspond pas à celui d'un utilisateur de PDA, mais d'un développeur sur PDA.
Pour une attente d'utilisateur, j'ai essayé d'y répondre par Speedy
Via ce bench, j'essaye juste de donner une idée de rapidité d'une bête routine reproductible aisément dans tous les langages et presque comparable.
Je t'invite à bien relire la conclusion de mon article ci-dessus, surtout le paragraphe proposé par George Henne de NSBasic Corporation... je crois que nous sommes bien d'accords en fait !
@+ aldweb
|
Réaction n°12 |
par Miellaby
le 20/01/2005 @ 17:13 |
Moi je trouve que ce bench ne correspond pas à ce que la majorité des utilisateurs attendent d'un PDA.
Voici plusieurs années que nos bécanes grosses et petites servent beaucoup moins à calculer des trajectoires de balistique (éthimologie de l'anglais computer) qu'à gérer de l'information structurée (éthimologie du francais ordinateur).
Bref, des langages scriptiques en queue de classement peuvent se réveler très efficace pour faire tourner une application quotidienne qui gèrent des listes, des tables indexés par des chaînes de caractères, etc. Je pense à ce pauve langage Tcl dont le portage a été abandonné.
|
Réaction n°11 |
par aldweb
le 27/09/2004 @ 21:54 |
Yv,
Il y aurait tout plein de choses à prendre en compte, comme aussi le traitement des appels aux APIs GUI, effectivement aussi le traitement des strings. On aurait aussi pu envisager la gestion de tableaux, de pointeurs, etc... Un benchmark de ce genre n'est jamais une science exacte. Mais, dans l'ensemble, le classement ainsi donné suit bien une logique de performance à peu près réaliste des outils "en compétition".
Quant aux colonnes à rajouter, je suis assez d'accord. Je ne l'ai pas fait pour la colonne desktop/onboard que j'avais pourtant envisagée dans ma dernière mise à jour de cette page... un peu par paresse !
Cordialement, aldweb
|
Réaction n°10 |
par Yv
le 27/09/2004 @ 10:45 |
Interessant. Mais comme le suggere la question de la proportion du travail liée à la performance du processeur, est-ce qu'il serait possible de concevoir un benchmark qui prenne en au moins en compte l'allocation memoire/traitement de chaines de caracteres plutot que des operations arithmetiques? Autre idee, ajouter une colonne pour indiquer environnement de developpement desktop ou Palm, et une autre pour la taille du code genere.
|
Réaction n°9 |
par aldweb
le 23/07/2004 @ 11:27 |
Palmipod,
I guess that you are talking about my development tools LaFac and iziBasic. Yes, they are both ahead of PocketC
Greetz, aldweb
|
Réaction n°7 |
par aldweb
le 27/01/2004 @ 20:15 |
Joe,
Sure, Appforge MobileVB is also missing. Do you volunteer to provide me with source code + files to run Bench2 in my device ?
|
Réaction n°6 |
par Joe le 27/01/2004 @ 12:22 |
And what's about Appforge MobileVB?
|
Réaction n°5 |
par aldweb
le 24/01/2004 @ 19:25 |
François,
I would be more than happy to include Quartus Forth in this analysis. But no contributor helped me so far. Will you be this one?
|
Réaction n°4 |
par Francois Bachmann le 23/01/2004 @ 23:26 |
What about Quartus ?
|
Réaction n°3 |
par aldweb
le 20/01/2004 @ 22:34 |
Ah jbb, transmission de pensée ou presque. Voici très peu de temps que j'ai pris contact avec Fred Bayer, l'auteur de LispMe.
Je transmettais justement les résultats à Fred qui m'a gentiment traduit le code de Bench2 et transmis les indications pour l'exécuter lorsque tu postais ce message.
Donc, un peu de patience, le temps que je mette à jour cette page web... mais LispMe se place très bien dans sa catégorie
|
Réaction n°2 |
par jbb le 20/01/2004 @ 10:26 |
Il manque un langage interessant : LISP. http://www.lispme.de/
Je suis curieux de voir le resultat ...
|
Réaction n°1 |
par Guilherme C. Hazan le 13/10/2003 @ 16:43 |
This work is very important. I think it is the best one in terms of number of developement tools used.
But it has a flaw: the algorithm previledges double floating point arithmetic, while ignoring other important aspects of the language.
Ok, i understand that is not easy to provide an algorithm that handles all aspects of computer programming, but i'm sure that a better one could be found.
Btw, the HSPascal does not use 64bit arithmetic, but 32bit, so that's the reason why it appears in first place.
|
|
|
|
|
|
|
Spécial ! |
Version mobile de l'aldweb Site m.aldweb.com Ni Français, ni Anglais ?Essayez donc l'un de ces drapeaux :
|
|
Météo / Spam / www |
Météo Lyon
aldweb contre le SPAM
|
|
|