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°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?

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 ^